MuleSoft MCPA-Level-1 Exam Practice Test Instant Access

Question 1

The responses to some HTTP requests can be cached depending on the HTTP verb used in the request. According to the HTTP specification, for what HTTP verbs is this safe to do?

APUT, POST, DELETE

BGET, HEAD, POST

CGET, PUT, OPTIONS

DGET, OPTIONS, HEAD

Answer : D

Correct Answer: GET, OPTIONS, HEAD

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

Question 2

In an organization, the InfoSec team is investigating Anypoint Platform related data traffic.

From where does most of the data available to Anypoint Platform for monitoring and alerting originate?

AFrom the Mule runtime or the API implementation, depending on the deployment model

BFrom various components of Anypoint Platform, such as the Shared Load Balancer, VPC, and Mule runtimes

CFrom the Mule runtime or the API Manager, depending on the type of data

DFrom the Mule runtime irrespective of the deployment model

Answer : D

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.

Question 3

What is true about automating interactions with Anypoint Platform using tools such as Anypoint Platform REST APIs, Anypoint CU, or the Mule Maven plugin?

AAccess to Anypoint Platform APIs and Anypoint CU can be controlled separately through the roles and permissions in Anypoint Platform, so that specific users can get access to Anypoint CLI white others get access to the platform APIs

BAnypoint Platform APIs can ONLY automate interactions with CloudHub, while the Mule Maven plugin is required for deployment to customer-hosted Mule runtimes

CBy 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

DAPI policies can be applied to the Anypoint Platform APIs so that ONLY certain LOBs have access to specific functions

Answer : C

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.

Question 4

What condition requires using a CloudHub Dedicated Load Balancer?

AWhen cross-region load balancing is required between separate deployments of the same Mule application

BWhen custom DNS names are required for API implementations deployed to customer-hosted Mule runtimes

CWhen API invocations across multiple CloudHub workers must be load balanced

DWhen server-side load-balanced TLS mutual authentication is required between API implementations and API clients

Answer : D

Correct Answer: When server-side load-balanced TLS mutual authentication is required between API implementations and API clients

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

Fact/ Memory Tip: Although there are many benefits of CloudHub Dedicated Load balancer, TWO important things that should come to ones mind for considering it are:

>> Having URL endpoints with Custom DNS names on CloudHub deployed apps

>> Configuring custom certificates for both HTTPS and Two-way (Mutual) authentication.

Coming to the options provided for this

>> We

CANNOT use DLB to perform cross-region load balancing between separate deployments of the same Mule application.

>> We can have mapping rules to have more than one DLB URL pointing to same Mule app. But vicevera (More than one Mule app having same DLB URL) is NOT POSSIBLE

>> It is true that DLB helps to setup custom DNS names for Cloudhub deployed Mule apps but NOT true for apps deployed to Customer-hosted Mule Runtimes.

>> It is true to that we can load balance API invocations across multiple CloudHub workers using DLB but it is NOT A MUST. We can achieve the same (load balancing) using SLB (Shared Load Balancer) too. We DO NOT necessarily require DLB for achieve it.

So the only right option that fits the scenario and requires us to use DLB is when TLS mutual authentication is required between API implementations and API clients.

Question 5

The implementation of a Process API must change.

What is a valid approach that minimizes the impact of this change on API clients?

AUpdate the RAML definition of the current Process API and notify API client developers by sending them links to the updated RAML definition

BPostpone changes until API consumers acknowledge they are ready to migrate to a new Process API or API version

CImplement required changes to the Process API implementation so that whenever possible, the Process API's RAML definition remains unchanged

DImplement the Process API changes in a new API implementation, and have the old API implementation return an HTTP status code 301 - Moved Permanently to inform API clients they should be calling the new API implementation

Answer : C

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.

Question 6

A system API has a guaranteed SLA of 100 ms per request. The system API is deployed to a primary environment as well as to a disaster recovery (DR) environment, with different DNS names in each environment. An upstream process API invokes the system API and the main goal of this process API is to respond to client requests in the least possible time. In what order should the system APIs be invoked, and what changes should be made in order to speed up the response time for requests from the process API?

AIn 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

BIn parallel, invoke the system API deployed to the primary environment and the system API deployed to the DR environment using a scatter-gather configured with a timeout, and then merge the responses

CInvoke the system API deployed to the primary environment, and if it fails, invoke the system API deployed to the DR environment

DInvoke ONLY the system API deployed to the primary environment, and add timeout and retry logic to avoid intermittent failures

Answer : A

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.

Question 7

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?

AIPwhitelist

BSLA-based rate limiting

CAuth 2 token enforcement

DClient ID enforcement

Answer : B

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

MuleSoft Certified Platform Architect - Level 1 MCPA-Level-1 Exam Practice Test