Mulesoft MCPA-Level-1 Exam Questions

What API policy would LEAST likely be applied to a Process API?

A.

Custom circuit breaker

B.

Client ID enforcement

C.

Rate limiting

D.

JSON threat protection

D.

JSON threat protection

Explanation: Explanation
Correct Answer: JSON threat protection
*****************************************
Fact: Technically, there are no restrictions on what policy can be applied in what layer. Any
policy can be applied on any layer API. However, context should also be considered
properly before blindly applying the policies on APIs.
That is why, this question asked for a policy that would LEAST likely be applied to a
Process API.
From the given options:
>> All policies except "JSON threat protection" can be applied without hesitation to the
APIs in Process tier.
>> JSON threat protection policy ideally fits for experience APIs to prevent suspicious
JSON payload coming from external API clients. This covers more of a security aspect by
trying to avoid possibly malicious and harmful JSON payloads from external clients calling
experience APIs.
As external API clients are NEVER allowed to call Process APIs directly and also these
kind of malicious and harmful JSON payloads are always stopped at experience API layer
only using this policy, it is LEAST LIKELY that this same policy is again applied on Process
Layer API.

A company stores financial transaction data in two legacy systems. For each legacy system, a separate, dedicated System API (SAPI) exposes data for that legacy system. A Process API (PAPI) merges the data retrieved from ail of the System APIs into a common format. Several API clients call the PAPI through its public domain name.
The company now wants to expose a subset of financial data to a newly developed mobile application that uses a different Bounded Context Data Model. The company wants to follow MuleSoft's best practices for building out an effective application network.
Following MuleSoft's best practices, how can the company expose financial data needed by the mobile application in a way that minimizes the impact on the currently running API clients, API implementations, and support asset reuse?

A. Add two new Experience APIs (EAPI-i and EAPI-2}.
Add Mobile PAPI-2 to expose the Intended subset of financial data as requested.
Both PAPIs access the Legacy Systems via SAPI-1 and SAP]-2.

B. Add two new Experience APIs (EAPI-i and EAPI-2}.
Add Mobile PAPI-2 to expose the Intended subset of financial data as requested.
Both PAPIs access the Legacy Systems via SAPI-1 and SAP]-2.

C. Create a new mobile Experince API (EAPI) chat exposes that subset of PAPI endpoints.
Add transformtion login to the mobile Experince API implementation to make mobile data compatible with the required PAPIs.

D. Develop and deploy is new PAPI implementation with data transformation and ... login to support this required endpoints of both mobile and web clients.
Deploy an API Proxy with an endpoint from API Manager that redirect the existing PAPI endpoints to the new PAPI.

A. Add two new Experience APIs (EAPI-i and EAPI-2}.
Add Mobile PAPI-2 to expose the Intended subset of financial data as requested.
Both PAPIs access the Legacy Systems via SAPI-1 and SAP]-2.

Explanation:
To achieve the goal of exposing financial data to a new mobile application while following MuleSoft’s best practices, the company should follow an API-led connectivity approach.
This approach ensures minimal disruption to existing clients, maximizes reusability, and respects the separation of concerns across API layers.
Explanation of Solution:
Experience APIs for Client-Specific Requirements:
Process API Layer for Data Transformation:
Reuse of System APIs:
Why Option A is Correct:
Explanation of Incorrect Options:
Option B: This option seems similar but lacks clarity on the separation of mobilespecific requirements and does not explicitly mention data transformation, which is essential in this scenario.
Option C: Creating a single mobile Experience API that exposes a subset of PAPI endpoints directly adds unnecessary complexity and may violate the separation of concerns, as transformation logic should not be in the Experience layer.
Option D: Deploying a new PAPI and using an API Proxy to redirect existing endpoints would add unnecessary complexity, disrupt the current API clients, and increase maintenance efforts.
References:
For additional guidance, refer to MuleSoft documentation on API-led connectivity best practices and best practices for structuring Experience, Process, and System APIs.

An organization wants to create a Center for Enablement (C4E). The IT director schedules a series of meetings with IT senior managers. What should be on the agenda of the first meeting?

A. Define C4E objectives, mission statement, guiding principles, a

B. Explore API monetization options based on identified use cases through MuleSoft

C. A walk through of common-services best practices for logging, auditing, exception handling, caching, security via policy, and rate limiting/throttling via policy

D. Specify operating model for the MuleSoft Integrations division

A. Define C4E objectives, mission statement, guiding principles, a

Explanation:
In the initial meeting for establishing a Center for Enablement (C4E), it’s essential to lay the foundational vision, objectives, and guiding principles for the team.
Here’s why this is crucial:

Clear Vision and Mission:
Guiding Principles:
Explanation of Correct Answer (A):
Explanation of Incorrect Options:

References:
For more on C4E objectives and foundational setup, refer to MuleSoft’s documentation on establishing a C4E and the roles and mission statements recommended for such initiatives.

An API implementation is deployed to CloudHub.
What conditions can be alerted on using the default Anypoint Platform functionality, where
the alert conditions depend on the end-to-end request processing of the API
implementation?

A.

When the API is invoked by an unrecognized API client

B.

When a particular API client invokes the API too often within a given time period

C.

When the response time of API invocations exceeds a threshold

D.

When the API receives a very high number of API invocations

C.

When the response time of API invocations exceeds a threshold

Explanation: Explanation
Correct Answer: When the response time of API invocations exceeds a threshold
*****************************************
>> Alerts can be setup for all the given options using the default Anypoint Platform
functionality
>> However, the question insists on an alert whose conditions depend on the end-to-end
request processing of the API implementation.
>> Alert w.r.t "Response Times" is the only one which requires end-to-end request
processing of API implementation in order to determine if the threshold is exceeded or not.
Reference: https://docs.mulesoft.com/api-manager/2.x/using-api-alerts

A TemperatureSensors API instance is defined in API Manager in the PROD environment of the CAR_FACTORY business group. An AcmelemperatureSensors Mule application implements this API instance and is deployed from Runtime Manager to the PROD environment of the CAR_FACTORY business group. A policy that requires a valid client ID and client secret is applied in API Manager to the API instance.
Where can an API consumer obtain a valid client ID and client secret to call the AcmeTemperatureSensors Mule application?

A. In secrets manager, request access to the Shared Secret static username/password

B. In API Manager, from the PROD environment of the CAR_FACTORY business group

C. In access management, from the PROD environment of the CAR_FACTORY business group

D. In Anypoint Exchange, from an API client application that has been approved for the TemperatureSensors API instance

Explanation:
When an API policy requiring a client ID and client secret is applied to an API instance in API Manager, API consumers must obtain these credentials through a registered client application. Here’s how it works:

Anypoint Exchange and Client Applications:
Why Option D is Correct:
Explanation of Incorrect Options:

The asset version 2.0.0 of the Order API is successfully published in Exchange and configured in API Manager with the Autodiscovery API ID correctly linked to the API implementation, A new GET method is added to the existing API specification, and after updates, the asset version of the Order API is 2.0.1. What happens to the Autodiscovery API ID when the new asset version is updated in API Manager?

A. The API ID changes, but no changes are needed to the API implementation for the new asset version in the API Autediscovery global element because the API ID is automatically updated

B. The APL ID changes, so the API implementation must be updated with the latest API ID for the new asset version in the API Autodiscovery global element

C. The APLID does not change, so no changes to the APT implementation are needed for the new asset version in the API Autodiscovery global element

D. The APL ID does not change, but the API implementation must be updated in the AP] Autodiscovery global element to indicate the new asset version 2.0.4

C. The APLID does not change, so no changes to the APT implementation are needed for the new asset version in the API Autodiscovery global element

Explanation:
Understanding API Autodiscovery in MuleSoft:
Effect of Asset Version Update on API Autodiscovery:
Evaluating the Options:

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.

Refer to the exhibit.

A.

Option A

B.

Option B

C.

Option C

D.

Option D

A.

Option A

Explanation: Explanation
Correct Answer: Ask the Marketing Department to interact with a mocking implementation
of the API using the automatically generated API Console.
*****************************************
As per MuleSoft's IT Operating Model:
>> API consumers need NOT wait until the full API implementation is ready.
>> NO technical test-suites needs to be shared with end users to interact with APIs.
>> Anypoint Platform offers a mocking capability on all the published API specifications to
Anypoint Exchange which also will be rich in documentation covering all details of API
functionalities and working nature.
>> No needs of arranging days of workshops with end users for feedback.
API consumers can use Anypoint Exchange features on the platform and interact with the
API using its mocking feature. The feedback can be shared quickly on the same to
incorporate any changes.