Salesforce Certified MuleSoft Platform Architect (Mule-Arch-201) Exam Questions 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 Answe r: They are typically written using MUnit to run in an embedded Mule runtime that does not require external connectivity.

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

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

A developer from the Central IT team has created an initial version of the RAML definition in Design Center for an OAuth 2.0-protected System API and published it

to Exchange. Another developer from LoB IT discovered the System API in Exchange and would like to leverage it in the Process API.

What is the MuleSoft-recommended approach for Process API to invoke the System API?

AThe Process API needs to import an CAuth 2.0 module from Exchange first and update it with OAuth 2.0 credentials before the System API can be invoked

BThe Process API uses property YAML files to store the System API URLs and uses the HTTP Request Connector to invoke the Systerm API

CThe Process APL uses the REST Connect Connector autogenerated in Exchange for the System API

DThe Process API manually updates the Process API POM file to include the System API as a dependency

Answer : C

In MuleSoft's ecosystem, when a Process API needs to consume a System API (published to Exchange and protected by OAuth 2.0), the recommended approach is to utilize the REST Connect Connector. Here's how it aligns with best practices:

Automated Connector Generation:

When a RAML or OAS specification is published in Exchange, MuleSoft automatically generates a REST Connect Connector for that API. This connector simplifies integration as it abstracts the complexity of making HTTP requests and handling OAuth authentication.

Streamlined Integration:

The Process API can import this generated connector from Exchange and configure OAuth credentials, streamlining secure access to the System API without manual HTTP setup.

Why Option C is Correct:

Using the REST Connect Connector directly leverages MuleSoft's automated tooling, minimizing manual configurations and ensuring a more maintainable integration.

of Incorrect Options:

Option A (importing an OAuth module) is unnecessary; OAuth is handled within the connector's configuration.

Option B (property YAML files with HTTP requests) involves manual setup, which is more error-prone and not recommended.

Option D (manually updating POM file) does not directly aid in invoking an API through Exchange.

Reference For more information on using REST Connect Connectors and OAuth integration in MuleSoft, refer to the MuleSoft documentation on API Management and Connectors.

Question 3

An API with multiple API implementations (Mule applications) is deployed to both CloudHub and customer-hosted Mule runtimes. All the deployments are managed by

the MuleSoft-hosted control plane. An alert needs to be triggered whenever an API implementation stops responding to API requests, even if no API clients have called the API implementation for some time.

What is the most effective out-of-the-box solution to create these alerts to monitor the API implementations?

ACreate monitors in Anypoint Functional Monitoring for the API implementations, where each monitor repeatedly invokes an API implementation endpoint

BAdd code to each API client to send an Anypoint Platform REST API request to generate a custom alert in Anypoint Platform when an API invocation times out

CHandle API invocation exceptions within the calling API client and raise an alert from that API client when such an exception is thrown

DConfigure one Worker Not Responding alert.in Anypoint Runtime Manager for all API implementations that will then monitor every API implementation

Answer : A

In scenarios where multiple API implementations are deployed across different environments (CloudHub and customer-hosted runtimes), Anypoint Functional Monitoring is the most effective tool to monitor API availability and trigger alerts when an API implementation becomes unresponsive. Here's how it works:

Using Anypoint Functional Monitoring:

Functional Monitoring allows you to create monitors that periodically invoke specific endpoints on the API implementations, simulating a client request. This helps ensure that the API is responsive, even if no actual client requests are being made.

If an API implementation does not respond as expected, Functional Monitoring can generate alerts, notifying administrators of potential issues.

Why Option A is Correct:

By setting up Functional Monitoring to automatically invoke the API endpoints at regular intervals, you ensure continuous monitoring and alerting capabilities, which are especially useful for APIs that may experience periods of low or no traffic. This approach provides a proactive solution, allowing you to identify and address issues before actual users are impacted.

of Incorrect Options:

Option B suggests modifying client applications to trigger alerts, which is not a best practice as it shifts monitoring responsibility to clients, reducing control and consistency.

Option C involves handling exceptions within client applications, which does not address situations where no clients are making requests.

Option D proposes a Worker Not Responding alert in Runtime Manager, which is limited to worker-specific alerts and may not reliably monitor the API's actual responsiveness to requests.

Reference For further information, refer to MuleSoft documentation on Anypoint Functional Monitoring setup and usage for API availability monitoring.

Question 4

Which out-of-the-box key performance indicator measures the success of a typical Center for Enablement and is immediately available in responses from Anypoint Platform APIs?

APer business group, the ratio of the number of production APT implementations deployed using a C1/CD pipeline to the number of production API implementations deployed manually

BPer deployed API implementation, the amount of bandwidth consumed each day

CPer published API, the number of developers that downloaded s version of the API specification

DPer published API, the number of consumers that requested access to the API and have been approved in the Production environment

Answer : D

Center for Enablement (C4E) KPIs:

A Center for Enablement (C4E) in MuleSoft focuses on enabling self-service and reuse by providing APIs that can be consumed across the organization. A key metric of success is how many consumers are utilizing the published APIs.

The number of consumers who have requested and received access to an API indicates the level of adoption and reuse, which aligns with the goals of a C4E.

Evaluating the Options:

Option A: This metric could indicate deployment automation, but it is not a direct measure of C4E's success in enabling API reuse and consumption.

Option B: Bandwidth usage per API implementation provides insight into API traffic but does not measure C4E enablement or consumer engagement.

Option C: The number of developers downloading an API specification can be an indicator of interest but does not confirm actual usage or enablement.

Option D (Correct Answer): The number of consumers who have requested and received access to an API in production is a key metric indicating API adoption and reuse, which aligns with C4E's goals.

Conclusion:

Option D is the correct answer as it provides a direct measure of consumer engagement and adoption, indicating the success of the C4E in promoting API usage across the organization.

Refer to MuleSoft's documentation on C4E KPIs and API usage metrics for additional insights.

Question 5

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

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

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

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

DWhen ALL backend systems in the application network are deployed in the organization's intranet

Answer : C

Correct Answe r: When regulatory requirements mandate on-premises processing of EVERY data item, including meta-data.

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

We need NOT require to use Anypoint Platform PCE or PCF for the below. So these options are OUT.

>> We can make ALL applications highly available across multiple data centers using CloudHub too.

>> We can use Anypoint VPN and tunneling from CloudHub to connect to ALL backend systems in the application network that are deployed in the organization's intranet.

>> We can use Anypoint VPC and Firewall Rules to make ALL APIs private and NOT exposed to the public cloud.

Only valid reason in the given options that requires to use Anypoint Platform PCE/ PCF is - When regulatory requirements mandate on-premises processing of EVERY data item, including meta-data.

Question 6

How can the application of a rate limiting API policy be accurately reflected in the RAML definition of an API?

ABy refining the resource definitions by adding a description of the rate limiting policy behavior

BBy refining the request definitions by adding a remaining Requests query parameter with description, type, and example

CBy refining the response definitions by adding the out-of-the-box Anypoint Platform rate-limit-enforcement securityScheme with description, type, and example

DBy refining the response definitions by adding the x-ratelimit-* response headers with description, type, and example

Answer : D

Correct Answe r:By refining the response definitions by adding thex-ratelimit-*response headers with description, type, and example

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

https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling#response-headers

https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling-sla-based-policies#response-headers

Question 7

What Anypoint Platform Capabilities listed below fall under APIs and API Invocations/Consumers category? Select TWO.

AAPI Operations and Management

BAPI Runtime Execution and Hosting

CAPI Consumer Engagement

DAPI Design and Development

Answer : D

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

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

Bottom of Form

Top of Form