Mulesoft MCPA-Level-1 Exam Questions

How can the application of a rate limiting API policy be accurately reflected in the RAML definition of an API?

A.

By refining the resource definitions by adding a description of the rate limiting policy behavior

B.

By refining the request definitions by adding a remaining Requests query parameter with description, type, and example

C.

By refining the response definitions by adding the out-of-the-box Anypoint Platform ratelimit-
enforcement securityScheme with description, type, and example

D.

By refining the response definitions by adding the x-ratelimit-* response headers with
description, type, and example

D.

By refining the response definitions by adding the x-ratelimit-* response headers with
description, type, and example

Explanation: Explanation
Correct Answer: By refining the response definitions by adding the x-ratelimit-* response
headers with description, type, and example
*****************************************

When can CloudHub Object Store v2 be used?

A. To store an unlimited number of key-value pairs

B. To store payloads with an average size greater than 15MB

C. To store information in Mule 4 Object Store v1

D. To store key-value pairs with keys up to 300 characters

Explanation: CloudHub Object Store v2 is a managed key-value store provided by MuleSoft to support various use cases where temporary data storage is required. Here’s why Option D is correct:
Key Length Support: Object Store v2 allows storage of keys with a length of up to 300 characters, making it suitable for applications needing flexible and descriptive keys.
Limitations on Size:
Key-Value Limits: Object Store v2 is designed for moderate, transient storage needs, and does not support unlimited storage. Thus, Option A is incorrect.
Backward Compatibility: Object Store v2 does not support Mule 4 applications running Object Store v1. Option C is incorrect as Object Store v1 and v2 are distinct.

What Anypoint Platform Capabilities listed below fall under APIs and API
Invocations/Consumers category? Select TWO.

A.

API Operations and Management

B.

API Runtime Execution and Hosting

C.

API Consumer Engagement

D.

API Design and Development

D.

API Design and Development

Explanation: Explanation
Correct Answers: API Design and Development and API Runtime Execution and Hosting
*****************************************
>> API Design and Development - Anypoint Studio, Anypoint Design Center, Anypoint
Connectors
>> API Runtime Execution and Hosting - Mule Runtimes, CloudHub, Runtime Services
>> API Operations and Management - Anypoint API Manager, Anypoint Exchange
>> API Consumer Management - API Contracts, Public Portals, Anypoint Exchange, API
Notebooks

A client has several applications running on the Salesforce service cloud. The business requirement for integration is to get daily data changes from Account and Case Objects. Data needs to be moved to the client's private cloud AWS DynamoDB instance as a single JSON and the business foresees only wanting five attributes from the Account object, which has 219 attributes (some custom) and eight attributes from the Case Object. What design should be used to support the API/ Application data model?

A. Create separate entities for Account and Case Objects by mimicking all the attributes in SAPI, which are combined by the PAPI and filtered to provide JSON output containing 13 attributes.

B. Request client’s AWS project team to replicate all the attributes and create Account and Case JSON table in DynamoDB. Then create separate entities for Account and Case Objects by mimicking all the attributes in SAPI to transfer ISON data to DynamoD for respective Objects

C. Start implementing an Enterprise Data Model by defining enterprise Account and Case Objects and implement SAPI and DynamoDB tables based on the Enterprise Data Model,

D. Create separate entities for Account with five attributes and Case with eight attributes in SAPI, which are combined by the PAPI to provide JSON output containing 13 attributes.

A company uses a hybrid Anypoint Platform deployment model that combines the EU
control plane with customer-hosted Mule runtimes. After successfully testing a Mule API
implementation in the Staging environment, the Mule API implementation is set with
environment-specific properties and must be promoted to the Production environment.
What is a way that MuleSoft recommends to configure the Mule API implementation and
automate its promotion to the Production environment?

A.

Bundle properties files for each environment into the Mule API implementation's deployable
archive, then promote the Mule API implementation to the Production environment using
Anypoint CLI or the Anypoint Platform REST APIsB.

B.

Modify the Mule API implementation's properties in the API Manager Properties tab, then
promote the Mule API implementation to the Production environment using API Manager

C.

Modify the Mule API implementation's properties in Anypoint Exchange, then promote the
Mule API implementation to the Production environment using Runtime Manager

D.

Use an API policy to change properties in the Mule API implementation deployed to the
Staging environment and another API policy to deploy the Mule API implementation to the
Production environment

A.

Bundle properties files for each environment into the Mule API implementation's deployable
archive, then promote the Mule API implementation to the Production environment using
Anypoint CLI or the Anypoint Platform REST APIsB.

Explanation: Explanation
Correct Answer: Bundle properties files for each environment into the Mule API
implementation's deployable archive, then promote the Mule API implementation to the
Production environment using Anypoint CLI or the Anypoint Platform REST APIs
*****************************************
>> Anypoint Exchange is for asset discovery and documentation. It has got no provision to
modify the properties of Mule API implementations at all.
>> API Manager is for managing API instances, their contracts, policies and SLAs. It has
also got no provision to modify the properties of API implementations.
>> API policies are to address Non-functional requirements of APIs and has again got no
provision to modify the properties of API implementations.
So, the right way and recommended way to do this as part of development practice is to
bundle properties files for each environment into the Mule API implementation and just
point and refer to respective file per environment.

An API has been updated in Anypoint exchange by its API producer from version 3.1.1 to
3.2.0 following accepted semantic versioning practices and the changes have been
communicated via the APIs public portal. The API endpoint does NOT change in the new
version. How should the developer of an API client respond to this change?

A.

The API producer should be requested to run the old version in parallel with the new one

B.

The API producer should be contacted to understand the change to existing functionality

C.

The API client code only needs to be changed if it needs to take advantage of the new features

D.

The API clients need to update the code on their side and need to do full regression

C.

The API client code only needs to be changed if it needs to take advantage of the new features

Which three tools automate the deployment of Mule applications? (Choose 3 answers)

A. Runtime Manager

B. Anypoint Platform CLI

C. Platform APIs

D. Anypoint Studio

E. Mule Mayen plugin

F. API Community Manager

A.   Runtime Manager

B.   Anypoint Platform CLI

C.   Platform APIs

Explanation:
MuleSoft offers various tools to automate the deployment of Mule applications, which can streamline deployment and management processes. Here’s how each tool supports automated deployment:

Runtime Manager:
Anypoint Platform CLI:
Platform APIs:
Explanation of Incorrect Options:

References:
For detailed steps on automating deployments with these tools, refer to MuleSoft documentation on Runtime Manager, CLI, and Platform APIs.

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.