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
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 out-of-the-box key performance indicator measures the success of a typical Center for Enablement and is immediately available in responses from Anypoint Platform APIs?
A. Per business group, the ratio of the number of production APT implementations deployed using a C1/CD pipeline to the number of production API implementations deployed manually
B. Per deployed API implementation, the amount of bandwidth consumed each day
C. Per published API, the number of developers that downloaded s version of the API specification
D. Per published API, the number of consumers that requested access to the API and have been approved in the Production environment
Which APIs can be used with DataGraph to create a unified schema?
A. APIs 1, 3, 5
B. APIs 2, 4 ,6
C. APIs 1, 2, s5, 6
D. APIs 1, 2, 3, 4
Explanation:
To create a unified schema in MuleSoft's DataGraph, APIs must be exposed
in a way that allows DataGraph to pull and consolidate data from these APIs into a single
schema accessible to consumers. DataGraph provides a federated approach, combining
multiple APIs to form a single, unified API endpoint.
In this setup:
APIs 1, 2, 3, and 4 are suitable candidates for DataGraph because they are hosted
within the Customer VPC on CloudHub and are accessible either through a
Shared Load Balancer (LB) or a Dedicated Load Balancer (DLB). Both of these
load balancers provide public access, which is a necessary condition for
DataGraph as it must access the APIs to aggregate data.
APIs 5 and 6 are hosted on Customer Hosted Server 2, which is explicitly marked
as "Not public". Since DataGraph requires API access through a publicly
reachable endpoint to aggregate them into a unified schema, APIs 5 and 6 cannot
be used with DataGraph in this configuration.
APIs 3 and 4 on Customer Hosted Server 1 appear accessible through a Shared
LB, implying public accessibility that meets DataGraph’s requirements.
By combining APIs 1, 2, 3, and 4 within DataGraph, you can create a unified schema that
enables clients to query data seamlessly from all these APIs as if it were from a single
source.
This setup allows for efficient data retrieval and can simplify API consumption by reducing
the need to call multiple APIs individually, thus optimizing performance and developer
experience.
Several times a week, an API implementation shows several thousand requests per minute
in an Anypoint Monitoring dashboard, Between these bursts, the
dashboard shows between two and five requests per minute. The API implementation is
running on Anypoint Runtime Fabric with two non-clustered replicas, reserved vCPU 1.0
and vCPU Limit 2.0.
An API consumer has complained about slow response time, and the dashboard shows the
99 percentile is greater than 120 seconds at the time of the complaint. It also shows greater than 90% CPU usage during these time periods.
In manual tests in the QA environment, the API consumer has consistently reproduced the
slow response time and high CPU usage, and there were no other API requests at
this time. In a brainstorming session, the engineering team has created several proposals
to reduce the response time for requests.
Which proposal should be pursued first?
A. Increase the vCPU resources of the API implementation
B. Modify the API client to split the problematic request into smaller, less-demanding requests
C. Increase the number of replicas of the API implementation
D. Throttle the APT client to reduce the number of requests per minute
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
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.
A company stores financial transaction data in two legacy systems. For each legacy
system, a separate, dedicated System API (SAPI) exposes data for that legacy system. A
Process API (PAPI) merges the data retrieved from ail of the System APIs into a common
format. Several API clients call the PAPI through its public domain name.
The company now wants to expose a subset of financial data to a newly developed mobile
application that uses a different Bounded Context Data Model. The company wants to
follow MuleSoft's best practices for building out an effective application network.
Following MuleSoft's best practices, how can the company expose financial data needed
by the mobile application in a way that minimizes the impact on the currently running API
clients, API implementations, and support asset reuse?
A. Add two new Experience APIs (EAPI-i and EAPI-2}.
Add Mobile PAPI-2 to expose the Intended subset of financial data as requested.
Both PAPIs access the Legacy Systems via SAPI-1 and SAP]-2.
B. Add two new Experience APIs (EAPI-i and EAPI-2}.
Add Mobile PAPI-2 to expose the Intended subset of financial data as requested.
Both PAPIs access the Legacy Systems via SAPI-1 and SAP]-2.
C. Create a new mobile Experince API (EAPI) chat exposes that subset of PAPI endpoints.
Add transformtion login to the mobile Experince API implementation to make mobile data
compatible with the required PAPIs.
D. Develop and deploy is new PAPI implementation with data transformation and ... login to
support this required endpoints of both mobile and web clients.
Deploy an API Proxy with an endpoint from API Manager that redirect the existing PAPI
endpoints to the new PAPI.
Explanation:
To achieve the goal of exposing financial data to a new mobile application while following
MuleSoft’s best practices, the company should follow an API-led connectivity approach.
This approach ensures minimal disruption to existing clients, maximizes reusability, and
respects the separation of concerns across API layers.
Explanation of Solution:
Experience APIs for Client-Specific Requirements:
Process API Layer for Data Transformation:
Reuse of System APIs:
Why Option A is Correct:
Explanation of Incorrect Options:
Option B: This option seems similar but lacks clarity on the separation of mobilespecific
requirements and does not explicitly mention data transformation, which is
essential in this scenario.
Option C: Creating a single mobile Experience API that exposes a subset of PAPI
endpoints directly adds unnecessary complexity and may violate the separation of
concerns, as transformation logic should not be in the Experience layer.
Option D: Deploying a new PAPI and using an API Proxy to redirect existing
endpoints would add unnecessary complexity, disrupt the current API clients, and
increase maintenance efforts.
References:
For additional guidance, refer to MuleSoft documentation on API-led
connectivity best practices and best practices for structuring Experience, Process, and
System APIs.
| Page 1 out of 19 Pages |
Contact Us - Privacy Policy ... Copyright © - All Rights Reserved