Mulesoft MCPA-Level-1 Exam Questions

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:

An established communications company is beginning its API-led connectivity journey, The company has been using a successful Enterprise Data Model for many years. The company has identified a self-service account management app as the first effort for APIled, and it has identified the following APIs.

Experience layer: Mobile Account Management EAPI, Browser Account Management EAPI
Process layer: Customer Lookup PAPI, Service Lookup PAPI, Account Lookup PAPI
System layer: Customer SAPI, Account SAPI, Product SAPI, Service SAPI

According to MuleSoft's API-led connectivity approach, which API would not be served by the Enterprise Data Model?

A. Customer SAPI

B. Customer Lookup PAPI

C. Mobile Account Management EAPI

D. Service SAPI

C. Mobile Account Management EAPI

Explanation: In the API-led connectivity approach, APIs are categorized into Experience, Process, and System layers:
Enterprise Data Model Scope:
Why Option C is Correct:
Explanation of Incorrect Options:
References:
For additional guidance, review MuleSoft's best practices on API-led connectivity and data modeling.

What is the most performant out-of-the-box solution in Anypoint Platform to track
transaction state in an asynchronously executing long-running process implemented as a
Mule application deployed to multiple CloudHub workers?

A.

Redis distributed cache

B.

java.util.WeakHashMap

C.

Persistent Object Store

D.

File-based storage

C.

Persistent Object Store

Explanation: Correct Answer: Persistent Object Store
*****************************************
>> Redis distributed cache is performant but NOT out-of-the-box solution in Anypoint
Platform
>> File-storage is neither performant nor out-of-the-box solution in Anypoint Platform
>> java.util.WeakHashMap needs a completely custom implementation of cache from
scratch using Java code and is limited to the JVM where it is running. Which means the
state in the cache is not worker aware when running on multiple workers. This type of
cache is local to the worker. So, this is neither out-of-the-box nor worker-aware among
multiple workers on cloudhub. https://www.baeldung.com/java-weakhashmap
>> Persistent Object Store is an out-of-the-box solution provided by Anypoint Platform
which is performant as well as worker aware among multiple workers running on
CloudHub. https://docs.mulesoft.com/object-store/
So, Persistent Object Store is the right answer.

What is a key requirement when using an external Identity Provider for Client Management in Anypoint Platform?

A.

Single sign-on is required to sign in to Anypoint Platform

B.

The application network must include System APIs that interact with the Identity
Provider

C.

To invoke OAuth 2.0-protected APIs managed by Anypoint Platform, API clients must submit access tokens issued by that same Identity Provider

D.

APIs managed by Anypoint Platform must be protected by SAML 2.0 policies

C.

To invoke OAuth 2.0-protected APIs managed by Anypoint Platform, API clients must submit access tokens issued by that same Identity Provider

Explanation: https://www.folkstalk.com/2019/11/mulesoft-integration-and-platform.html
Explanation
Correct Answer: To invoke OAuth 2.0-protected APIs managed by Anypoint Platform, API
clients must submit access tokens issued by that same Identity Provider
*****************************************
>> It is NOT necessary that single sign-on is required to sign in to Anypoint Platform
because we are using an external Identity Provider for Client Management
>> It is NOT necessary that all APIs managed by Anypoint Platform must be protected by
SAML 2.0 policies because we are using an external Identity Provider for Client
Management
>> Not TRUE that the application network must include System APIs that interact with the
Identity Provider because we are using an external Identity Provider for Client Management
Only TRUE statement in the given options is - "To invoke OAuth 2.0-protected APIs
managed by Anypoint Platform, API clients must submit access tokens issued by that same
Identity Provider"
References:
https://docs.mulesoft.com/api-manager/2.x/external-oauth-2.0-token-validation-policy
https://blogs.mulesoft.com/dev/api-dev/api-security-ways-to-authenticate-and-authorize/

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.

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

C.

System Layer

Explanation: Explanation
Correct Answer: System Layer

What correctly characterizes unit tests of Mule applications?

A.

They test the validity of input and output of source and target systems

B.

They must be run in a unit testing environment with dedicated Mule runtimes for the environment

C.

They must be triggered by an external client tool or event source

D.

They are typically written using MUnit to run in an embedded Mule runtime that does not require external connectivity

D.

They are typically written using MUnit to run in an embedded Mule runtime that does not require external connectivity

Explanation: Explanation
Correct Answer: They are typically written using MUnit to run in an embedded Mule runtime
that does not require external connectivity.
*****************************************
Below TWO are characteristics of Integration Tests but NOT unit tests:
>> They test the validity of input and output of source and target systems.
>> They must be triggered by an external client tool or event source.
It is NOT TRUE that Unit Tests must be run in a unit testing environment with dedicated
Mule runtimes for the environment.
MuleSoft offers MUnit for writing Unit Tests and they run in an embedded Mule Runtime
without needing any separate/ dedicated Runtimes to execute them. They also do NOT
need any external connectivity as MUnit supports mocking via stubs.
https://dzone.com/articles/munit-framework

What is true about automating interactions with Anypoint Platform using tools such as Anypoint Platform REST APIs, Anypoint CU, or the Mule Maven plugin?

A.

Access to Anypoint Platform APIs and Anypoint CU can be controlled separately through the roles and permissions in Anypoint Platform, so that specific users can get access to Anypoint CLI white others get access to the platform APIs

B.

Anypoint Platform APIs can ONLY automate interactions with CloudHub, while the Mule Maven plugin is required for deployment to customer-hosted Mule runtimes

C.

By default, the Anypoint CLI and Mule Maven plugin are NOT included in the Mule runtime, so are NOT available to be used by deployed Mule applications

D.

API policies can be applied to the Anypoint Platform APIs so that ONLY certain LOBs have access to specific functions

C.

By default, the Anypoint CLI and Mule Maven plugin are NOT included in the Mule runtime, so are NOT available to be used by deployed Mule applications

Explanation: Explanation
Correct Answer: By default, the Anypoint CLI and Mule Maven plugin are NOT included in
the Mule runtime, so are NOT available to be used by deployed Mule applications
*****************************************
>> We CANNOT apply API policies to the Anypoint Platform APIs like we can do on our
custom written API instances. So, option suggesting this is FALSE.
>> Anypoint Platform APIs can be used for automating interactions with both CloudHub
and customer-hosted Mule runtimes. Not JUST the CloudHub. So, option opposing this is
FALSE.
>> Mule Maven plugin is NOT mandatory for deployment to customer-hosted Mule
runtimes. It just helps your CI/CD to have smoother automation. But not a compulsory
requirement to deploy. So, option opposing this is FALSE.
>> We DO NOT have any such special roles and permissions on the platform to separately
control access for some users to have Anypoint CLI and others to have Anypoint Platform
APIs. With proper general roles/permissions (API Owner, Cloudhub Admin etc..), one can
use any of the options (Anypoint CLI or Platform APIs). So, option suggesting this is
FALSE.
Only TRUE statement given in the choices is that - Anypoint CLI and Mule Maven plugin
are NOT included in the Mule runtime, so are NOT available to be used by deployed Mule
applications.
Maven is part of Studio or you can use other Maven installation for development.
CLI is convenience only. It is one of many ways how to install app to the runtime.
These are definitely NOT part of anything except your process of deployment or
automation.