Mulesoft MCPA-Level-1 Exam Questions

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.

Three business processes need to be implemented, and the implementations need to communicate with several different SaaS applications.
These processes are owned by separate (siloed) LOBs and are mainly independent of each other, but do share a few business entities. Each LOB has one development team and their own budget.
In this organizational context, what is the most effective approach to choose the API data models for the APIs that will implement these business processes with minimal redundancy of the data models?
A) Build several Bounded Context Data Models that align with coherent parts of the business processes and the definitions of associated business entities.
B) Build distinct data models for each API to follow established micro-services and Agile API-centric practices
C) Build all API data models using XML schema to drive consistency and reuse across the organization
D) Build one centralized Canonical Data Model (Enterprise Data Model) that unifies all the data types from all three business processes, ensuring the data model is consistent and non-redundant

A. Option A

B. Option B

C. Option C

D. Option D

A. Option A

Explanation:

Correct Answer: Build several Bounded Context Data Models that align with coherent parts of the business processes and the definitions of associated business entities.

The options w.r.t building API data models using XML schema/ Agile API-centric practices are irrelevant to the scenario given in the question. So these two are INVALID.
Building EDM (Enterprise Data Model) is not feasible or right fit for this scenario as the teams and LOBs work in silo and they all have different initiatives, budget etc.. Building EDM needs intensive coordination among all the team which evidently seems not possible in this scenario.

So, the right fit for this scenario is to build several Bounded Context Data Models that align with coherent parts of the business processes and the definitions of associated business entities.

What is true about the technology architecture of Anypoint VPCs?

A.

The private IP address range of an Anypoint VPC is automatically chosen by CloudHub

B.

Traffic between Mule applications deployed to an Anypoint VPC and on-premises
systems can stay within a private network

C.

Each CloudHub environment requires a separate Anypoint VPC

D.

VPC peering can be used to link the underlying AWS VPC to an on-premises (non
AWS) private network

B.

Traffic between Mule applications deployed to an Anypoint VPC and on-premises
systems can stay within a private network

Explanation: Explanation
Correct Answer: Traffic between Mule applications deployed to an Anypoint VPC and onpremises
systems can stay within a private network
*****************************************
>> The private IP address range of an Anypoint VPC is NOT automatically chosen by
CloudHub. It is chosen by us at the time of creating VPC using thr CIDR blocks.
CIDR Block: The size of the Anypoint VPC in Classless Inter-Domain Routing (CIDR)
notation.
For example, if you set it to 10.111.0.0/24, the Anypoint VPC is granted 256 IP addresses
from 10.111.0.0 to 10.111.0.255.
Ideally, the CIDR Blocks you choose for the Anypoint VPC come from a private IP space,
and should not overlap with any other Anypoint VPC’s CIDR Blocks, or any CIDR Blocks in
use in your corporate network.

What is most likely NOT a characteristic of an integration test for a REST API
implementation?

A.

The test needs all source and/or target systems configured and accessible

B.

The test runs immediately after the Mule application has been compiled and packaged

C.

The test is triggered by an external HTTP request

D.

The test prepares a known request payload and validates the response payload

B.

The test runs immediately after the Mule application has been compiled and packaged

Explanation: Explanation
Correct Answer: The test runs immediately after the Mule application has been compiled
and packaged
*****************************************
>> Integration tests are the last layer of tests we need to add to be fully covered.
>> These tests actually run against Mule running with your full configuration in place and are tested from external source as they work in PROD.
>> These tests exercise the application as a whole with actual transports enabled. So,
external systems are affected when these tests run.
So, these tests do NOT run immediately after the Mule application has been compiled and
packaged.
FYI... Unit Tests are the one that run immediately after the Mule application has been
compiled and packaged.
Reference: https://docs.mulesoft.com/mule-runtime/3.9/testing-strategies#integrationtesting

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.

An enterprise is embarking on the API-led digital transformation journey, and the central IT team has started to define System APIs. Currently there is no Enterprise Data Model being defined within the enterprise, and the definition of a clean Bounded Context Data Model requires too much effort. According to MuleSoft's recommended guidelines, how should the System API data model be defined?

A. If there are misspellings of the data fields in the back-end system, Systerm APIs should not correct it, and expose it as-is to mirror the back-end systems

B. The data model of the System APIs should make use of data types that approximately mirror those from the back-end systems

C. The data model should define its own naming convention, and not follow the same naming as the back-end systems

D. The System APIs should expose all back-end system fields

B. The data model of the System APIs should make use of data types that approximately mirror those from the back-end systems

Explanation: When defining data models for System APIs without an established Enterprise Data Model, MuleSoft recommends mirroring the back-end systems' data types to achieve quick and effective integration without adding complexity. This approach has several benefits:

Alignment with Backend Systems:
Flexibility for Future Enhancements:
Explanation of Incorrect Options:

An organization makes a strategic decision to move towards an IT operating model that emphasizes consumption of reusable IT assets using modern APIs (as defined by MuleSoft). What best describes each modern API in relation to this new IT operating model?

A.

Each modern API has its own software development lifecycle, which reduces the need for documentation and automation

B.

Each modem API must be treated like a product and designed for a particular target audience (for instance, mobile app developers)

C.

Each modern API must be easy to consume, so should avoid complex authentication mechanisms such as SAML or JWT D

D.

Each modern API must be REST and HTTP based

B.

Each modem API must be treated like a product and designed for a particular target audience (for instance, mobile app developers)

Explanation: Explanation
Correct Answers:
1. Each modern API must be treated like a product and designed for a particular target
audience (for instance mobile app developers)
*****************************************

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