Free MCPA-Level-1 Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

Correct Answer: Ask the Marketing Department to interact with a mocking implementation of the

API using the automatically generated API Console.

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

As per MuleSoft's IT Operating Model:

>> API consumers need NOT wait until the full API implementation is ready.

>> NO technical test-suites needs to be shared with end users to interact with APIs.

>> Anypoint Platform offers a mocking capability on all the published API specifications to Anypoint

Exchange which also will be rich in documentation covering all details of API functionalities and

working nature.

>> No needs of arranging days of workshops with end users for feedback.

API consumers can use Anypoint Exchange features on the platform and interact with the API using

its mocking feature. The feedback can be shared quickly on the same to incorporate any changes.

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

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.

Correct Answer: It makes API Manager aware of API implementations and hence enables it to

enforce policies.

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

>> API Autodiscovery is a mechanism that manages an API from API Manager by pairing the

deployed application to an API created on the platform.

>> API Management includes tracking, enforcing policies if you apply any, and reporting API

analytics.

>> Critical to the Autodiscovery process is identifying the API by providing the API name and version.

https://docs.mulesoft.com/api-manager/2.x/api-auto-discovery-new-concept

https://docs.mulesoft.com/api-manager/1.x/api-auto-discovery

https://docs.mulesoft.com/api-manager/2.x/api-auto-discovery-new-concept

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

Correct Answer: The SSL certificates used by the API implementation to expose HTTPS endpoints

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

>> The assignment of each HTTP request to a particular CloudHub worker is taken care by Anypoint

Platform itself. We need not manage it explicitly in the API implementation and in fact we CANNOT

manage it in the API implementation.

>> The logging configuration that enables log entries to be visible in Runtime Manager is ALWAYS

managed in the API implementation and NOT just for SLB. So this is not something we do

EXCLUSIVELY when using SLB.

>> We DO NOT manage the number of DNS entries allocated to the API implementation inside the

code. Anypoint Platform takes care of this.

It is the SSL certificates used by the API implementation to expose HTTPS endpoints that is to be

managed EXCLUSIVELY by the API implementation. Anypoint Platform does NOT do this when using

SLBs.

Correct Answer: API implementations can run successfully in customer-hosted Mule runtimes, even

when they are unable to communicate with the control plane.

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

>> We CANNOT use Shared Load balancer to load balance APIs on customer hosted runtimes

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

>> For Hybrid deployment models, the on-premises are first connected to Runtime Manager

using Runtime Manager agent. So, the connection is initiated first from On-premises to Runtime

Manager. Then all control can be done from Runtime Manager.

>> Anypoint Runtime Manager CANNOT ensure automatic HA. Clusters/Server Groups etc should be

configured before hand.

Only TRUE statement in the given choices is, API implementations can run successfully in customer-

hosted Mule runtimes, even when they are unable to communicate with the control plane. There are

several

below to justify this statement.

References:

https://docs.mulesoft.com/runtime-manager/deployment-strategies#hybrid-deployments

https://help.mulesoft.com/s/article/On-Premise-Runtimes-Disconnected-From-US-Control-PlaneJune-18th-2018

https://help.mulesoft.com/s/article/Runtime-Manager-cannot-manage-On-Prem-Applications-andServers-from-US-Control-Plane-June-25th-2019

https://help.mulesoft.com/s/article/On-premise-Runtimes-Appear-Disconnected-in-RuntimeManager-May-29th-2018

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

============================

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

============================

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

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

Correct Answer: The visibility level of the API instances of that API that need to be publicly accessible

should be set to public visibility.

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

Reference: https://docs.mulesoft.com/exchange/to-share-api-asset-to-portal

https://docs.mulesoft.com/exchange/to-share-api-asset-to-portal

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

Correct Answer: GET, OPTIONS, HEAD

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

http://restcookbook.com/HTTP%20Methods/idempotency/

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.

Correct Answer: 8082

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

>> 8091 and 8092 ports are to be used when keeping your HTTP and HTTPS app private to the LOCAL

VPC respectively.

>> Above TWO ports are not for Shared AWS VPC/ Shared Worker Cloud.

>> 8081 is to be used when exposing your HTTP endpoint app to the internet through Shared LB

>> 8082 is to be used when exposing your HTTPS endpoint app to the internet through Shared LB

So, API invocations should be sent to port 8082 when calling this HTTPS based app.

https://docs.mulesoft.com/runtime-manager/cloudhub-networking-guide

https://help.mulesoft.com/s/article/Configure-Cloudhub-Application-to-Send-a-HTTPS-RequestDirectly-to-Another-Cloudhub-Application

https://help.mulesoft.com/s/question/0D52T00004mXXULSA4/multiple-http-listerners-oncloudhub-one-with-port-9090

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"

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/

Correct Answer: The API policy is defined in API Manager for a specific API instance, and then ONLY

applied to the specific API instance.

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

>> Once our API specifications are ready and published to Exchange, we need to visit API Manager

and register an API instance for each API.

>> API Manager is the place where management of API aspects takes place like addressing NFRs by

enforcing policies on them.

>> We can create multiple instances for a same API and manage them differently for different

purposes.

>> One instance can have a set of API policies applied and another instance of same API can have

different set of policies applied for some other purpose.

>> These APIs and their instances are defined PER environment basis. So, one need to manage them

seperately in each environment.

>> We can ensure that same configuration of API instances (SLAs, Policies etc..) gets promoted when

promoting to higher environments using platform feature. But this is optional only. Still one can

change them per environment basis if they have to.

>> Runtime Manager is the place to manage API Implementations and their Mule Runtimes but NOT

APIs itself. Though API policies gets executed in Mule Runtimes, We CANNOT enforce API policies in

Runtime Manager. We would need to do that via API Manager only for a cherry picked instance in an

environment.

So, based on these facts, right statement in the given choices is - "The API policy is defined in API

Manager for a specific API instance, and then ONLY applied to the specific API instance".

Reference: https://docs.mulesoft.com/api-manager/2.x/latest-overview-concept

Correct Answer: Apply a basic authentication - LDAP policy; the internal Active Directory will be

configured as the LDAP source for authenticating users.

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

>> IP Whitelisting does NOT fit for this purpose. Moreover, the users workstations may not

necessarily have static IPs in the network.

>> OAuth 2.0 enforcement requires a client provider which isn't in the organizations system

components.

>> It is not an effective approach to let every user create separate client credentials and configure

those for their usage.

The effective way it to apply a basic authentication - LDAP policy and the internal Active Directory

will be configured as the LDAP source for authenticating users.

Reference: https://docs.mulesoft.com/api-manager/2.x/basic-authentication-ldap-concept

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