A system API has a guaranteed SLA of 100 ms per request. The system API is deployed to a primary environment as well as to a disaster recovery (DR) environment, with different DNS names in each environment. An upstream process API invokes the system API and the main goal of this process API is to respond to client requests in the least possible time. In what order should the system APIs be invoked, and what changes should be made in order to speed up the response time for requests from the process API?
A. In parallel, invoke the system API deployed to the primary environment and the system API deployed to the DR environment, and ONLY use the first response
B. In parallel, invoke the system API deployed to the primary environment and the system API deployed to the DR environment using a scatter-gather configured with a timeout, and then merge the responses
C. Invoke the system API deployed to the primary environment, and if it fails, invoke the system API deployed to the DR environment
D. Invoke ONLY the system API deployed to the primary environment, and add timeout and retry logic to avoid intermittent failures
Explanation: Explanation
Correct Answer: In parallel, invoke the system API deployed to the primary environment
and the system API deployed to the DR environment, and ONLY use the first response.
*****************************************
>> The API requirement in the given scenario is to respond in least possible time.
>> The option that is suggesting to first try the API in primary environment and then
fallback to API in DR environment would result in successful response but NOT in least
possible time. So, this is NOT a right choice of implementation for given requirement.
>> Another option that is suggesting to ONLY invoke API in primary environment and to
add timeout and retries may also result in successful response upon retries but NOT in
least possible time. So, this is also NOT a right choice of implementation for given
requirement.
>> One more option that is suggesting to invoke API in primary environment and API in DR
environment in parallel using Scatter-Gather would result in wrong API response as it
would return merged results and moreover, Scatter-Gather does things in parallel which is
true but still completes its scope only on finishing all routes inside it. So again, NOT a right
choice of implementation for given requirement
The Correct choice is to invoke the API in primary environment and the API in DR
environment parallelly, and using ONLY the first response received from one of them
A code-centric API documentation environment should allow API consumers to investigate and execute API client source code that demonstrates invoking one or more APIs as part of representative scenarios. What is the most effective way to provide this type of code-centric API documentation environment using Anypoint Platform?
A. Enable mocking services for each of the relevant APIs and expose them via their Anypoint Exchange entry
B. Ensure the APIs are well documented through their Anypoint Exchange entries and API Consoles and share these pages with all API consumers
C. Create API Notebooks and include them in the relevant Anypoint Exchange entries
D. Make relevant APIs discoverable via an Anypoint Exchange entry
Explanation: Explanation
Correct Answer: Create API Notebooks and Include them in the relevant Anypoint
exchange entries
*****************************************
>> API Notebooks are the one on Anypoint Platform that enable us to provide code-centric
API documentation
: https://docs.mulesoft.com/exchange/to-use-api-notebook
Bottom of Form
Top of Form
An organization wants to create a Center for Enablement (C4E). The IT director schedules a series of meetings with IT senior managers. What should be on the agenda of the first meeting?
A. Define C4E objectives, mission statement, guiding principles, a
B. Explore API monetization options based on identified use cases through MuleSoft
C. A walk through of common-services best practices for logging, auditing, exception handling, caching, security via policy, and rate limiting/throttling via policy
D. Specify operating model for the MuleSoft Integrations division
Explanation:
In the initial meeting for establishing a Center for Enablement (C4E), it’s
essential to lay the foundational vision, objectives, and guiding principles for the team.
Here’s why this is crucial:
Which scenario is suited for MUnit tests instead of integration tests?
A. For read-only interactions to any dependencies (such as other web APIs)
B. When testing does not require knowledge of implementation details
C. When no mocking is permissible
D. For tests that are implemented using SoapUI
Explanation:
MUnit is MuleSoft’s testing framework for creating and running automated
tests within Anypoint Studio. It is specifically designed for unit testing Mule applications and
is best suited when testing doesn’t require understanding the inner workings or
implementation details of the components being tested.
A Platinum customer uses the U.S. control plane and deploys applications to CloudHub in Singapore with a default log configuration. The compliance officer asks where the logs and monitoring data reside?
A. Logs are held in: Singapore and monitoring data is held in the United States
B. Logs and monitoring data are held in the United States
C. Logs are held in the United States and monitoring data is held in Singapore
D. Logs and monitoring data are held in Singapore
Explanation:
For applications deployed on CloudHub in a foreign region (e.g., Singapore),
MuleSoft handles log and monitoring data in the region where the control plane
resides. This data storage policy is standard for CloudHub deployments to maintain
centralized log and monitoring data.
In an organization, the InfoSec team is investigating Anypoint Platform related data traffic. From where does most of the data available to Anypoint Platform for monitoring and alerting originate?
A.
From the Mule runtime or the API implementation, depending on the deployment model
B.
From various components of Anypoint Platform, such as the Shared Load Balancer, VPC, and Mule runtimes
C.
From the Mule runtime or the API Manager, depending on the type of data
D.
From the Mule runtime irrespective of the deployment model
From the Mule runtime irrespective of the deployment model
Explanation: Explanation
Correct Answer: From the Mule runtime irrespective of the deployment model
*****************************************
>> Monitoring and Alerting metrics are always originated from Mule Runtimes irrespective
of the deployment model.
>> It may seems that some metrics (Runtime Manager) are originated from Mule Runtime
and some are (API Invocations/ API Analytics) from API Manager. However, this is
realistically NOT TRUE. The reason is, API manager is just a management tool for API
instances but all policies upon applying on APIs eventually gets executed on Mule
Runtimes only (Either Embedded or API Proxy).
>> Similarly all API Implementations also run on Mule Runtimes.
So, most of the day required for monitoring and alerts are originated fron Mule Runtimes
only irrespective of whether the deployment model is MuleSoft-hosted or Customer-hosted
or Hybrid.
An organization uses various cloud-based SaaS systems and multiple on-premises
systems. The on-premises systems are an important part of the organization's application
network and can only be accessed from within the organization's intranet.
What is the best way to configure and use Anypoint Platform to support integrations with
both the cloud-based SaaS systems and on-premises systems?
A) Use CloudHub-deployed Mule runtimes in an Anypoint VPC managed by Anypoint
Platform Private Cloud Edition control plane
A.
Option A
B.
Option B
C.
Option C
D.
Option D
Option B
Explanation: •Explanation
Correct Answer: Use a combination of CloudHub-deployed and manually provisioned onpremises
Mule runtimes managed by the MuleSoft-hosted Platform control plane.
*****************************************
Key details to be taken from the given scenario:
>> Organization uses BOTH cloud-based and on-premises systems
>> On-premises systems can only be accessed from within the organization's intranet
Let us evaluate the given choices based on above key details:
>> CloudHub-deployed Mule runtimes can ONLY be controlled using MuleSoft-hosted
control plane. We CANNOT use Private Cloud Edition's control plane to control CloudHub
Mule Runtimes. So, option suggesting this is INVALID
>> Using CloudHub-deployed Mule runtimes in the shared worker cloud managed by the
MuleSoft-hosted Anypoint Platform is completely IRRELEVANT to given scenario and silly
choice. So, option suggesting this is INVALID
>> Using an on-premises installation of Mule runtimes that are completely isolated with NO
external network access, managed by the Anypoint Platform Private Cloud Edition control
plane would work for On-premises integrations. However, with NO external access,
integrations cannot be done to SaaS-based apps. Moreover CloudHub-hosted apps are
best-fit for integrating with SaaS-based applications. So, option suggesting this is BEST
WAY.
The best way to configure and use Anypoint Platform to support these mixed/hybrid
integrations is to use a combination of CloudHub-deployed and manually provisioned onpremises
Mule runtimes managed by the MuleSoft-hosted Platform control plane.
A Mule 4 API has been deployed to CloudHub and a Basic Authentication - Simple policy has been applied to all API methods and resources. However, the API is still accessible by clients without using authentication. How is this possible?
A. The APE Router component is pointing to the incorrect Exchange version of the APT
B. The Autodiscovery element is not present, in the deployed Mule application
C. No… for client applications have been created of this API
D. One of the application’s CloudHub workers restarted
Explanation:
When a Basic Authentication policy is applied to an API on CloudHub but
clients can still access the API without authentication, the likely cause is a missing
Autodiscovery element. Here’s how this affects API security:
| Page 1 out of 19 Pages |
Contact Us - Privacy Policy ... Copyright © - All Rights Reserved