True or False. We should always make sure that the APIs being designed and developed are self-servable even if it needs more man-day effort and resources.
A.
FALSE
B.
TRUE
TRUE
Explanation: Explanation
Correct Answer: TRUE
*****************************************
>> As per MuleSoft proposed IT Operating Model, designing APIs and making sure that
they are discoverable and self-servable is VERY VERY IMPORTANT and decides the
success of an API and its application network.
An API has been updated in Anypoint Exchange by its API producer from version 3.1.1 to
3.2.0 following accepted semantic versioning practices and the changes have been
communicated via the API's public portal.
The API endpoint does NOT change in the new version.
How should the developer of an API client respond to this change?
A.
The update should be identified as a project risk and full regression testing of the functionality that uses this API should be run
B.
The API producer should be contacted to understand the change to existing functionality
C.
The API producer should be requested to run the old version in parallel with the new one
D.
The API client code ONLY needs to be changed if it needs to take advantage of new
features
The API client code ONLY needs to be changed if it needs to take advantage of new
features
Reference: https://docs.mulesoft.com/exchange/to-change-raml-version
Mule applications that implement a number of REST APIs are deployed to their own subnet
that is inaccessible from outside the organization.
External business-partners need to access these APIs, which are only allowed to be
invoked from a separate subnet dedicated to partners - called Partner-subnet. This subnet
is accessible from the public internet, which allows these external partners to reach it.
Anypoint Platform and Mule runtimes are already deployed in Partner-subnet. These Mule
runtimes can already access the APIs.
What is the most resource-efficient solution to comply with these requirements, while
having the least impact on other applications that are currently using the APIs?
A.
Implement (or generate) an API proxy Mule application for each of the APIs, then deploy the API proxies to the Mule runtimes
B.
Redeploy the API implementations to the same servers running the Mule runtimes
C.
Add an additional endpoint to each API for partner-enablement consumption
D.
Duplicate the APIs as Mule applications, then deploy them to the Mule runtimes
Implement (or generate) an API proxy Mule application for each of the APIs, then deploy the API proxies to the Mule runtimes
To minimize operation costs, a customer wants to use a CloudHub 1.0 solution. The
customer's requirements are:
A. One production and one non-production Virtual Private Cloud (VPC).
Use availability zones to differentiate between Business groups.
Allocate maximum CIDR per VPCs to ensure HA across availability zones
B. One production and one non-production Virtual Private Cloud (VPC) per Business
group.
Minimize CIDR aligning with projected application total.
Choose a MuleSoft CloudHub 1.0 region with multiple availability zones.
Deploy multiple workers for HA,
C. One production and one non-production Virtual Private Cloud (VPC) per Business
group.
Minimize CIDR aligning with projected application total.
Divide availability zones during deployment of APIs for HA.
D. One production and one non-production Virtual Private Claud (VPC).
Configure subnet to differentiate between business groups.
Allocate maximum CIDR per VPCs to make it easier to add Child groups.
Span VPC to cover three availability zones.
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:
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.
An organization has implemented a Customer Address API to retrieve customer address
information. This API has been deployed to multiple environments and has been configured
to enforce client IDs everywhere.
A developer is writing a client application to allow a user to update their address. The
developer has found the Customer Address API in Anypoint Exchange and wants to use it
in their client application.
What step of gaining access to the API can be performed automatically by Anypoint
Platform?
A.
Approve the client application request for the chosen SLA tier
B.
Request access to the appropriate API Instances deployed to multiple environments using the client application's credentials
C.
Modify the client application to call the API using the client application's credentials
D.
Create a new application in Anypoint Exchange for requesting access to the API
Approve the client application request for the chosen SLA tier
Explanation: Explanation
Correct Answer: Approve the client application request for the chosen SLA tier
*****************************************
>> Only approving the client application request for the chosen SLA tier can be automated
>> Rest of the provided options are not valid
Reference: https://docs.mulesoft.com/api-manager/2.x/defining-sla-tiers#defining-a-tier
Select the correct Owner-Layer combinations from below options
A.
1. App Developers owns and focuses on Experience Layer APIs
2. Central IT owns and focuses on Process Layer APIs
3. LOB IT owns and focuses on System Layer APIs
B.
1. Central IT owns and focuses on Experience Layer APIs
2. LOB IT owns and focuses on Process Layer APIs
3. App Developers owns and focuses on System Layer APIs
C.
1. App Developers owns and focuses on Experience Layer APIs
2. LOB IT owns and focuses on Process Layer APIs
3. Central IT owns and focuses on System Layer APIs
1. App Developers owns and focuses on Experience Layer APIs
2. LOB IT owns and focuses on Process Layer APIs
3. Central IT owns and focuses on System Layer APIs
Explanation: Explanation
Correct Answer:
1. App Developers owns and focuses on Experience Layer APIs
2. LOB IT owns and focuses on Process Layer APIs
3. Central IT owns and focuses on System Layer APIs
References:
https://blogs.mulesoft.com/biz/api/experience-api-ownership/
https://blogs.mulesoft.com/biz/api/process-api-ownership/
https://blogs.mulesoft.com/biz/api/system-api-ownership
| Page 1 out of 19 Pages |