Mulesoft MCPA-Level-1 Exam Questions

The Line of Business (LoB) of an eCommerce company is requesting a process that sends automated notifications via email every time a new order is processed through the customer's mobile application or through the internal company's web application. In the future, multiple notification channels may be added: for example, text messages and push notifications. What is the most effective API-led connectivity approach for the scenario described above?

A. Create one Experience API for the web application and one for the mobile application.
Create a Process API to orchestrate and retrieve the email template from = database.
Create a System API that sends the email using the Anypoint Connector for Email.
Create one Experience API for the web application and one for the mobile application.
Create a Process API to orchestrate and retrieve the email template from = database.
Create a System API that sends the email using the Anypoint Connector for Email.

B. Create one Experience API for the web application and one for the mobile application
Create a Process API to orchestrate, retrieve the email template from a database, and send the email using the Anypoint Connector for Email.

C. Create Experience APIs for both the web application and mobile application.
Create a Process API ta orchestrate, retrieve the email template from e database, and send the email using the Anypoint Connector for Email.

D. Create Experience APIs for both the web application and mobile application.
(Create 3 Process API to orchestrate and retrieve the email template from 2 database.
Create a System API that sends the email using the Anypoint Connector for Email.

A. Create one Experience API for the web application and one for the mobile application.
Create a Process API to orchestrate and retrieve the email template from = database.
Create a System API that sends the email using the Anypoint Connector for Email.
Create one Experience API for the web application and one for the mobile application.
Create a Process API to orchestrate and retrieve the email template from = database.
Create a System API that sends the email using the Anypoint Connector for Email.

Explanation:
In this scenario, the best approach to satisfy the API-led connectivity principles and support future scalability is:

Experience APIs:
Process API:
System API:

Why Option A is Correct:
This structure aligns with API-led connectivity principles by separating concerns across Experience, Process, and System layers. It provides flexibility for future notification channels and isolates each layer’s responsibility, making it easier to maintain and scale.
Explanation of Incorrect Options:

Option B lacks a separate System API for sending emails, which goes against the principle of isolating back-end functionality in System APIs.
Option C similarly lacks a dedicated System API, reducing flexibility and reusability.
Option D suggests creating multiple Process APIs for database retrieval, which adds unnecessary complexity and does not adhere to the single-orchestration principle typically followed in API-led design.

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.

What Mule application can have API policies applied by
Anypoint Platform to the endpoint exposed by that Mule application?
A) A Mule application that accepts requests over HTTP/1.x

A.

Option A

B.

Option B

C.

Option C

D.

Option D

A.

Option A

Explanation: Explanation
Correct Answer: Option A
*****************************************
>> Anypoint API Manager and API policies are applicable to all types of HTTP/1.x APIs.
>> They are not applicable to WebSocket APIs, HTTP/2 APIs and gRPC APIs
Reference: https://docs.mulesoft.com/api-manager/2.x/using-policies

What Anypoint Connectors support transactions?

A.

Database, JMS, VM

B.

Database, 3MS, HTTP

C.

Database, JMS, VM, SFTP

D.

Database, VM, File

A.

Database, JMS, VM

What are the major benefits of MuleSoft proposed IT Operating Model?

A.

1. Decrease the IT delivery gap
2. Meet various business demands without increasing the IT capacity
3. Focus on creation of reusable assets first. Upon finishing creation of all the possible
assets then inform the LOBs in the organization to start using them

B.

1. Decrease the IT delivery gap
2. Meet various business demands by increasing the IT capacity and forming various IT
departments
3. Make consumption of assets at the rate of production

C.

1. Decrease the IT delivery gap
2. Meet various business demands without increasing the IT capacity
3. Make consumption of assets at the rate of production

C.

1. Decrease the IT delivery gap
2. Meet various business demands without increasing the IT capacity
3. Make consumption of assets at the rate of production

Explanation: Explanation
Correct Answer:
1. Decrease the IT delivery gap
2. Meet various business demands without increasing the IT capacity
3. Make consumption of assets at the rate of production.
*****************************************
Reference: https://www.youtube.com/watch?v=U0FpYMnMjmM

Which two statements are true about the technology architecture of an Anypoint Virtual Private Cloud (VPC)?
(Choose 2 answers)

A. Ports 8081 and 8082 are used

B. CIDR blacks are used

C. Anypoint VPC is responsible for load balancing the applications

D. Round-robin load balancing is used to distribute client requests across different applications

E. By default, HTTP requests can be made from the public internet to workers at port 6091

B. CIDR blacks are used

E. By default, HTTP requests can be made from the public internet to workers at port 6091

Explanation:
An Anypoint Virtual Private Cloud (VPC) provides a secure and private networking environment for MuleSoft applications, using specific architectural elements:

CIDR Blocks
Port 6091 for HTTP Requests
Explanation of Correct Answers (B, E)
Explanation of Incorrect Options

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.

Refer to the exhibit.

What is the best way to decompose one end-to-end business process into a collaboration of Experience, Process, and System APIs?
A) Handle customizations for the end-user application at the Process API level rather than the Experience API level
B) Allow System APIs to return data that is NOT currently required by the identified Process or Experience APIs
C) Always use a tiered approach by creating exactly one API for each of the 3 layers (Experience, Process and System APIs)
D) Use a Process API to orchestrate calls to multiple System APIs, but NOT to other Process APIs

A. Option A

B. Option B

C. Option C

D. Option D

B. Option B

Explanation:
Correct Answer: Allow System APIs to return data that is NOT currently required by the identified Process or Experience APIs.

All customizations for the end-user application should be handled in "Experience API" only. Not in Process API
We should use tiered approach but NOT always by creating exactly one API for each of the 3 layers. Experience APIs might be one but Process APIs and System APIs are often more than one. System APIs for sure will be more than one all the time as they are the smallest modular APIs built in front of end systems.
Process APIs can call System APIs as well as other Process APIs. There is no such anti-design pattern in API-Led connectivity saying Process APIs should not call other Process APIs.

So, the right answer in the given set of options that makes sense as per API-Led connectivity principles is to allow System APIs to return data that is NOT currently required by the identified Process or Experience APIs. This way, some future Process APIs can make use of that data from System APIs and we need NOT touch the System layer APIs again and again.