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
An operations team is analyzing the effort needed to set up monitoring of their application network. They are looking at which API invocation metrics can be used to identify and predict trouble without having to write custom scripts or install additional analytics software or tools. Which type of metrics can satisfy this goal of directly identifying and predicting failures?
A. The number and types of API policy violations per day
B. The effectiveness of the application network based on the level of reuse
C. The number and types of past API invocations across the application network
D. The ROI from each APT invocation
Explanation:
To monitor an application network and predict issues without custom scripts,
policy violation metrics are critical. They provide insights into potential problems by
tracking instances where API usage does not conform to defined policies. Here’s why this
approach is suitable:
A company has created a successful enterprise data model (EDM). The company is
committed to building an application network by adopting modern APIs as a core enabler of
the company's IT operating model. At what API tiers (experience, process, system) should
the company require reusing the EDM when designing modern API data models?
A.
At the experience and process tiers
B.
At the experience and system tiers
C.
At the process and system tiers
D.
At the experience, process, and system tiers
At the process and system tiers
Explanation: Explanation Correct Answer: At the process and system tiers
*****************************************
>> Experience Layer APIs are modeled and designed exclusively for the end user's
experience. So, the data models of experience layer vary based on the nature and type of
such API consumer. For example, Mobile consumers will need light-weight data models to
transfer with ease on the wire, where as web-based consumers will need detailed data
models to render most of the info on web pages, so on. So, enterprise data models fit for
the purpose of canonical models but not of good use for experience APIs.
>> That is why, EDMs should be used extensively in process and system tiers but NOT in
experience tier.
Refer to the exhibit.

A. Option A
B. Option B
C. Option C
D. Option D
Explanation:
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
The Line of Business (LoB) of an eCommerce company is requesting a process that sends automated notifications via email every time a new order is processed through the customer's mobile application or through the internal company's web application. In the future, multiple notification channels may be added: for example, text messages and push notifications. What is the most effective API-led connectivity approach for the scenario described above?
A. Create one Experience API for the web application and one for the mobile application.
Create a Process API to orchestrate and retrieve the email template from = database.
Create a System API that sends the email using the Anypoint Connector for Email.
Create one Experience API for the web application and one for the mobile application.
Create a Process API to orchestrate and retrieve the email template from = database.
Create a System API that sends the email using the Anypoint Connector for Email.
B. Create one Experience API for the web application and one for the mobile application
Create a Process API to orchestrate, retrieve the email template from a database, and
send the email using the Anypoint Connector for Email.

C. Create Experience APIs for both the web application and mobile application.
Create a Process API ta orchestrate, retrieve the email template from e database, and
send the email using the Anypoint Connector for Email.
D. Create Experience APIs for both the web application and mobile application.
(Create 3 Process API to orchestrate and retrieve the email template from 2 database.
Create a System API that sends the email using the Anypoint Connector for Email.
Explanation:
In this scenario, the best approach to satisfy the API-led connectivity
principles and support future scalability is:
Refer to the exhibit.
A developer is building a client application to invoke an API deployed to the STAGING
environment that is governed by a client ID enforcement policy.
What is required to successfully invoke the API?
A.
The client ID and secret for the Anypoint Platform account owning the API in the STAGING environment
B.
The client ID and secret for the Anypoint Platform account's STAGING environment
C.
The client ID and secret obtained from Anypoint Exchange for the API instance in the
STAGING environment
D.
A valid OAuth token obtained from Anypoint Platform and its associated client ID and
secret
The client ID and secret obtained from Anypoint Exchange for the API instance in the
STAGING environment
Explanation: Explanation
Correct Answer: The client ID and secret obtained from Anypoint Exchange for the API
instance in the STAGING environment
*****************************************
>> We CANNOT use the client ID and secret of Anypoint Platform account or any individual
environments for accessing the APIs
>> As the type of policy that is enforced on the API in question is "Client ID Enforcment
Policy", OAuth token based access won't work.
Right way to access the API is to use the client ID and secret obtained from Anypoint
Exchange for the API instance in a particular environment we want to work on.
References:
Managing API instance Contracts on API Manager
https://docs.mulesoft.com/api-manager/1.x/request-access-to-api-task
https://docs.mulesoft.com/exchange/to-request-access
https://docs.mulesoft.com/api-manager/2.x/policy-mule3-client-id-based-policies
A customer wants to host their MuleSoft applications in CloudHub 1.0, and these
applications should be available at the domain https://api.acmecorp.com.
After creating a dedicated load balancer (DLB) called acme-dib-prod, which further action
must the customer take to complete the configuration?
A. Configure the DLB with a TLS certificate for api.acmecorp.com and create an A record for api.acmecorp.com to the public IP addresses associated with their DLB
B. Configure the DLB with a TLS certificate for api.acmecorp.com and create a CNAME record from api.acmecorp.com to acme-dib-prod.|lb.anypointdns.net
C. Configure the DLB with a TLS certificate for acme-dib-prod.Jb.anypointdns.net and create a CNAME record from api.acmecorp:com to acme-dlb-prod.lb.anypointdns.net
D. Configure the DLB with a TLS certificate for aplacmecorp.com and create a CNAME record from api.aomecorp.com to acme-dib-prod.ei.cloubhub.io
Explanation:
When setting up a custom domain for MuleSoft applications hosted on
CloudHub 1.0 using a Dedicated Load Balancer (DLB), follow these steps:
Set Up the TLS Certificate: Configure the DLB (acme-dib-prod) with a TLS
certificate that covers the custom domain api.acmecorp.com. This certificate will
allow HTTPS traffic to be securely directed through the DLB to your Mule
applications.
| Page 1 out of 19 Pages |