Mulesoft MCPA-Level-1 Exam Questions

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

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.

Refer to the exhibit.

A.

Option A

B.

Option B

C.

Option C

D.

Option D

D.

Option D

Explanation: Explanation
Correct Answer: XML over HTTP
*****************************************
>> API-led connectivity and Application Networks urge to have the APIs on HTTP based
protocols for building most effective APIs and networks on top of them.
>> The HTTP based APIs allow the platform to apply various varities of policies to address
many NFRs
>> The HTTP based APIs also allow to implement many standard and effective
implementation patterns that adhere to HTTP based w3c rules

What should be ensured before sharing an API through a public Anypoint Exchange portal?

A.

The visibility level of the API instances of that API that need to be publicly accessible should be set to public visibility

B.

The users needing access to the API should be added to the appropriate role in
Anypoint Platform

C.

The API should be functional with at least an initial implementation deployed and accessible for users to interact with

D.

The API should be secured using one of the supported authentication/authorization mechanisms to ensure that data is not compromised

A.

The visibility level of the API instances of that API that need to be publicly accessible should be set to public visibility

Explanation: Explanation

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.

What best describes the Fully Qualified Domain Names (FQDNs), also known as DNS entries, created when a Mule application is deployed to the CloudHub Shared Worker Cloud?

A.

A fixed number of FQDNs are created, IRRESPECTIVE of the environment and VPC design

B.

The FQDNs are determined by the application name chosen, IRRESPECTIVE of the region

C.

The FQDNs are determined by the application name, but can be modified by an
administrator after deployment

D.

The FQDNs are determined by both the application name and the Anypoint Platform
organization

B.

The FQDNs are determined by the application name chosen, IRRESPECTIVE of the region

Explanation: Explanation
Correct Answer: The FQDNs are determined by the application name chosen,
IRRESPECTIVE of the region
*****************************************
>> When deploying applications to Shared Worker Cloud, the FQDN are always
determined by application name chosen.
>> It does NOT matter what region the app is being deployed to.
>> Although it is fact and true that the generated FQDN will have the region included in it
(Ex: exp-salesorder-api.au-s1.cloudhub.io), it does NOT mean that the same name can be
used when deploying to another CloudHub region.
>> Application name should be universally unique irrespective of Region and Organization
and solely determines the FQDN for Shared Load Balancers

What Mule application deployment scenario requires using Anypoint Platform Private Cloud Edition or Anypoint Platform for Pivotal Cloud Foundry?

A.

When it Is required to make ALL applications highly available across multiple data centers

B.

When it is required that ALL APIs are private and NOT exposed to the public cloud

C.

When regulatory requirements mandate on-premises processing of EVERY data item, including meta-data

D.

When ALL backend systems in the application network are deployed in the
organization's intranet

C.

When regulatory requirements mandate on-premises processing of EVERY data item, including meta-data

Explanation: Explanation
Correct Answer: When regulatory requirements mandate on-premises processing of EVERY data item, including meta-data.
*****************************************
We need NOT require to use Anypoint Platform PCE or PCF for the below. So these
options are OUT.
>> We can make ALL applications highly available across multiple data centers using
CloudHub too.
>> We can use Anypoint VPN and tunneling from CloudHub to connect to ALL backend
systems in the application network that are deployed in the organization's intranet.
>> We can use Anypoint VPC and Firewall Rules to make ALL APIs private and NOT
exposed to the public cloud.
Only valid reason in the given options that requires to use Anypoint Platform PCE/ PCF is -
When regulatory requirements mandate on-premises processing of EVERY data item,
including meta-data

A Mule 4 API has been deployed to CloudHub and a Basic Authentication - Simple policy has been applied to all API methods and resources. However, the API is still accessible by clients without using authentication. How is this possible?

A. The APE Router component is pointing to the incorrect Exchange version of the APT

B. The Autodiscovery element is not present, in the deployed Mule application

C. No… for client applications have been created of this API

D. One of the application’s CloudHub workers restarted

B. The Autodiscovery element is not present, in the deployed Mule application

Explanation:
When a Basic Authentication policy is applied to an API on CloudHub but clients can still access the API without authentication, the likely cause is a missing Autodiscovery element. Here’s how this affects API security:

Autodiscovery in MuleSoft:
Why Option B is Correct:
Explanation of Incorrect Options:

References:
Refer to MuleSoft documentation on Autodiscovery configuration and linking API Manager policies for additional information on setting up secure API policies.