MuleSoft mcpa-level-1 practice test

Answer:

B

Explanation:
Correct Answer: TRUE
*****************************************
>> As per MuleSoft proposed IT Operating Model, designing APIs and making sure that they are
discoverable and self-servable is VERY VERY IMPORTANT and decides the success of an API and its
application network.

Answer:

C

Explanation:
Correct Answer: API Design and Development, API Runtime Execution and Hosting, API Operations
and Management, API Consumer Engagement
*****************************************
>> API Design and Development - Anypoint Studio, Anypoint Design Center, Anypoint Connectors
>> API Runtime Execution and Hosting - Mule Runtimes, CloudHub, Runtime Services
>> API Operations and Management - Anypoint API Manager, Anypoint Exchange
>> API Consumer Management - API Contracts, Public Portals, Anypoint Exchange, API Notebooks

Answer:

D

Explanation:
Correct Answers: API Design and Development and API Runtime Execution and Hosting
*****************************************
>> API Design and Development - Anypoint Studio, Anypoint Design Center, Anypoint Connectors
>> API Runtime Execution and Hosting - Mule Runtimes, CloudHub, Runtime Services
>> API Operations and Management - Anypoint API Manager, Anypoint Exchange
>> API Consumer Management - API Contracts, Public Portals, Anypoint Exchange, API Notebooks

Explanation:
Correct Answers:API Operations and Management and API Consumer Engagement
*****************************************
>>API Design and Development- Anypoint Studio, Anypoint Design Center, Anypoint Connectors
>>API Runtime Execution and Hosting- Mule Runtimes, CloudHub, Runtime Services
>>API Operations and Management- Anypoint API Manager, Anypoint Exchange
>>API Consumer Management- API Contracts, Public Portals, Anypoint Exchange, API Notebooks

Answer:

C

Explanation:
Correct Answer:
1. App Developers owns and focuses on Experience Layer APIs
2. LOB IT owns and focuses on Process Layer APIs
3. Central IT owns and focuses on System Layer APIs

References:
https://blogs.mulesoft.com/biz/api/experience-api-ownership/
https://blogs.mulesoft.com/biz/api/process-api-ownership/
https://blogs.mulesoft.com/biz/api/system-api-ownership/

Answer:

C

Explanation:
Correct Answer: System Layer

The APIs used in an API-led approach to connectivity fall into three categories:
System APIs these usually access the core systems of record and provide a means of insulating the
user from the complexity or any changes to the underlying systems. Once built, many users, can
access data without any need to learn the underlying systems and can reuse these APIs in multiple
projects.
Process APIs These APIs interact with and shape data within a single system or across systems
(breaking down data silos) and are created here without a dependence on the source systems from
which that data originates, as well as the target channels through which that data is delivered.
Experience APIs Experience APIs are the means by which data can be reconfigured so that it is most
easily consumed by its intended audience, all from a common data source, rather than setting up
separate point-to-point integrations for each channel. An Experience API is usually created with API-
first design principles where the API is designed for the specific user experience in mind.

Answer:

B

Explanation:
Correct Answer: The CloudHub shared load balancer
*****************************************
The scenario in this question can be split as below:
>> There are 3 CloudHub workers (So, there are already good number of workers to handle high
volume of requests)
>> The workers are not using static IP addresses (So, one CANNOT use customer load-balancing
solutions without static IPs)
>> Looking for most cost-effective component to load balance the client requests among the
workers.
Based on the above details given in the scenario:
>> Runtime autoscaling is NOT at all cost-effective as it incurs extra cost. Most over, there are already
3 workers running which is a good number.
>> We cannot go for a customer-hosted load balancer as it is also NOT most cost-effective (needs
custom load balancer to maintain and licensing) and same time the Mule App is not having Static IP
Addresses which limits from going with custom load balancing.
>> An API Proxy is irrelevant there as it has no role to play w.r.t handling high volumes or load
balancing.
So, the only right option to go with and fits the purpose of scenario being most cost-effective is -
using a CloudHub Shared Load Balancer.

Answer:

C

Explanation:
Correct Answer:
1. Decrease the IT delivery gap
2. Meet various business demands without increasing the IT capacity
3. Make consumption of assets at the rate of production.
*****************************************
Reference:
https://www.youtube.com/watch?v=U0FpYMnMjmM

Answer:

A

Explanation:
Correct Answer: API-led connectivity is not just an architecture or technology but also a way to
organize people and processes for efficient IT delivery in the organization.
*****************************************
Reference:
https://blogs.mulesoft.com/dev/api-dev/what-is-api-led-connectivity/

Answer:

A

Explanation:
Correct Answer: In parallel, invoke the system API deployed to the primary environment and the
system API deployed to the DR environment, and ONLY use the first response.
*****************************************
>> The API requirement in the given scenario is to respond in least possible time.
>> The option that is suggesting to first try the API in primary environment and then fallback to API in
DR environment would result in successful response but NOT in least possible time. So, this is NOT a
right choice of implementation for given requirement.
>> Another option that is suggesting to ONLY invoke API in primary environment and to add timeout
and retries may also result in successful response upon retries but NOT in least possible time. So, this
is also NOT a right choice of implementation for given requirement.
>> One more option that is suggesting to invoke API in primary environment and API in DR
environment in parallel using Scatter-Gather would result in wrong API response as it would return
merged results and moreover, Scatter-Gather does things in parallel which is true but still completes
its scope only on finishing all routes inside it. So again, NOT a right choice of implementation for
given requirement
The Correct choice is to invoke the API in primary environment and the API in DR environment
parallelly, and using ONLY the first response received from one of them.

Answer:

A
*****************************************
>> Application Network is a disposable architecture.
>> Which means, it can be altered without disturbing entire architecture and its components.
>> It bends as per requirements or design changes but does not break

Reference:
https://www.mulesoft.com/resources/api/what-is-an-application-network

Answer:

C

Explanation:
Correct Answer: At the process and system tiers
*****************************************
>> Experience Layer APIs are modeled and designed exclusively for the end user's experience. So, the
data models of experience layer vary based on the nature and type of such API consumer. For
example, Mobile consumers will need light-weight data models to transfer with ease on the wire,
where as web-based consumers will need detailed data models to render most of the info on web
pages, so on. So, enterprise data models fit for the purpose of canonical models but not of good use
for experience APIs.
>> That is why, EDMs should be used extensively in process and system tiers but NOT in experience
tier.

Answer:

D

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.

Answer:

D

Explanation:
Correct Answer: Increase the size of the CloudHub worker(s)
*****************************************
The key details that we can take out from the given scenario are:
>> API implementation uses a database bulk insert command to submit all the purchase data to a
database
>> JDBC driver processes the data into a set of several temporary disk files on the CloudHub worker
>> Sometimes a request fails and the logs show a message indicating an out-of-file-space message
Based on above details:
>> Both auto-scaling options does NOT help because we cannot set auto-scaling rules based on error
messages. Auto-scaling rules are kicked-off based on CPU/Memory usages and not due to some
given error or disk space issues.
>> Increasing the number of CloudHub workers also does NOT help here because the reason for the
failure is not due to performance aspects w.r.t CPU or Memory. It is due to disk-space.
>> Moreover, the API is doing bulk insert to submit the received batch data. Which means, all data is
handled by ONE worker only at a time. So, the disk space issue should be tackled on "per worker"
basis. Having multiple workers does not help as the batch may still fail on any worker when disk is
out of space on that particular worker.
Therefore, the right way to deal this issue and resolve this is to increase the vCore size of the worker
so that a new worker with more disk space will be provisioned.

Answer:

D

Explanation:
Correct Answer: The remaining capacity allowed by the API implementation.
*****************************************
>> Reference:
https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling-sla-based-
policies#response-headers

Answer:

C