When can CloudHub Object Store v2 be used?
A. To store an unlimited number of key-value pairs
B. To store payloads with an average size greater than 15MB
C. To store information in Mule 4 Object Store v1
D. To store key-value pairs with keys up to 300 characters
Explanation: CloudHub Object Store v2 is a managed key-value store provided by
MuleSoft to support various use cases where temporary data storage is required. Here’s
why Option D is correct:
Key Length Support: Object Store v2 allows storage of keys with a length of up to
300 characters, making it suitable for applications needing flexible and descriptive
keys.
Limitations on Size:
Key-Value Limits: Object Store v2 is designed for moderate, transient storage
needs, and does not support unlimited storage. Thus, Option A is incorrect.
Backward Compatibility: Object Store v2 does not support Mule 4 applications
running Object Store v1. Option C is incorrect as Object Store v1 and v2 are
distinct.
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.
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:
An API implementation is being designed that must invoke an Order API, which is known to
repeatedly experience downtime.
For this reason, a fallback API is to be called when the Order API is unavailable.
What approach to designing the invocation of the fallback API provides the best resilience?
A.
Search Anypoint Exchange for a suitable existing fallback API, and then implement
invocations to this fallback API in addition to the Order API
B.
Create a separate entry for the Order API in API Manager, and then invoke this API as a
fallback API if the primary Order API is unavailable
C.
Redirect client requests through an HTTP 307 Temporary Redirect status code to the
fallback API whenever the Order API is unavailable
D.
Set an option in the HTTP Requester component that invokes the Order API to instead
invoke a fallback API whenever an HTTP 4xx or 5xx response status code is returned from
the Order API
Search Anypoint Exchange for a suitable existing fallback API, and then implement
invocations to this fallback API in addition to the Order API
Explanation: Explanation
Correct Answer: Search Anypoint exchange for a suitable existing fallback API, and then
implement invocations to this fallback API in addition to the order API
*****************************************
>> It is not ideal and good approach, until unless there is a pre-approved agreement with
the API clients that they will receive a HTTP 3xx temporary redirect status code and they
have to implement fallback logic their side to call another API.
>> Creating separate entry of same Order API in API manager would just create an
another instance of it on top of same API implementation. So, it does NO GOOD by using
clone od same API as a fallback API. Fallback API should be ideally a different API
implementation that is not same as primary one.
>> There is NO option currently provided by Anypoint HTTP Connector that allows us to
invoke a fallback API when we receive certain HTTP status codes in response.
The only statement TRUE in the given options is to Search Anypoint exchange for a
suitable existing fallback API, and then implement invocations to this fallback API in
addition to the order API.
Which of the following sequence is correct?
A.
API Client implementes logic to call an API >> API Consumer requests access to API >>
API Implementation routes the request to >> API
B.
API Consumer requests access to API >> API Client implementes logic to call an API >>
API routes the request to >> API Implementation
C.
API Consumer implementes logic to call an API >> API Client requests access to API >>
API Implementation routes the request to >> API
D.
API Client implementes logic to call an API >> API Consumer requests access to API >>
API routes the request to >> API Implementation
API Consumer requests access to API >> API Client implementes logic to call an API >>
API routes the request to >> API Implementation
Explanation: Explanation
Correct Answer: API Consumer requests access to API >> API Client implementes logic to
call an API >> API routes the request to >> API Implementation
*****************************************
>> API consumer does not implement any logic to invoke APIs. It is just a role. So, the
option stating "API Consumer implementes logic to call an API" is INVALID.
>> API Implementation does not route any requests. It is a final piece of logic where
functionality of target systems is exposed. So, the requests should be routed to the API
implementation by some other entity. So, the options stating "API Implementation routes
the request to >> API" is INVALID
>> The statements in one of the options are correct but sequence is wrong. The sequence
is given as "API Client implementes logic to call an API >> API Consumer requests access
to API >> API routes the request to >> API Implementation". Here, the statements in the
options are VALID but sequence is WRONG.
>> Right option and sequence is the one where API consumer first requests access to API
on Anypoint Exchange and obtains client credentials. API client then writes logic to call an
API by using the access client credentials requested by API consumer and the requests will
be routed to API implementation via the API which is managed by API Manager
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:
What is a key requirement when using an external Identity Provider for Client Management in Anypoint Platform?
A.
Single sign-on is required to sign in to Anypoint Platform
B.
The application network must include System APIs that interact with the Identity
Provider
C.
To invoke OAuth 2.0-protected APIs managed by Anypoint Platform, API clients must submit access tokens issued by that same Identity Provider
D.
APIs managed by Anypoint Platform must be protected by SAML 2.0 policies
To invoke OAuth 2.0-protected APIs managed by Anypoint Platform, API clients must submit access tokens issued by that same Identity Provider
Explanation: https://www.folkstalk.com/2019/11/mulesoft-integration-and-platform.html
Explanation
Correct Answer: To invoke OAuth 2.0-protected APIs managed by Anypoint Platform, API
clients must submit access tokens issued by that same Identity Provider
*****************************************
>> It is NOT necessary that single sign-on is required to sign in to Anypoint Platform
because we are using an external Identity Provider for Client Management
>> It is NOT necessary that all APIs managed by Anypoint Platform must be protected by
SAML 2.0 policies because we are using an external Identity Provider for Client
Management
>> Not TRUE that the application network must include System APIs that interact with the
Identity Provider because we are using an external Identity Provider for Client Management
Only TRUE statement in the given options is - "To invoke OAuth 2.0-protected APIs
managed by Anypoint Platform, API clients must submit access tokens issued by that same
Identity Provider"
References:
https://docs.mulesoft.com/api-manager/2.x/external-oauth-2.0-token-validation-policy
https://blogs.mulesoft.com/dev/api-dev/api-security-ways-to-authenticate-and-authorize/
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:
| Page 1 out of 19 Pages |
Contact Us - Privacy Policy ... Copyright © - All Rights Reserved