Which statement is true about Spike Control policy and Rate Limiting policy?
A. All requests are rejected after the limit is reached in Rate Limiting policy, whereas the requests are queued in Spike Control policy after the limit is reached
B. In a clustered environment, the Rate Limiting.and Spike Control policies are applied to each node in the cluster
C. To protect Experience APIs by limiting resource consumption, Rate Limiting policy must be applied
D. In order to apply Rate Limiting and Spike Control policies, a contract to bind client application and API is needed for both
A new upstream API Is being designed to offer an SLA of 500 ms median and 800 ms
maximum (99th percentile) response time. The corresponding API implementation needs to
sequentially invoke 3 downstream APIs of very similar complexity.
The first of these downstream APIs offers the following SLA for its response time: median:
100 ms, 80th percentile: 500 ms, 95th percentile: 1000 ms.
If possible, how can a timeout be set in the upstream API for the invocation of the first
downstream API to meet the new upstream API's desired SLA?
A.
Set a timeout of 50 ms; this times out more invocations of that API but gives additional
room for retries
B.
Set a timeout of 100 ms; that leaves 400 ms for the other two downstream APIs to complete
C.
No timeout is possible to meet the upstream API's desired SLA; a different SLA must be
negotiated with the first downstream API or invoke an alternative API
D.
Do not set a timeout; the Invocation of this API Is mandatory and so we must wait until it
responds
Set a timeout of 100 ms; that leaves 400 ms for the other two downstream APIs to complete
Explanation:
Explanation
Correct Answer: Set a timeout of 100ms; that leaves 400ms for other two downstream APIs
to complete
*****************************************
Key details to take from the given scenario:
>> Upstream API's designed SLA is 500ms (median). Lets ignore maximum SLA response
times.
>> This API calls 3 downstream APIs sequentially and all these are of similar complexity.
>> The first downstream API is offering median SLA of 100ms, 80th percentile: 500ms;
95th percentile: 1000ms.
Based on the above details:
>> We can rule out the option which is suggesting to set 50ms timeout. Because, if the
median SLA itself being offered is 100ms then most of the calls are going to timeout and
time gets wasted in retried them and eventually gets exhausted with all retries. Even if
some retries gets successful, the remaining time wont leave enough room for 2nd and 3rd
downstream APIs to respond within time.
>> The option suggesting to NOT set a timeout as the invocation of this API is mandatory
and so we must wait until it responds is silly. As not setting time out would go against the
good implementation pattern and moreover if the first API is not responding within its
offered median SLA 100ms then most probably it would either respond in 500ms (80th
percentile) or 1000ms (95th percentile). In BOTH cases, getting a successful response
from 1st downstream API does NO GOOD because already by this time the Upstream API
SLA of 500 ms is breached. There is no time left to call 2nd and 3rd downstream APIs.
>> It is NOT true that no timeout is possible to meet the upstream APIs desired SLA.
As 1st downstream API is offering its median SLA of 100ms, it means MOST of the time we
would get the responses within that time. So, setting a timeout of 100ms would be ideal for
MOST calls as it leaves enough room of 400ms for remaining 2 downstream API calls.
Refer to the exhibit.
A.
Option A
B.
Option B
C.
Option C
D.
Option D
Option D
Explanation: Explanation
Correct Answer: XML over HTTP
*****************************************
>> API-led connectivity and Application Networks urge to have the APIs on HTTP based
protocols for building most effective APIs and networks on top of them.
>> The HTTP based APIs allow the platform to apply various varities of policies to address
many NFRs
>> The HTTP based APIs also allow to implement many standard and effective
implementation patterns that adhere to HTTP based w3c rules
Which three tools automate the deployment of Mule applications? (Choose 3 answers)
A. Runtime Manager
B. Anypoint Platform CLI
C. Platform APIs
D. Anypoint Studio
E. Mule Mayen plugin
F. API Community Manager
Explanation:
MuleSoft offers various tools to automate the deployment of Mule
applications, which can streamline deployment and management processes. Here’s how
each tool supports automated deployment:
An organization has several APIs that accept JSON data over HTTP POST. The APIs are
all publicly available and are associated with several mobile applications and web
applications.
The organization does NOT want to use any authentication or compliance policies for these
APIs, but at the same time, is worried that some bad actor could send payloads that could
somehow compromise the applications or servers running the API implementations.
What out-of-the-box Anypoint Platform policy can address exposure to this threat?
A.
Shut out bad actors by using HTTPS mutual authentication for all API invocations
B.
Apply an IP blacklist policy to all APIs; the blacklist will Include all bad actors
C.
Apply a Header injection and removal policy that detects the malicious data before it is used
D.
Apply a JSON threat protection policy to all APIs to detect potential threat vectors
Apply a JSON threat protection policy to all APIs to detect potential threat vectors
Explanation: Explanation
Correct Answer: Apply a JSON threat protection policy to all APIs to detect potential threat
vectors
*****************************************
>> Usually, if the APIs are designed and developed for specific consumers (known
consumers/customers) then we would IP Whitelist the same to ensure that traffic only
comes from them.
>> However, as this scenario states that the APIs are publicly available and being used by
so many mobile and web applications, it is NOT possible to identify and blacklist all
possible bad actors.
>> So, JSON threat protection policy is the best chance to prevent any bad JSON payloads
from such bad actors.
What is the most performant out-of-the-box solution in Anypoint Platform to track
transaction state in an asynchronously executing long-running process implemented as a
Mule application deployed to multiple CloudHub workers?
A.
Redis distributed cache
B.
java.util.WeakHashMap
C.
Persistent Object Store
D.
File-based storage
Persistent Object Store
Explanation: Correct Answer: Persistent Object Store
*****************************************
>> Redis distributed cache is performant but NOT out-of-the-box solution in Anypoint
Platform
>> File-storage is neither performant nor out-of-the-box solution in Anypoint Platform
>> java.util.WeakHashMap needs a completely custom implementation of cache from
scratch using Java code and is limited to the JVM where it is running. Which means the
state in the cache is not worker aware when running on multiple workers. This type of
cache is local to the worker. So, this is neither out-of-the-box nor worker-aware among
multiple workers on cloudhub. https://www.baeldung.com/java-weakhashmap
>> Persistent Object Store is an out-of-the-box solution provided by Anypoint Platform
which is performant as well as worker aware among multiple workers running on
CloudHub. https://docs.mulesoft.com/object-store/
So, Persistent Object Store is the right answer.
An Order API triggers a sequence of other API calls to look up details of an order's items in
a back-end inventory database. The Order API calls the OrderItems process API, which
calls the Inventory system API. The Inventory system API performs database operations in
the back-end inventory database.
The network connection between the Inventory system API and the database is known to
be unreliable and hang at unpredictable times.
Where should a two-second timeout be configured in the API processing sequence so that
the Order API never waits more than two seconds for a response from the Orderltems
process API?
A. In the Orderltems process API implementation
B. In the Order API implementation
C. In the Inventory system API implementation
D. In the inventory database
What is most likely NOT a characteristic of an integration test for a REST API
implementation?
A.
The test needs all source and/or target systems configured and accessible
B.
The test runs immediately after the Mule application has been compiled and packaged
C.
The test is triggered by an external HTTP request
D.
The test prepares a known request payload and validates the response payload
The test runs immediately after the Mule application has been compiled and packaged
Explanation: Explanation
Correct Answer: The test runs immediately after the Mule application has been compiled
and packaged
*****************************************
>> Integration tests are the last layer of tests we need to add to be fully covered.
>> These tests actually run against Mule running with your full configuration in place and are tested from external source as they work in PROD.
>> These tests exercise the application as a whole with actual transports enabled. So,
external systems are affected when these tests run.
So, these tests do NOT run immediately after the Mule application has been compiled and
packaged.
FYI... Unit Tests are the one that run immediately after the Mule application has been
compiled and packaged.
Reference: https://docs.mulesoft.com/mule-runtime/3.9/testing-strategies#integrationtesting
| Page 1 out of 19 Pages |
Contact Us - Privacy Policy ... Copyright © - All Rights Reserved