When must an API implementation be deployed to an Anypoint VPC?
A.
When the API Implementation must invoke publicly exposed services that are deployed outside of CloudHub in a customer- managed AWS instance
B.
When the API implementation must be accessible within a subnet of a restricted customer-hosted network that does not allow public access
C.
When the API implementation must be deployed to a production AWS VPC using the Mule Maven plugin
D.
When the API Implementation must write to a persistent Object Store
When the API Implementation must invoke publicly exposed services that are deployed outside of CloudHub in a customer- managed AWS instance
The implementation of a Process API must change.What is a valid approach that minimizes the impact of this change on API clients?
A.
Update the RAML definition of the current Process API and notify API client developers
by sending them links to the updated RAML definition
B.
Postpone changes until API consumers acknowledge they are ready to migrate to a new
Process API or API version
C.
Implement required changes to the Process API implementation so that whenever
possible, the Process API's RAML definition remains unchanged
D.
Implement the Process API changes in a new API implementation, and have the old API
implementation return an HTTP status code 301 - Moved Permanently to inform API clients
they should be calling the new API implementation
Implement required changes to the Process API implementation so that whenever
possible, the Process API's RAML definition remains unchanged
Explanation: Explanation
Correct Answer: Implement required changes to the Process API implementation so that,
whenever possible, the Process API’s RAML definition remains unchanged.
*****************************************
Key requirement in the question is:
>> Approach that minimizes the impact of this change on API clients
Based on above:
>> Updating the RAML definition would possibly impact the API clients if the changes
require any thing mandatory from client side. So, one should try to avoid doing that until
really necessary.
>> Implementing the changes as a completely different API and then redirectly the clients
with 3xx status code is really upsetting design and heavily impacts the API clients.
>> Organisations and IT cannot simply postpone the changes required until all API
consumers acknowledge they are ready to migrate to a new Process API or API version.
This is unrealistic and not possible.
The best way to handle the changes always is to implement required changes to the API
implementations so that, whenever possible, the API’s RAML definition remains
unchanged.
Which statement is true about identity management and client management on Anypoint Platform?
A. If an external identity provider is configured, the SAML 2.0 bearer tokens issued by the identity provider cannot be used for invocations of the Anypoint Platform web APIs
B. If an external client provider is configured, it must be configured at the Anypoint Platform organization level and cannot be assigned to individual business groups and environments
C. Anypoint Platform supports configuring one external identity provider
D. Both client management and identity management require an identity provider
Explanation:
Anypoint Platform allows organizations to integrate one external identity
provider (IdP) for identity and access management (IAM), supporting SSO and centralized
user authentication.
A System API is designed to retrieve data from a backend system that has scalability challenges. What API policy can best safeguard the backend system?
A.
IPwhitelist
B.
SLA-based rate limiting
C.
Auth 2 token enforcement
D.
Client ID enforcement
SLA-based rate limiting
Explanation: Explanation
Correct Answer: SLA-based rate limiting
*****************************************
>> Client Id enforement policy is a "Compliance" related NFR and does not help in
maintaining the "Quality of Service (QoS)". It CANNOT and NOT meant for protecting the
backend systems from scalability challenges.
>> IP Whitelisting and OAuth 2.0 token enforcement are "Security" related NFRs and again
does not help in maintaining the "Quality of Service (QoS)". They CANNOT and are NOT
meant for protecting the backend systems from scalability challenges.
Rate Limiting, Rate Limiting-SLA, Throttling, Spike Control are the policies that are "Quality
of Service (QOS)" related NFRs and are meant to help in protecting the backend systems
from getting overloaded.
https://dzone.com/articles/how-to-secure-apis
A customer has an ELA contract with MuleSoft. An API deployed to CloudHub is consistently experiencing performance issues. Based on the root cause analysis, it is determined that autoscaling needs to be applied. How can this be achieved?
A. Configure a policy so that when the number of HTTP requests reaches a certain threshold the number of workers/replicas increases (horizontal scaling)
B. Configure two separate policies: When CPU and memory reach certain threshold, increase the worker/replica type (vertical sealing) and the number of workers/replicas (horizontal sealing)
C. Configure a policy based on CPU usage so that CloudHub auto-adjusts the number of workers/replicas (horizontal scaling)
D. Configure a policy so that when the response time reaches a certain threshold the worker/replica type increases (vertical scaling)
Explanation:
In MuleSoft CloudHub, autoscaling is essential to managing application load
efficiently. CloudHub supports horizontal scaling based on CPU usage, which is wellsuited
to applications experiencing variable demand and needing responsive resource
allocation.
What is typically NOT a function of the APIs created within the framework called API-led connectivity?
A.
They provide an additional layer of resilience on top of the underlying backend system,
thereby insulating clients from extended failure of these systems.
B.
They allow for innovation at the user Interface level by consuming the underlying assets
without being aware of how data Is being extracted from backend systems.
C.
They reduce the dependency on the underlying backend systems by helping unlock data
from backend systems In a reusable and consumable way.
D.
They can compose data from various sources and combine them with orchestration logic to create higher level value.
They provide an additional layer of resilience on top of the underlying backend system,
thereby insulating clients from extended failure of these systems.
Explanation: Explanation
Correct Answer: They provide an additional layer of resilience on top of the underlying
backend system, thereby insulating clients from extended failure of these systems.
*****************************************
In API-led connectivity,
>> Experience APIs - allow for innovation at the user interface level by consuming the
underlying assets without being aware of how data is being extracted from backend
systems.
>> Process APIs - compose data from various sources and combine them with
orchestration logic to create higher level value
>> System APIs - reduce the dependency on the underlying backend systems by helping
unlock data from backend systems in a reusable and consumable way.
However, they NEVER promise that they provide an additional layer of resilience on top of
the underlying backend system, thereby insulating clients from extended failure of these
systems.
https://dzone.com/articles/api-led-connectivity-with-mule
The responses to some HTTP requests can be cached depending on the HTTP verb used
in the request. According to the HTTP specification, for what HTTP verbs is this safe to do?
A.
PUT, POST, DELETE
B.
GET, HEAD, POST
C.
GET, PUT, OPTIONS
D.
GET, OPTIONS, HEAD
GET, OPTIONS, HEAD
The application network is recomposable: it is built for change because it "bends but does
not break"
A.
TRUE
B.
FALSE
TRUE
Explanation: *****************************************
>> Application Network is a disposable architecture.
>> Which means, it can be altered without disturbing entire architecture and its
components.
>> It bends as per requirements or design changes but does not break
Reference: https://www.mulesoft.com/resources/api/what-is-an-application-network
| Page 1 out of 19 Pages |
Contact Us - Privacy Policy ... Copyright © - All Rights Reserved