MCPA-LEVEL-1 Practice Questions

Correct Answer: The client ID and secret obtained from Anypoint Exchange for the API instance in the

STAGING environment

*****************************************

>> We CANNOT use the client ID and secret of Anypoint Platform account or any individual

environments for accessing the APIs

>> As the type of policy that is enforced on the API in question is "Client ID Enforcment Policy",

OAuth token based access won't work.

Right way to access the API is to use the client ID and secret obtained from Anypoint Exchange for

the API instance in a particular environment we want to work on.

Managing API instance Contracts on API Manager

https://docs.mulesoft.com/api-manager/1.x/request-access-to-api-task

https://docs.mulesoft.com/exchange/to-request-access

https://docs.mulesoft.com/api-manager/2.x/policy-mule3-client-id-based-policies

Correct Answer: Traffic between Mule applications deployed to an Anypoint VPC and on-premises

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.

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/MuleSoft_MCPA-Level-1/page_6_img_1.jpg

that each CloudHub environment requires a separate Anypoint VPC. Once an Anypoint VPC is

created, we can choose a same VPC by multiple environments. However, it is generally a best and

recommended practice to always have seperate Anypoint VPCs for Non-Prod and Prod environments.

>> We use Anypoint VPN to link the underlying AWS VPC to an on-premises (non AWS) private

network. NOT VPC Peering.

Reference: https://docs.mulesoft.com/runtime-manager/vpn-about

Only true statement in the given choices is that the traffic between Mule applications deployed to an

Anypoint VPC and on-premises systems can stay within a private network.

https://docs.mulesoft.com/runtime-manager/vpc-connectivity-methods-concept

Correct Answer: Set a timeout of 100ms; that leaves 400ms for other two downstream APIs to

complete

*****************************************

Key details to take from the given scenario:

>> Upstream API's designed SLA is 500ms (median). Lets ignore maximum SLA response times.

>> This API calls 3 downstream APIs sequentially and all these are of similar complexity.

>> The first downstream API is offering median SLA of 100ms, 80th percentile: 500ms; 95th

percentile: 1000ms.

Based on the above details:

>> We can rule out the option which is suggesting to set 50ms timeout. Because, if the median SLA

itself being offered is 100ms then most of the calls are going to timeout and time gets wasted in

retried them and eventually gets exhausted with all retries. Even if some retries gets successful, the

remaining time wont leave enough room for 2nd and 3rd downstream APIs to respond within time.

>> The option suggesting to NOT set a timeout as the invocation of this API is mandatory and so we

must wait until it responds is silly. As not setting time out would go against the good implementation

pattern and moreover if the first API is not responding within its offered median SLA 100ms then

most probably it would either respond in 500ms (80th percentile) or 1000ms (95th percentile). In

BOTH cases, getting a successful response from 1st downstream API does NO GOOD because already

by this time the Upstream API SLA of 500 ms is breached. There is no time left to call 2nd and 3rd

downstream APIs.

>> It is NOT true that no timeout is possible to meet the upstream APIs desired SLA.

As 1st downstream API is offering its median SLA of 100ms, it means MOST of the time we would get

the responses within that time. So, setting a timeout of 100ms would be ideal for MOST calls as it

leaves enough room of 400ms for remaining 2 downstream API calls.

Correct Answers:

1. Each modern API must be treated like a product and designed for a particular target audience (for

instance mobile app developers)

*****************************************

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/MuleSoft_MCPA-Level-1/page_38_img_1.jpg

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.

Correct Answer: A CloudHub worker fails with an out-of-memory exception.

*****************************************

>> An AWS Region itself going down will definitely result in an outage as it does not matter how

many workers are assigned to the Mule App as all of those in that region will go down. This is a

complete downtime and outage.

>> Extended outage of API manager during initial deployment of API implementation will of course

cause issues in proper application startup itself as the API Autodiscovery might fail or API policy

templates and polices may not be downloaded to embed at the time of applicaiton startup etc...

there are many reasons that could cause issues.

>> A network outage onpremises would of course cause the Order Management System not

accessible and it does not matter how many workers are assigned to the app they all will fail and

cause outage for sure.

The only option that does NOT result in a service outage is if a cloudhub worker fails with an out-of-

memory exception. Even if a worker fails and goes down, there are still other workers to handle the

requests and keep the API UP and Running. So, this is the right answer.

Correct Answer: By refining the response definitions by adding the x-ratelimit-* response headers

with description, type, and example

*****************************************

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/MuleSoft_MCPA-Level-1/page_33_img_1.jpg

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/MuleSoft_MCPA-Level-1/page_33_img_2.jpg

https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling#response-headers

https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling-sla-basedpolicies#response-headers

Correct Answer: Implement required changes to the Process API implementation so that, whenever

possible, the Process API’s RAML definition remains unchanged.

*****************************************

Key requirement in the question is:

>> Approach that minimizes the impact of this change on API clients

Based on above:

>> Updating the RAML definition would possibly impact the API clients if the changes require any

thing mandatory from client side. So, one should try to avoid doing that until really necessary.

>> Implementing the changes as a completely different API and then redirectly the clients with 3xx

status code is really upsetting design and heavily impacts the API clients.

>> Organisations and IT cannot simply postpone the changes required until all API consumers

acknowledge they are ready to migrate to a new Process API or API version. This is unrealistic and

not possible.

The best way to handle the changes always is to implement required changes to the API

implementations so that, whenever possible, the API’s RAML definition remains unchanged.

Correct Answer: Approve the client application request for the chosen SLA tier

*****************************************

>> Only approving the client application request for the chosen SLA tier can be automated

>> Rest of the provided options are not valid

Reference: https://docs.mulesoft.com/api-manager/2.x/defining-sla-tiers#defining-a-tier

Correct Answer: From the Mule runtime irrespective of the deployment model

*****************************************

>> Monitoring and Alerting metrics are always originated from Mule Runtimes irrespective of the

deployment model.

>> It may seems that some metrics (Runtime Manager) are originated from Mule Runtime and some

are (API Invocations/ API Analytics) from API Manager. However, this is realistically NOT TRUE. The

reason is, API manager is just a management tool for API instances but all policies upon applying on

APIs eventually gets executed on Mule Runtimes only (Either Embedded or API Proxy).

>> Similarly all API Implementations also run on Mule Runtimes.

So, most of the day required for monitoring and alerts are originated fron Mule Runtimes only

irrespective of whether the deployment model is MuleSoft-hosted or Customer-hosted or Hybrid.