Mulesoft MCPA-Level-1 Exam Questions

A System API is designed to retrieve data from a backend system that has scalability challenges. What API policy can best safeguard the backend system?

A.

IPwhitelist

B.

SLA-based rate limiting

C.

Auth 2 token enforcement

D.

Client ID enforcement

B.

SLA-based rate limiting

Explanation: Explanation
Correct Answer: SLA-based rate limiting
*****************************************
>> Client Id enforement policy is a "Compliance" related NFR and does not help in
maintaining the "Quality of Service (QoS)". It CANNOT and NOT meant for protecting the
backend systems from scalability challenges.
>> IP Whitelisting and OAuth 2.0 token enforcement are "Security" related NFRs and again
does not help in maintaining the "Quality of Service (QoS)". They CANNOT and are NOT
meant for protecting the backend systems from scalability challenges.
Rate Limiting, Rate Limiting-SLA, Throttling, Spike Control are the policies that are "Quality
of Service (QOS)" related NFRs and are meant to help in protecting the backend systems
from getting overloaded.
https://dzone.com/articles/how-to-secure-apis

What CANNOT be effectively enforced using an API policy in Anypoint Platform?

A.

Guarding against Denial of Service attacks

B.

Maintaining tamper-proof credentials between APIs

C.

Logging HTTP requests and responses

D.

Backend system overloading

A.

Guarding against Denial of Service attacks

Explanation: Explanation
Correct Answer: Guarding against Denial of Service attacks
*****************************************
>> Backend system overloading can be handled by enforcing "Spike Control Policy"
>> Logging HTTP requests and responses can be done by enforcing "Message Logging
Policy"
>> Credentials can be tamper-proofed using "Security" and "Compliance" Policies
However, unfortunately, there is no proper way currently on Anypoint Platform to guard
against DOS attacks.
Reference: https://help.mulesoft.com/s/article/DDos-Dos-at

A European company has customers all across Europe, and the IT department is migrating from an older platform to MuleSoft. The main requirements are that the new platform should allow redeployments with zero downtime and deployment of applications to multiple runtime versions, provide security and speed, and utilize Anypoint MQ as the message service. Which runtime plane should the company select based on the requirements without additional network configuration?

A. Runtime Fabric on VMs / Bare Metal for the runtime plane

B. Customer-hosted runtime plane

C. MuleSoft-hosted runtime plane (CloudHub)

D. Anypoint Runtime Fabric on Self-Managed Kubernetes for the runtime plane

C. MuleSoft-hosted runtime plane (CloudHub)

Explanation:
For a European company with requirements such as zero-downtime redeployment, deployment to multiple runtime versions, secure and fast performance, and the use of Anypoint MQ without additional network configuration, CloudHub is the best choice for the following reasons:

Zero-Downtime Redeployment: CloudHub supports zero-downtime deployment, which allows seamless redeployment of applications without impacting availability. Support for Multiple Runtime Versions: CloudHub allows deploying applications across different Mule runtime versions, giving flexibility to test and migrate applications as needed.
Integrated Anypoint MQ: Anypoint MQ, which is fully integrated with CloudHub, provides reliable messaging across applications. Choosing CloudHub removes the need for additional network configurations, as Anypoint MQ can be directly accessed in this hosted environment.
Security and Performance: CloudHub offers secure networking, automatic scaling, and optimized performance without requiring a complex setup. This is managed by MuleSoft’s infrastructure, meeting the speed and security requirements with minimal overhead.

Explanation of Incorrect Options:
References:
For more information on CloudHub’s capabilities regarding zero-downtime deployments and integration with Anypoint MQ, refer to MuleSoft documentation on CloudHub.

An operations team is analyzing the effort needed to set up monitoring of their application network. They are looking at which API invocation metrics can be used to identify and predict trouble without having to write custom scripts or install additional analytics software or tools. Which type of metrics can satisfy this goal of directly identifying and predicting failures?

A. The number and types of API policy violations per day

B. The effectiveness of the application network based on the level of reuse

C. The number and types of past API invocations across the application network

D. The ROI from each APT invocation

A. The number and types of API policy violations per day

Explanation:
To monitor an application network and predict issues without custom scripts, policy violation metrics are critical. They provide insights into potential problems by tracking instances where API usage does not conform to defined policies. Here’s why this approach is suitable:

Predictive Monitoring:
No Custom Scripting Needed:
Explanation of Incorrect Options:

When must an API implementation be deployed to an Anypoint VPC?

A.

When the API Implementation must invoke publicly exposed services that are deployed outside of CloudHub in a customer- managed AWS instance

B.

When the API implementation must be accessible within a subnet of a restricted customer-hosted network that does not allow public access

C.

When the API implementation must be deployed to a production AWS VPC using the Mule Maven plugin

D.

When the API Implementation must write to a persistent Object Store

A.

When the API Implementation must invoke publicly exposed services that are deployed outside of CloudHub in a customer- managed AWS instance

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.

Due to a limitation in the backend system, a system API can only handle up to 500
requests per second. What is the best type of API policy to apply to the system API to avoid overloading the backend system?

A.

Rate limiting

B.

HTTP caching

C.

Rate limiting - SLA based

D.

Spike control

D.

Spike control

Explanation: Explanation
Correct Answer: Spike control
*****************************************
>> First things first, HTTP Caching policy is for purposes different than avoiding the
backend system from overloading. So this is OUT.
>> Rate Limiting and Throttling/ Spike Control policies are designed to limit API access, but
have different intentions.
>> Rate limiting protects an API by applying a hard limit on its access.
>> Throttling/ Spike Control shapes API access by smoothing spikes in traffic.
That is why, Spike Control is the right option

What API policy would be LEAST LIKELY used when designing an Experience API that is intended to work with a consumer mobile phone or tablet application?

A.

OAuth 2.0 access token enforcement

B.

Client ID enforcement

C.

JSON threat protection

D.

IPwhitellst

D.

IPwhitellst

Explanation: Explanation
Correct Answer: IP whitelist
*****************************************
>> OAuth 2.0 access token and Client ID enforcement policies are VERY common to apply
on Experience APIs as API consumers need to register and access the APIs using one of
these mechanisms
>> JSON threat protection is also VERY common policy to apply on Experience APIs to
prevent bad or suspicious payloads hitting the API implementations.
>> IP whitelisting policy is usually very common in Process and System APIs to only
whitelist the IP range inside the local VPC. But also applied occassionally on some
experience APIs where the End User/ API Consumers are FIXED.
>> When we know the API consumers upfront who are going to access certain Experience
APIs, then we can request for static IPs from such consumers and whitelist them to prevent
anyone else hitting the API.
However, the experience API given in the question/ scenario is intended to work with a
consumer mobile phone or tablet application. Which means, there is no way we can know
all possible IPs that are to be whitelisted as mobile phones and tablets can so many in
number and any device in the city/state/country/globe.
So, It is very LEAST LIKELY to apply IP Whitelisting on such Experience APIs whose
consumers are typically Mobile Phones or Tablets.