Pass MCPA-Level-1-Maintenance Brain Dump Updated Certification Sample Questions [Q27-Q44]

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

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

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

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

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

NEW QUESTION 28
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 fixed number of FQDNs are created, IRRESPECTIVE of the environment and VPC design

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

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

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

NEW QUESTION 29
Select the correct Owner-Layer combinations from below options

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

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

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

NEW QUESTION 30
An API has been updated in Anypoint exchange by its API producer from version 3.1.1 to 3.2.0 following accepted semantic versioning practices and the changes have been communicated via the APIs public portal.
The API endpoint does NOT change in the new version. How should the developer of an API client respond to this change?

The API producer should be requested to run the old version in parallel with the new one

The API producer should be contacted to understand the change to existing functionality

The API client code only needs to be changed if it needs to take advantage of the new features

The API clients need to update the code on their side and need to do full regression

NEW QUESTION 31
What is the main change to the IT operating model that MuleSoft recommends to organizations to improve innovation and clock speed?

Drive consumption as much as production of assets; this enables developers to discover and reuse assets from other projects and encourages standardization

Expose assets using a Master Data Management (MDM) system; this standardizes projects and enables developers to quickly discover and reuse assets from other projects

Implement SOA for reusable APIs to focus on production over consumption; this standardizes on XML and WSDL formats to speed up decision making

Create a lean and agile organization that makes many small decisions everyday; this speeds up decision making and enables each line of business to take ownership of its projects

NEW QUESTION 32
What is a key requirement when using an external Identity Provider for Client Management in Anypoint Platform?

Single sign-on is required to sign in to Anypoint Platform

The application network must include System APIs that interact with the Identity Provider

To invoke OAuth 2.0-protected APIs managed by Anypoint Platform, API clients must submit access tokens issued by that same Identity Provider

APIs managed by Anypoint Platform must be protected by SAML 2.0 policies

NEW QUESTION 33
An organization has created an API-led architecture that uses various API layers to integrate mobile clients with a backend system. The backend system consists of a number of specialized components and can be accessed via a REST API. The process and experience APIs share the same bounded-context model that is different from the backend data model. What additional canonical models, bounded-context models, or anti-corruption layers are best added to this architecture to help process data consumed from the backend system?

Create a bounded-context model for every layer and overlap them when the boundary contexts overlap, letting API developers know about the differences between upstream and downstream data models

Create a canonical model that combines the backend and API-led models to simplify and unify data models, and minimize data transformations.

Create a bounded-context model for the system layer to closely match the backend data model, and add an anti-corruption layer to let the different bounded contexts cooperate across the system and process layers

Create an anti-corruption layer for every API to perform transformation for every data model to match each other, and let data simply travel between APIs to avoid the complexity and overhead of building canonical models

NEW QUESTION 34
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?

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

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

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

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

When a pragmatic approach with only limited isolation from the backend system is deemed appropriate.
*****************************************
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

NEW QUESTION 35
What are the major benefits of MuleSoft proposed IT Operating Model?

1. Decrease the IT delivery gap
2. Meet various business demands without increasing the IT capacity
3. Focus on creation of reusable assets first. Upon finishing creation of all the possible assets then inform the LOBs in the organization to start using them

1. Decrease the IT delivery gap
2. Meet various business demands by increasing the IT capacity and forming various IT departments
3. Make consumption of assets at the rate of production

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

NEW QUESTION 36
Which of the below, when used together, makes the IT Operational Model effective?

Create reusable assets, Do marketing on the created assets across organization, Arrange time to time LOB reviews to ensure assets are being consumed or not

Create reusable assets, Make them discoverable so that LOB teams can self-serve and browse the APIs, Get active feedback and usage metrics

Create resuable assets, make them discoverable so that LOB teams can self-serve and browse the APIs

NEW QUESTION 37
Refer to the exhibit.

What is the best way to decompose one end-to-end business process into a collaboration of Experience, Process, and System APIs?
A) Handle customizations for the end-user application at the Process API level rather than the Experience API level

B) Allow System APIs to return data that is NOT currently required by the identified Process or Experience APIs

C) Always use a tiered approach by creating exactly one API for each of the 3 layers (Experience, Process and System APIs)

D) Use a Process API to orchestrate calls to multiple System APIs, but NOT to other Process APIs

Option A

Option B

Option C

Option D

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

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

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

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

NEW QUESTION 39
Traffic is routed through an API proxy to an API implementation. The API proxy is managed by API Manager and the API implementation is deployed to a CloudHub VPC using Runtime Manager. API policies have been applied to this API. In this deployment scenario, at what point are the API policies enforced on incoming API client requests?

At the API proxy

At the API implementation

At both the API proxy and the API implementation

At a MuleSoft-hosted load balancer

NEW QUESTION 40
A company has created a successful enterprise data model (EDM). The company is committed to building an application network by adopting modern APIs as a core enabler of the company’s IT operating model. At what API tiers (experience, process, system) should the company require reusing the EDM when designing modern API data models?

At the experience and process tiers

At the experience and system tiers

At the process and system tiers

At the experience, process, and system tiers

NEW QUESTION 41
What correctly characterizes unit tests of Mule applications?

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

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

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

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

NEW QUESTION 42
An organization wants to make sure only known partners can invoke the organization’s APIs. To achieve this security goal, the organization wants to enforce a Client ID Enforcement policy in API Manager so that only registered partner applications can invoke the organization’s APIs. In what type of API implementation does MuleSoft recommend adding an API proxy to enforce the Client ID Enforcement policy, rather than embedding the policy directly in the application’s JVM?

A Mule 3 application using APIkit

A Mule 3 or Mule 4 application modified with custom Java code

A Mule 4 application with an API specification

A Non-Mule application

NEW QUESTION 43
Refer to the exhibit.

An organization uses one specific CloudHub (AWS) region for all CloudHub deployments.
How are CloudHub workers assigned to availability zones (AZs) when the organization’s Mule applications are deployed to CloudHub in that region?

Workers belonging to a given environment are assigned to the same AZ within that region

AZs are selected as part of the Mule application’s deployment configuration

Workers are randomly distributed across available AZs within that region

An AZ is randomly selected for a Mule application, and all the Mule application’s CloudHub workers are assigned to that one AZ

NEW QUESTION 44
What is a typical result of using a fine-grained rather than a coarse-grained API deployment model to implement a given business process?

A decrease in the number of connections within the application network supporting the business process

A higher number of discoverable API-related assets in the application network

A better response time for the end user as a result of the APIs being smaller in scope and complexity

An overall tower usage of resources because each fine-grained API consumes less resources

Quiz Training Materials

Pass MCPA-Level-1-Maintenance Brain Dump Updated Certification Sample Questions [Q27-Q44]

Leave a Reply Cancel reply