MuleSoft MCPA-Level-1-Maintenance Exam Practice Test Instant Access

Question 1

What correctly characterizes unit tests of Mule applications?

AThey test the validity of input and output of source and target systems

BThey must be run in a unit testing environment with dedicated Mule runtimes for the environment

CThey must be triggered by an external client tool or event source

DThey are typically written using MUnit to run in an embedded Mule runtime that does not require external connectivity

Answer : D

Correct Answer: They are typically written using MUnit to run in an embedded Mule

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

Below TWO are characteristics of Integration Tests but NOT unit tests:

>> They test the validity of input and output of source and target systems.

>> They must be triggered by an external client tool or event source.

It is NOT TRUE that Unit Tests must be run in a unit testing environment with dedicated Mule runtimes for the environment.

MuleSoft offers MUnit for writing Unit Tests and they run in an embedded Mule Runtime without needing any separate/ dedicated Runtimes to execute them. They also do NOT need any external connectivity as MUnit supports mocking via stubs.

https://dzone.com/articles/munit-framework

Question 2

An organization has several APIs that accept JSON data over HTTP POST. The APIs are all publicly available and are associated with several mobile applications and web applications.

The organization does NOT want to use any authentication or compliance policies for these APIs, but at the same time, is worried that some bad actor could send payloads that could somehow compromise the applications or servers running the API implementations.

What out-of-the-box Anypoint Platform policy can address exposure to this threat?

AShut out bad actors by using HTTPS mutual authentication for all API invocations

BApply an IP blacklist policy to all APIs; the blacklist will Include all bad actors

CApply a Header injection and removal policy that detects the malicious data before it is used

DApply a JSON threat protection policy to all APIs to detect potential threat vectors

Answer : D

Correct Answer: Apply a JSON threat protection policy to all APIs to detect potential

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

>> Usually, if the APIs are designed and developed for specific consumers (known consumers/customers) then we would IP Whitelist the same to ensure that traffic only comes from them.

>> However, as this scenario states that the APIs are publicly available and being used by so many mobile and web applications, it is NOT possible to identify and blacklist all possible bad actors.

>> So, JSON threat protection policy is the best chance to prevent any bad JSON payloads from such bad actors.

Question 3

Which layer in the API-led connectivity focuses on unlocking key systems, legacy systems, data sources etc and exposes the functionality?

AExperience Layer

BProcess Layer

CSystem Layer

Answer : C

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.

Question 4

An API experiences a high rate of client requests (TPS) vwth small message paytoads. How can usage limits be imposed on the API based on the type of client application?

AUse an SLA-based rate limiting policy and assign a client application to a matching SLA tier based on its type

BUse a spike control policy that limits the number of requests for each client application type

CUse a cross-origin resource sharing (CORS) policy to limit resource sharing between client applications, configured by the client application type

DUse a rate limiting policy and a client ID enforcement policy, each configured by the client application type

Answer : A

Correct Answer: Use an SLA-based rate limiting policy and assign a client

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

>> SLA tiers will come into play whenever any limits to be imposed on APIs based on client type

Question 5

An organization is deploying their new implementation of the OrderStatus System API to multiple workers in CloudHub. This API fronts the organization's on-premises Order Management System, which is accessed by the API implementation over an IPsec tunnel.

What type of error typically does NOT result in a service outage of the OrderStatus System API?

AA CloudHub worker fails with an out-of-memory exception

BAPI Manager has an extended outage during the initial deployment of the API implementation

CThe AWS region goes offline with a major network failure to the relevant AWS data centers

DThe Order Management System is Inaccessible due to a network outage in the organization's on-premises data center

Answer : A

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.

Question 6

What is a best practice when building System APIs?

ADocument the API using an easily consumable asset like a RAML definition

BModel all API resources and methods to closely mimic the operations of the backend system

CBuild an Enterprise Data Model (Canonical Data Model) for each backend system and apply it to System APIs

DExpose to API clients all technical details of the API implementation's interaction wifch the backend system

Answer : B

Correct Answer: Model all API resources and methods to closely mimic the

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

>> 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.

Question 7

When could the API data model of a System API reasonably mimic the data model exposed by the corresponding backend system, with minimal improvements over the backend system's data model?

AWhen there is an existing Enterprise Data Model widely used across the organization

BWhen the System API can be assigned to a bounded context with a corresponding data model

CWhen a pragmatic approach with only limited isolation from the backend system is deemed appropriate

DWhen the corresponding backend system is expected to be replaced in the near future

Answer : C

Correct Answer: When a pragmatic approach with only limited isolation from the

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

General guidance w.r.t choosing Data Models:

>> If an Enterprise Data Model is in use then the API data model of System APIs should make use of data types from that Enterprise Data Model and the corresponding API implementation should translate between these data types from the Enterprise Data Model and the native data model of the backend system.

>> If no Enterprise Data Model is in use then each System API should be assigned to a Bounded Context, the API data model of System APIs should make use of data types from the corresponding Bounded Context Data Model and the corresponding API implementation should translate between these data types from the Bounded Context Data Model and the native data model of the backend system. In this scenario, the data types in the Bounded Context Data Model are defined purely in terms of their business characteristics and are typically not related to the native data model of the backend system. In other words, the translation effort may be significant.

>> If no Enterprise Data Model is in use, and the definition of a clean Bounded Context Data Model is considered too much effort, then the API data model of System APIs should make use of data types that approximately mirror those from the backend system, same semantics and naming as backend system, lightly sanitized, expose all fields needed for the given System API's functionality, but not significantly more and making good use of REST conventions.

The latter approach, i.e., exposing in System APIs an API data model that basically mirrors that of the backend system, does not provide satisfactory isolation from backend systems through the System API tier on its own. In particular, it will typically not be possible to 'swap out' a backend system without significantly changing all System APIs in front of that backend system and therefore the API implementations of all Process APIs that depend on those System APIs! This is so because it is not desirable to prolong the life of a previous backend system's data model in the form of the API data model of System APIs that now front a new backend system. The API data models of System APIs following this approach must therefore change when the backend system is replaced.

On the other hand:

>> It is a very pragmatic approach that adds comparatively little overhead over accessing the backend system directly

>> Isolates API clients from intricacies of the backend system outside the data model (protocol, authentication, connection pooling, network address, ...)

>> Allows the usual API policies to be applied to System APIs

>> Makes the API data model for interacting with the backend system explicit and visible, by exposing it in the RAML definitions of the System APIs

>> Further isolation from the backend system data model does occur in the API implementations of the Process API tier

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