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
What API policy would be LEAST LIKELY used when designing an Experience API that is intended to work with a consumer mobile phone or tablet application?
A.
OAuth 2.0 access token enforcement
B.
Client ID enforcement
C.
JSON threat protection
D.
IPwhitellst
IPwhitellst
Explanation: Explanation
Correct Answer: IP whitelist
*****************************************
>> OAuth 2.0 access token and Client ID enforcement policies are VERY common to apply
on Experience APIs as API consumers need to register and access the APIs using one of
these mechanisms
>> JSON threat protection is also VERY common policy to apply on Experience APIs to
prevent bad or suspicious payloads hitting the API implementations.
>> IP whitelisting policy is usually very common in Process and System APIs to only
whitelist the IP range inside the local VPC. But also applied occassionally on some
experience APIs where the End User/ API Consumers are FIXED.
>> When we know the API consumers upfront who are going to access certain Experience
APIs, then we can request for static IPs from such consumers and whitelist them to prevent
anyone else hitting the API.
However, the experience API given in the question/ scenario is intended to work with a
consumer mobile phone or tablet application. Which means, there is no way we can know
all possible IPs that are to be whitelisted as mobile phones and tablets can so many in
number and any device in the city/state/country/globe.
So, It is very LEAST LIKELY to apply IP Whitelisting on such Experience APIs whose
consumers are typically Mobile Phones or Tablets.
A company uses a hybrid Anypoint Platform deployment model that combines the EU
control plane with customer-hosted Mule runtimes. After successfully testing a Mule API
implementation in the Staging environment, the Mule API implementation is set with
environment-specific properties and must be promoted to the Production environment.
What is a way that MuleSoft recommends to configure the Mule API implementation and
automate its promotion to the Production environment?
A.
Bundle properties files for each environment into the Mule API implementation's deployable
archive, then promote the Mule API implementation to the Production environment using
Anypoint CLI or the Anypoint Platform REST APIsB.
B.
Modify the Mule API implementation's properties in the API Manager Properties tab, then
promote the Mule API implementation to the Production environment using API Manager
C.
Modify the Mule API implementation's properties in Anypoint Exchange, then promote the
Mule API implementation to the Production environment using Runtime Manager
D.
Use an API policy to change properties in the Mule API implementation deployed to the
Staging environment and another API policy to deploy the Mule API implementation to the
Production environment
Bundle properties files for each environment into the Mule API implementation's deployable
archive, then promote the Mule API implementation to the Production environment using
Anypoint CLI or the Anypoint Platform REST APIsB.
Explanation: Explanation
Correct Answer: Bundle properties files for each environment into the Mule API
implementation's deployable archive, then promote the Mule API implementation to the
Production environment using Anypoint CLI or the Anypoint Platform REST APIs
*****************************************
>> Anypoint Exchange is for asset discovery and documentation. It has got no provision to
modify the properties of Mule API implementations at all.
>> API Manager is for managing API instances, their contracts, policies and SLAs. It has
also got no provision to modify the properties of API implementations.
>> API policies are to address Non-functional requirements of APIs and has again got no
provision to modify the properties of API implementations.
So, the right way and recommended way to do this as part of development practice is to
bundle properties files for each environment into the Mule API implementation and just
point and refer to respective file per environment.
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
A REST API is being designed to implement a Mule application.
What standard interface definition language can be used to define REST APIs?
A.
Web Service Definition Language(WSDL)
B.
OpenAPI Specification (OAS)
C.
YAML
D.
AsyncAPI Specification
OpenAPI Specification (OAS)
Which of the below, when used together, makes the IT Operational Model effective?
A.
Create reusable assets, Do marketing on the created assets across organization, Arrange time to time LOB reviews to ensure assets are being consumed or not
B.
Create reusable assets, Make them discoverable so that LOB teams can self-serve and browse the APIs, Get active feedback and usage metrics
C.
Create resuable assets, make them discoverable so that LOB teams can self-serve and browse the APIs
Create resuable assets, make them discoverable so that LOB teams can self-serve and browse the APIs
Explanation: Explanation
Correct Answer: Create reusable assets, Make them discoverable so that LOB teams can self-serve and browse the APIs, Get active feedback and usage metrics.
Diagram, arrow
Description automatically generated
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 organization wants to make sure only known partners can invoke the organization's
APIs. To achieve this security goal, the organization wants to enforce a Client ID
Enforcement policy in API Manager so that only registered partner applications can invoke
the organization's APIs. In what type of API implementation does MuleSoft recommend
adding an API proxy to enforce the Client ID Enforcement policy, rather than embedding
the policy directly in the application's JVM?
A.
A Mule 3 application using APIkit
B.
A Mule 3 or Mule 4 application modified with custom Java code
C.
A Mule 4 application with an API specification
D.
A Non-Mule application
A Non-Mule application
Explanation: Explanation
Correct Answer: A Non-Mule application
*****************************************
>> All type of Mule applications (Mule 3/ Mule 4/ with APIkit/ with Custom Java Code etc)
running on Mule Runtimes support the Embedded Policy Enforcement on them.
>> The only option that cannot have or does not support embedded policy enforcement
and must have API Proxy is for Non-Mule Applications.
So, Non-Mule application is the right answer
| Page 1 out of 19 Pages |