Mulesoft MCPA-Level-1 Exam Questions

A Platform Architect inherits a legacy monolithic SOAP-based web service that performs a number of tasks, including showing all policies belonging to a client. The service connects to two back-end systems — a life-insurance administration system and a general-insurance administration system — and then queries for insurance policy information within each system, aggregates the results, and presents a SOAP-based response to a user interface (UI). The architect wants to break up the monolithic web service to follow API-led conventions. Which part of the service should be put into the process layer?

A. Combining the insurance policy information from the administration systems

B. Presenting the SOAP-based response to the UI

C. Authenticating and maintaining connections to each of the back-end administration systems

D. Querying the data from the administration systems

A. Combining the insurance policy information from the administration systems

Explanation:
In the API-led connectivity approach, each layer (System, Process, and Experience) has a distinct purpose:

System APIs: These APIs connect directly to backend systems to expose and unlock data in a standardized way.
Process APIs: These are responsible for orchestrating and processing data across different systems, combining information where needed.
Experience APIs: These are designed for specific user interfaces or applications, often transforming data formats to fit the needs of each consumer application.

Why Option A is Correct:

Process APIs are designed to combine data from multiple systems, which aligns with the function of aggregating policy information from both the life and general insurance systems. This aggregation logic would ideally reside in the Process layer, separating data retrieval from data orchestration.
Moving this functionality to the Process layer enables reusability and modularity, as other Experience APIs or services could also leverage the combined policy data if needed.

Explanation of Incorrect Options:

Option B (Presenting the SOAP-based response) would be managed by the Experience layer, as this layer adapts data formats for specific interfaces.
Option C (Authenticating and maintaining backend connections) would typically be handled within the System layer, where backend integration and security handling occurs.
Option D (Querying data) is the function of System APIs, which access the backend systems directly and expose the raw data without additional processing.

A company deployed an API to a single worker/replica in the shared cloud in the U.S. West Region. What happens when the Availability Zone experiences an outage?

A. CloudHub will auto-redeploy the APL in the U.S. East Region

B. The APT will be unavailable until the availability comes back online, at which time the worker/replica will be auto-restarted

C. CloudHub will auto-redeploy the API in another Availability Zone in the U.S. West Region

D. The Anypoint Platform admin is alerted when the AP] is experiencing an outage and needs the trigger the CI/CD pipeline to redeploy to the US. East Region

B. The APT will be unavailable until the availability comes back online, at which time the worker/replica will be auto-restarted

Explanation:
In a CloudHub deployment with a single worker/replica located in a specific Availability Zone (AZ), if an AZ experiences an outage, here’s what happens:
Worker Availability: Since the application is deployed in a single AZ, CloudHub does not automatically redeploy the application in a different zone or region during an outage. Thus, if the current AZ is unavailable, the application will be offline.
Auto-Restart upon AZ Recovery: Once the affected AZ is back online, CloudHub will auto-restart the worker in the same AZ without manual intervention. This ensures that as soon as the AZ is functional, the application resumes automatically.

An organization wants to make sure only known partners can invoke the organization's
APIs. To achieve this security goal, the organization wants to enforce a Client ID
Enforcement policy in API Manager so that only registered partner applications can invoke
the organization's APIs. In what type of API implementation does MuleSoft recommend
adding an API proxy to enforce the Client ID Enforcement policy, rather than embedding
the policy directly in the application's JVM?

A.

A Mule 3 application using APIkit

B.

A Mule 3 or Mule 4 application modified with custom Java code

C.

A Mule 4 application with an API specification

D.

A Non-Mule application

D.

A Non-Mule application

Explanation: Explanation
Correct Answer: A Non-Mule application
*****************************************
>> All type of Mule applications (Mule 3/ Mule 4/ with APIkit/ with Custom Java Code etc)
running on Mule Runtimes support the Embedded Policy Enforcement on them.
>> The only option that cannot have or does not support embedded policy enforcement
and must have API Proxy is for Non-Mule Applications.
So, Non-Mule application is the right answer

What do the API invocation metrics provided by Anypoint Platform provide?

A.

ROI metrics from APIs that can be directly shared with business users

B.

Measurements of the effectiveness of the application network based on the level of reuse

C.

Data on past API invocations to help identify anomalies and usage patterns across various APIs

D.

Proactive identification of likely future policy violations that exceed a given threat
threshold

C.

Data on past API invocations to help identify anomalies and usage patterns across various APIs

Explanation: Explanation
Correct Answer: Data on past API invocations to help identify anomalies and usage
patterns across various APIs
*****************************************
API Invocation metrics provided by Anypoint Platform:
>> Does NOT provide any Return Of Investment (ROI) related information. So the option
suggesting it is OUT.
>> Does NOT provide any information w.r.t how APIs are reused, whether there is effective
usage of APIs or not etc...
>> Does NOT prodive any prediction information as such to help us proactively identify any
future policy violations.
So, the kind of data/information we can get from such metrics is on past API invocations to
help identify anomalies and usage patterns across various APIs.
Reference:
https://usermanual.wiki/Document/APAAppNetstudentManual02may2018.991784750.pdf

What is a best practice when building System APIs?

A.

Document the API using an easily consumable asset like a RAML definition

B.

Model all API resources and methods to closely mimic the operations of the backend system

C.

Build an Enterprise Data Model (Canonical Data Model) for each backend system and apply it to System APIs

D.

Expose to API clients all technical details of the API implementation's interaction wifch
the backend system

B.

Model all API resources and methods to closely mimic the operations of the backend system

Explanation: Explanation
Correct Answer: Model all API resources and methods to closely mimic the operations of
the backend system.
*****************************************
>> There are NO fixed and straight best practices while opting data models for APIs. They
are completly contextual and depends on number of factors. Based upon those factors, an
enterprise can choose if they have to go with Enterprise Canonical Data Model or Bounded
Context Model etc.
>> One should NEVER expose the technical details of API implementation to their API
clients. Only the API interface/ RAML is exposed to API clients.
>> It is true that the RAML definitions of APIs should be as detailed as possible and should
reflect most of the documentation. However, just that is NOT enough to call your API as
best documented API. There should be even more documentation on Anypoint Exchange
with API Notebooks etc. to make and create a developer friendly API and repository..
>> The best practice always when creating System APIs is to create their API interfaces by
modeling their resources and methods to closely reflect the operations and functionalities
of that backend system.

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

An organization is implementing a Quote of the Day API that caches today's quote.
What scenario can use the GoudHub Object Store via the Object Store connector to persist
the cache's state?

A.

When there are three CloudHub deployments of the API implementation to three
separate CloudHub regions that must share the cache state

B.

When there are two CloudHub deployments of the API implementation by two Anypoint
Platform business groups to the same CloudHub region that must share the cache state

C.

When there is one deployment of the API implementation to CloudHub and anottV
deployment to a customer-hosted Mule runtime that must share the cache state

D.

When there is one CloudHub deployment of the API implementation to three CloudHub
workers that must share the cache state

D.

When there is one CloudHub deployment of the API implementation to three CloudHub
workers that must share the cache state

Explanation: Explanation
Correct Answer: When there is one CloudHub deployment of the API implementation to
three CloudHub workers that must share the cache state.
*****************************************
Key details in the scenario:
>> Use the CloudHub Object Store via the Object Store connector
Considering above details:
>> CloudHub Object Stores have one-to-one relationship with CloudHub Mule Applications.
>> We CANNOT use an application's CloudHub Object Store to be shared among multiple
Mule applications running in different Regions or Business Groups or Customer-hosted
Mule Runtimes by using Object Store connector.
>> If it is really necessary and very badly needed, then Anypoint Platform supports a way
by allowing access to CloudHub Object Store of another application using Object Store
REST API. But NOT using Object Store connector.
So, the only scenario where we can use the CloudHub Object Store via the Object Store
connector to persist the cache’s state is when there is one CloudHub deployment of the
API implementation to multiple CloudHub workers that must share the cache state

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.