Which layer in the API-led connectivity focuses on unlocking key systems, legacy systems, data sources etc and exposes the functionality?

• A.Experience Layer
• B.Process Layer
• C.System Layer

Correct Answer: C

Correct answer: System Layer

The APIs used in an API-led approach to connectivity fall into three categories:
System APIs - these usually access the core systems of record and provide a means of insulating the user from the complexity or any changes to the underlying systems. Once built, many users, can access data without any need to learn the underlying systems and can reuse these APIs in multiple projects.
Process APIs - These APIs interact with and shape data within a single system or across systems (breaking down data silos) and are created here without a dependence on the source systems from which that data originates, as well as the target channels through which that data is delivered.
Experience APIs - Experience APIs are the means by which data can be reconfigured so that it is most easily consumed by its intended audience, all from a common data source, rather than setting up separate point-to-point integrations for each channel. An Experience API is usually created with API-first design principles where the API is designed for the specific user experience in mind.

Comment: *

Name: *

Email: *

Verification: *

What is true about API implementations when dealing with legal regulations that require all data processing to be performed within a certain jurisdiction (such as in the USA or the EU)?

• A.They must avoid using the Object Store as it depends on services deployed ONLY to the US East region
• B.They must use a Jurisdiction-local external messaging system such as Active MQ rather than Anypoint MQ
• C.They must te deployed to Anypoint Platform runtime planes that are managed by Anypoint Platform control planes, with both planes in the same Jurisdiction
• D.They must ensure ALL data is encrypted both in transit and at rest

Comment: *

Name: *

Email: *

Verification: *

An API implementation is being designed that must invoke an Order API, which is known to repeatedly experience downtime.
For this reason, a fallback API is to be called when the Order API is unavailable.
What approach to designing the invocation of the fallback API provides the best resilience?

• A.Create a separate entry for the Order API in API Manager, and then invoke this API as a fallback API if the primary Order API is unavailable
• B.Search Anypoint Exchange for a suitable existing fallback API, and then implement invocations to this fallback API in addition to the Order API
• C.Set an option in the HTTP Requester component that invokes the Order API to instead invoke a fallback API whenever an HTTP 4xx or 5xx response status code is returned from the Order API
• D.Redirect client requests through an HTTP 307 Temporary Redirect status code to the fallback API whenever the Order API is unavailable

Comment: *

Name: *

Email: *

Verification: *

Refer to the exhibit.

what is true when using customer-hosted Mule runtimes with the MuleSoft-hosted Anypoint Platform control plane (hybrid deployment)?

• A.Anypoint Runtime Manager automatically ensures HA in the control plane by creating a new Mule runtime instance in case of a node failure
• B.Anypoint Runtime Manager initiates a network connection to a Mule runtime in order to deploy Mule applications
• C.API implementations can run successfully in customer-hosted Mule runtimes, even when they are unable to communicate with the control plane
• D.The MuleSoft-hosted Shared Load Balancer can be used to load balance API invocations to the Mule runtimes

Comment: *

Name: *

Email: *

Verification: *

Due to a limitation in the backend system, a system API can only handle up to 500 requests per second. What is the best type of API policy to apply to the system API to avoid overloading the backend system?

• A.Rate limiting
• B.HTTP caching
• C.Rate limiting - SLA based
• D.Spike control

Comment: *

Name: *

Email: *

Verification: *