Mulesoft MCPA-Level-1 Exam Questions

A system API has a guaranteed SLA of 100 ms per request. The system API is deployed to a primary environment as well as to a disaster recovery (DR) environment, with different DNS names in each environment. An upstream process API invokes the system API and the main goal of this process API is to respond to client requests in the least possible time. In what order should the system APIs be invoked, and what changes should be made in order to speed up the response time for requests from the process API?

A. In parallel, invoke the system API deployed to the primary environment and the system API deployed to the DR environment, and ONLY use the first response

B. In parallel, invoke the system API deployed to the primary environment and the system API deployed to the DR environment using a scatter-gather configured with a timeout, and then merge the responses

C. Invoke the system API deployed to the primary environment, and if it fails, invoke the system API deployed to the DR environment

D. Invoke ONLY the system API deployed to the primary environment, and add timeout and retry logic to avoid intermittent failures

A. In parallel, invoke the system API deployed to the primary environment and the system API deployed to the DR environment, and ONLY use the first response

Explanation: Explanation
Correct Answer: In parallel, invoke the system API deployed to the primary environment
and the system API deployed to the DR environment, and ONLY use the first response.
*****************************************
>> The API requirement in the given scenario is to respond in least possible time.
>> The option that is suggesting to first try the API in primary environment and then
fallback to API in DR environment would result in successful response but NOT in least
possible time. So, this is NOT a right choice of implementation for given requirement.
>> Another option that is suggesting to ONLY invoke API in primary environment and to
add timeout and retries may also result in successful response upon retries but NOT in
least possible time. So, this is also NOT a right choice of implementation for given
requirement.
>> One more option that is suggesting to invoke API in primary environment and API in DR
environment in parallel using Scatter-Gather would result in wrong API response as it
would return merged results and moreover, Scatter-Gather does things in parallel which is
true but still completes its scope only on finishing all routes inside it. So again, NOT a right
choice of implementation for given requirement
The Correct choice is to invoke the API in primary environment and the API in DR
environment parallelly, and using ONLY the first response received from one of them

Refer to the exhibit.

Three business processes need to be implemented, and the implementations need to communicate with several different SaaS applications.
These processes are owned by separate (siloed) LOBs and are mainly independent of each other, but do share a few business entities. Each LOB has one development team and their own budget.
In this organizational context, what is the most effective approach to choose the API data models for the APIs that will implement these business processes with minimal redundancy of the data models?
A) Build several Bounded Context Data Models that align with coherent parts of the business processes and the definitions of associated business entities.
B) Build distinct data models for each API to follow established micro-services and Agile API-centric practices
C) Build all API data models using XML schema to drive consistency and reuse across the organization
D) Build one centralized Canonical Data Model (Enterprise Data Model) that unifies all the data types from all three business processes, ensuring the data model is consistent and non-redundant

A. Option A

B. Option B

C. Option C

D. Option D

A. Option A

Explanation:

Correct Answer: Build several Bounded Context Data Models that align with coherent parts of the business processes and the definitions of associated business entities.

The options w.r.t building API data models using XML schema/ Agile API-centric practices are irrelevant to the scenario given in the question. So these two are INVALID.
Building EDM (Enterprise Data Model) is not feasible or right fit for this scenario as the teams and LOBs work in silo and they all have different initiatives, budget etc.. Building EDM needs intensive coordination among all the team which evidently seems not possible in this scenario.

So, the right fit for this scenario is to build several Bounded Context Data Models that align with coherent parts of the business processes and the definitions of associated business entities.

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.

Search Anypoint Exchange for a suitable existing fallback API, and then implement
invocations to this fallback API in addition to the Order API

B.

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

C.

Redirect client requests through an HTTP 307 Temporary Redirect status code to the
fallback API whenever the Order API is unavailable

D.

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

A.

Search Anypoint Exchange for a suitable existing fallback API, and then implement
invocations to this fallback API in addition to the Order API

Explanation: Explanation
Correct Answer: Search Anypoint exchange for a suitable existing fallback API, and then
implement invocations to this fallback API in addition to the order API
*****************************************
>> It is not ideal and good approach, until unless there is a pre-approved agreement with
the API clients that they will receive a HTTP 3xx temporary redirect status code and they
have to implement fallback logic their side to call another API.
>> Creating separate entry of same Order API in API manager would just create an
another instance of it on top of same API implementation. So, it does NO GOOD by using
clone od same API as a fallback API. Fallback API should be ideally a different API
implementation that is not same as primary one.
>> There is NO option currently provided by Anypoint HTTP Connector that allows us to
invoke a fallback API when we receive certain HTTP status codes in response.
The only statement TRUE in the given options is to Search Anypoint exchange for a
suitable existing fallback API, and then implement invocations to this fallback API in
addition to the order API.

An API client calls one method from an existing API implementation. The API
implementation is later updated. What change to the API implementation would require the API client's invocation logic to also be updated?

A.

When the data type of the response is changed for the method called by the API client

B.

When a new method is added to the resource used by the API client

C.

When a new required field is added to the method called by the API client

D.

When a child method is added to the method called by the API client

C.

When a new required field is added to the method called by the API client

Explanation: Explanation
Correct Answer: When a new required field is added to the method called by the API client
*****************************************
>> Generally, the logic on API clients need to be updated when the API contract breaks.
>> When a new method or a child method is added to an API , the API client does not
break as it can still continue to use its existing method. So these two options are out.
>> We are left for two more where "datatype of the response if changed" and "a new
required field is added".
>> Changing the datatype of the response does break the API contract. However, the
question is insisting on the "invocation" logic and not about the response handling logic.
The API client can still invoke the API successfully and receive the response but the
response will have a different datatype for some field.
>> Adding a new required field will break the API's invocation contract. When adding a new
required field, the API contract breaks the RAML or API spec agreement that the API
client/API consumer and API provider has between them. So this requires the API client
invocation logic to also be updated.

Once an API Implementation is ready and the API is registered on API Manager, who should request the access to the API on Anypoint Exchange?

A.

None

B.

Both

C.

API Client

D.

API Consumer

D.

API Consumer

Explanation: Explanation
Correct Answer: API Consumer
*****************************************
>> API clients are piece of code or programs that use the client credentials of API
consumer but does not directly interact with Anypoint Exchange to get the access
>> API consumer is the one who should get registered and request access to API and then
API client needs to use those client credentials to hit the APIs
So, API consumer is the one who needs to request access on the API from Anypoint
Exchange

What is typically NOT a function of the APIs created within the framework called API-led connectivity?

A.

They provide an additional layer of resilience on top of the underlying backend system,
thereby insulating clients from extended failure of these systems.

B.

They allow for innovation at the user Interface level by consuming the underlying assets
without being aware of how data Is being extracted from backend systems.

C.

They reduce the dependency on the underlying backend systems by helping unlock data
from backend systems In a reusable and consumable way.

D.

They can compose data from various sources and combine them with orchestration logic to create higher level value.

A.

They provide an additional layer of resilience on top of the underlying backend system,
thereby insulating clients from extended failure of these systems.

Explanation: Explanation
Correct Answer: They provide an additional layer of resilience on top of the underlying
backend system, thereby insulating clients from extended failure of these systems.
*****************************************
In API-led connectivity,
>> Experience APIs - allow for innovation at the user interface level by consuming the
underlying assets without being aware of how data is being extracted from backend
systems.
>> Process APIs - compose data from various sources and combine them with
orchestration logic to create higher level value
>> System APIs - reduce the dependency on the underlying backend systems by helping
unlock data from backend systems in a reusable and consumable way.
However, they NEVER promise that they provide an additional layer of resilience on top of
the underlying backend system, thereby insulating clients from extended failure of these
systems.
https://dzone.com/articles/api-led-connectivity-with-mule

What best describes the Fully Qualified Domain Names (FQDNs), also known as DNS entries, created when a Mule application is deployed to the CloudHub Shared Worker Cloud?

A.

A fixed number of FQDNs are created, IRRESPECTIVE of the environment and VPC design

B.

The FQDNs are determined by the application name chosen, IRRESPECTIVE of the region

C.

The FQDNs are determined by the application name, but can be modified by an
administrator after deployment

D.

The FQDNs are determined by both the application name and the Anypoint Platform
organization

B.

The FQDNs are determined by the application name chosen, IRRESPECTIVE of the region

Explanation: Explanation
Correct Answer: The FQDNs are determined by the application name chosen,
IRRESPECTIVE of the region
*****************************************
>> When deploying applications to Shared Worker Cloud, the FQDN are always
determined by application name chosen.
>> It does NOT matter what region the app is being deployed to.
>> Although it is fact and true that the generated FQDN will have the region included in it
(Ex: exp-salesorder-api.au-s1.cloudhub.io), it does NOT mean that the same name can be
used when deploying to another CloudHub region.
>> Application name should be universally unique irrespective of Region and Organization
and solely determines the FQDN for Shared Load Balancers

Refer to the exhibit. An organization is running a Mule standalone runtime and has
configured Active Directory as the Anypoint Platform external Identity Provider. The organization does not have budget for other system components.

What policy should be applied to all instances of APIs in the organization to most
effecuvelyKestrict access to a specific group of internal users?

A.

Apply a basic authentication - LDAP policy; the internal Active Directory will be
configured as the LDAP source for authenticating users

B.

Apply a client ID enforcement policy; the specific group of users will configure their client applications to use their specific client credentials

C.

Apply an IP whitelist policy; only the specific users' workstations will be in the whitelist

D.

Apply an OAuth 2.0 access token enforcement policy; the internal Active Directory will be configured as the OAuth server

A.

Apply a basic authentication - LDAP policy; the internal Active Directory will be
configured as the LDAP source for authenticating users

Explanation: Explanation
Correct Answer: Apply a basic authentication - LDAP policy; the internal Active Directory
will be configured as the LDAP source for authenticating users.
*****************************************
>> IP Whitelisting does NOT fit for this purpose. Moreover, the users workstations may not
necessarily have static IPs in the network.
>> OAuth 2.0 enforcement requires a client provider which isn't in the organizations system
components.
>> It is not an effective approach to let every user create separate client credentials and
configure those for their usage.
The effective way it to apply a basic authentication - LDAP policy and the internal Active
Directory will be configured as the LDAP source for authenticating users.
Reference: https://docs.mulesoft.com/api-manager/2.x/basic-authentication-ldap-concept