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?
A. Create monitors in Anypoint Functional Monitoring for the API implementations, where each monitor repeatedly invokes an API implementation endpoint
B. Add 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
C. Handle API invocation exceptions within the calling API client and raise an alert from that API client when such an exception is thrown
D. Configure one Worker Not Responding alert.in Anypoint Runtime Manager for all API implementations that will then monitor every API implementation
Explanation:
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:
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?
A.
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
B.
Create a canonical model that combines the backend and API-led models to simplify
and unify data models, and minimize data transformations.
C.
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
D.
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
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
Explanation: Explanation
Correct Answer: 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
*****************************************
>> Canonical models are not an option here as the organization has already put in efforts
and created bounded-context models for Experience and Process APIs.
>> Anti-corruption layers for ALL APIs is unnecessary and invalid because it is mentioned
that experience and process APIs share same bounded-context model. It is just the System
layer APIs that need to choose their approach now.
>> So, having an anti-corruption layer just between the process and system layers will work
well. Also to speed up the approach, system APIs can mimic the backend system data
model.
Refer to the exhibit.
A. Option A
B. Option B
C. Option C
D. Option D
Explanation:
Correct Answer: Allow System APIs to return data that is NOT currently required by the
identified Process or Experience APIs.
What API policy would LEAST likely be applied to a Process API?
A.
Custom circuit breaker
B.
Client ID enforcement
C.
Rate limiting
D.
JSON threat protection
JSON threat protection
Explanation: Explanation
Correct Answer: JSON threat protection
*****************************************
Fact: Technically, there are no restrictions on what policy can be applied in what layer. Any
policy can be applied on any layer API. However, context should also be considered
properly before blindly applying the policies on APIs.
That is why, this question asked for a policy that would LEAST likely be applied to a
Process API.
From the given options:
>> All policies except "JSON threat protection" can be applied without hesitation to the
APIs in Process tier.
>> JSON threat protection policy ideally fits for experience APIs to prevent suspicious
JSON payload coming from external API clients. This covers more of a security aspect by
trying to avoid possibly malicious and harmful JSON payloads from external clients calling
experience APIs.
As external API clients are NEVER allowed to call Process APIs directly and also these
kind of malicious and harmful JSON payloads are always stopped at experience API layer
only using this policy, it is LEAST LIKELY that this same policy is again applied on Process
Layer API.
An enterprise is embarking on the API-led digital transformation journey, and the central IT team has started to define System APIs. Currently there is no Enterprise Data Model being defined within the enterprise, and the definition of a clean Bounded Context Data Model requires too much effort. According to MuleSoft's recommended guidelines, how should the System API data model be defined?
A. If there are misspellings of the data fields in the back-end system, Systerm APIs should not correct it, and expose it as-is to mirror the back-end systems
B. The data model of the System APIs should make use of data types that approximately mirror those from the back-end systems
C. The data model should define its own naming convention, and not follow the same naming as the back-end systems
D. The System APIs should expose all back-end system fields
Explanation: When defining data models for System APIs without an established
Enterprise Data Model, MuleSoft recommends mirroring the back-end systems' data
types to achieve quick and effective integration without adding complexity. This approach
has several benefits:
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.
A Mule 3 application using APIkit
B.
A Mule 3 or Mule 4 application modified with custom Java code
C.
A Mule 4 application with an API specification
D.
A Non-Mule application
A Non-Mule application
Explanation: Explanation
Correct Answer: A Non-Mule application
*****************************************
>> All type of Mule applications (Mule 3/ Mule 4/ with APIkit/ with Custom Java Code etc)
running on Mule Runtimes support the Embedded Policy Enforcement on them.
>> The only option that cannot have or does not support embedded policy enforcement
and must have API Proxy is for Non-Mule Applications.
So, Non-Mule application is the right answer
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?
A.
Workers belonging to a given environment are assigned to the same AZ within that region
B.
AZs are selected as part of the Mule application's deployment configuration
C.
Workers are randomly distributed across available AZs within that region
D.
An AZ is randomly selected for a Mule application, and all the Mule application's CloudHub workers are assigned to that one AZ
An AZ is randomly selected for a Mule application, and all the Mule application's CloudHub workers are assigned to that one AZ
Explanation: Explanation
Correct Answer: Workers are randomly distributed across available AZs within that region.
*****************************************
>> Currently, we only have control to choose which AWS Region to choose but there is no
control at all using any configurations or deployment options to decide what Availability
Zone (AZ) to assign to what worker.
>> There are NO fixed or implicit rules on platform too w.r.t assignment of AZ to workers
based on environment or application.
>> They are completely assigned in random. However, cloudhub definitely ensures that
HA is achieved by assigning the workers to more than on AZ so that all workers are not
assigned to same AZ for same application.
: https://help.mulesoft.com/s/question/0D52T000051rqDj/one-cloudhub-aws-region-howcloudhub-
workers-are-assigned-to-availability-zones-azs-
Graphical user interface, application
Description automatically generated
Bottom of Form
Top of Form
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?
A.
The API producer should be requested to run the old version in parallel with the new one
B.
The API producer should be contacted to understand the change to existing functionality
C.
The API client code only needs to be changed if it needs to take advantage of the new features
D.
The API clients need to update the code on their side and need to do full regression
The API client code only needs to be changed if it needs to take advantage of the new features
| Page 1 out of 19 Pages |
Contact Us - Privacy Policy ... Copyright © - All Rights Reserved