Mulesoft MCPA-Level-1 Exam Questions

A company has started to create an application network and is now planning to implement a Center for Enablement (C4E) organizational model. What key factor would lead the company to decide upon a federated rather than a centralized C4E?

A.

When there are a large number of existing common assets shared by development teams

B.

When various teams responsible for creating APIs are new to integration and hence need extensive training

C.

When development is already organized into several independent initiatives or groups

D.

When the majority of the applications in the application network are cloud based

C.

When development is already organized into several independent initiatives or groups

Explanation: Explanation
Correct Answer: When development is already organized into several independent
initiatives or groups
*****************************************
>> It would require lot of process effort in an organization to have a single C4E team
coordinating with multiple already organized development teams which are into several
independent initiatives. A single C4E works well with different teams having at least a
common initiative. So, in this scenario, federated C4E works well instead of centralized
C4E.

An operations team is analyzing the effort needed to set up monitoring of their application network. They are looking at which API invocation metrics can be used to identify and predict trouble without having to write custom scripts or install additional analytics software or tools. Which type of metrics can satisfy this goal of directly identifying and predicting failures?

A. The number and types of API policy violations per day

B. The effectiveness of the application network based on the level of reuse

C. The number and types of past API invocations across the application network

D. The ROI from each APT invocation

A. The number and types of API policy violations per day

Explanation:
To monitor an application network and predict issues without custom scripts, policy violation metrics are critical. They provide insights into potential problems by tracking instances where API usage does not conform to defined policies. Here’s why this approach is suitable:

Predictive Monitoring:
No Custom Scripting Needed:
Explanation of Incorrect Options:

A TemperatureSensors API instance is defined in API Manager in the PROD environment of the CAR_FACTORY business group. An AcmelemperatureSensors Mule application implements this API instance and is deployed from Runtime Manager to the PROD environment of the CAR_FACTORY business group. A policy that requires a valid client ID and client secret is applied in API Manager to the API instance.
Where can an API consumer obtain a valid client ID and client secret to call the AcmeTemperatureSensors Mule application?

A. In secrets manager, request access to the Shared Secret static username/password

B. In API Manager, from the PROD environment of the CAR_FACTORY business group

C. In access management, from the PROD environment of the CAR_FACTORY business group

D. In Anypoint Exchange, from an API client application that has been approved for the TemperatureSensors API instance

Explanation:
When an API policy requiring a client ID and client secret is applied to an API instance in API Manager, API consumers must obtain these credentials through a registered client application. Here’s how it works:

Anypoint Exchange and Client Applications:
Why Option D is Correct:
Explanation of Incorrect Options:

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

A.

Access 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

B.

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

C.

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

D.

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

C.

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

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

Refer to the exhibit.

Three business processes need to be implemented, and the implementations need to communicate with several different SaaS applications.
These processes are owned by separate (siloed) LOBs and are mainly independent of each other, but do share a few business entities. Each LOB has one development team and their own budget.
In this organizational context, what is the most effective approach to choose the API data models for the APIs that will implement these business processes with minimal redundancy of the data models?
A) Build several Bounded Context Data Models that align with coherent parts of the business processes and the definitions of associated business entities.
B) Build distinct data models for each API to follow established micro-services and Agile API-centric practices
C) Build all API data models using XML schema to drive consistency and reuse across the organization
D) Build one centralized Canonical Data Model (Enterprise Data Model) that unifies all the data types from all three business processes, ensuring the data model is consistent and non-redundant

A. Option A

B. Option B

C. Option C

D. Option D

A. Option A

Explanation:

Correct Answer: Build several Bounded Context Data Models that align with coherent parts of the business processes and the definitions of associated business entities.

The options w.r.t building API data models using XML schema/ Agile API-centric practices are irrelevant to the scenario given in the question. So these two are INVALID.
Building EDM (Enterprise Data Model) is not feasible or right fit for this scenario as the teams and LOBs work in silo and they all have different initiatives, budget etc.. Building EDM needs intensive coordination among all the team which evidently seems not possible in this scenario.

So, the right fit for this scenario is to build several Bounded Context Data Models that align with coherent parts of the business processes and the definitions of associated business entities.

What is most likely NOT a characteristic of an integration test for a REST API
implementation?

A.

The test needs all source and/or target systems configured and accessible

B.

The test runs immediately after the Mule application has been compiled and packaged

C.

The test is triggered by an external HTTP request

D.

The test prepares a known request payload and validates the response payload

B.

The test runs immediately after the Mule application has been compiled and packaged

Explanation: Explanation
Correct Answer: The test runs immediately after the Mule application has been compiled
and packaged
*****************************************
>> Integration tests are the last layer of tests we need to add to be fully covered.
>> These tests actually run against Mule running with your full configuration in place and are tested from external source as they work in PROD.
>> These tests exercise the application as a whole with actual transports enabled. So,
external systems are affected when these tests run.
So, these tests do NOT run immediately after the Mule application has been compiled and
packaged.
FYI... Unit Tests are the one that run immediately after the Mule application has been
compiled and packaged.
Reference: https://docs.mulesoft.com/mule-runtime/3.9/testing-strategies#integrationtesting

A business process is being implemented within an organization's application network. The architecture group proposes using a more coarse-grained application network design with relatively fewer APIs deployed to the application network compared to a more fine-grained design. Overall, which factor typically increases with a more coarse-grained design for this business process implementation and deployment compared with using a more finegrained design?

A. The complexity of each API implementation

B. The number of discoverable assets related to APIs deployed in the application network

C. The number of possible connections between API implementations in the application network

D. The usage of network infrastructure resources by the application network

A. The complexity of each API implementation

Which of the following best fits the definition of API-led connectivity?

A.

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

B.

API-led connectivity is a 3-layered architecture covering Experience, Process and System layers

C.

API-led connectivity is a technology which enabled us to implement Experience, Process and System layer based APIs

A.

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

Explanation: 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/