An organization has several APIs that accept JSON data over HTTP POST. The APIs are
all publicly available and are associated with several mobile applications and web
applications.
The organization does NOT want to use any authentication or compliance policies for these
APIs, but at the same time, is worried that some bad actor could send payloads that could
somehow compromise the applications or servers running the API implementations.
What out-of-the-box Anypoint Platform policy can address exposure to this threat?
A.
Shut out bad actors by using HTTPS mutual authentication for all API invocations
B.
Apply an IP blacklist policy to all APIs; the blacklist will Include all bad actors
C.
Apply a Header injection and removal policy that detects the malicious data before it is used
D.
Apply a JSON threat protection policy to all APIs to detect potential threat vectors
Apply a JSON threat protection policy to all APIs to detect potential threat vectors
Explanation: Explanation
Correct Answer: Apply a JSON threat protection policy to all APIs to detect potential threat
vectors
*****************************************
>> Usually, if the APIs are designed and developed for specific consumers (known
consumers/customers) then we would IP Whitelist the same to ensure that traffic only
comes from them.
>> However, as this scenario states that the APIs are publicly available and being used by
so many mobile and web applications, it is NOT possible to identify and blacklist all
possible bad actors.
>> So, JSON threat protection policy is the best chance to prevent any bad JSON payloads
from such bad actors.
An API implementation is updated. When must the RAML definition of the API also be updated?
A.
When the API implementation changes the structure of the request or response messages
B.
When the API implementation changes from interacting with a legacy backend system deployed on-premises to a modern, cloud-based (SaaS) system
C.
When the API implementation is migrated from an older to a newer version of the Mule runtime
D.
When the API implementation is optimized to improve its average response time
When the API implementation changes the structure of the request or response messages
Explanation: Explanation
Correct Answer: When the API implementation changes the structure of the request or
response messages
*****************************************
>> RAML definition usually needs to be touched only when there are changes in the
request/response schemas or in any traits on API.
>> It need not be modified for any internal changes in API implementation like performance
tuning, backend system migrations etc
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:
Refer to the exhibit. An organization needs to enable access to their customer data from
both a mobile app and a web application, which each need access to common fields as
well as certain unique fields.
The data is available partially in a database and partially in a 3rd-party CRM system.
What APIs should be created to best fit these design requirements?
A.
Option A
B.
Option B
C.
Option C
D.
Option D
Option C
Explanation: Explanation
Correct Answer: Separate Experience APIs for the mobile and web app, but a common
Process API that invokes separate System APIs created for the database and CRM system
*****************************************
As per MuleSoft's API-led connectivity:
>> Experience APIs should be built as per each consumer needs and their experience.
>> Process APIs should contain all the orchestration logic to achieve the business
functionality.
>> System APIs should be built for each backend system to unlock their data.
Reference: https://blogs.mulesoft.com/dev/api-dev/what-is-api-led-connectivity
Once an API Implementation is ready and the API is registered on API Manager, who should request the access to the API on Anypoint Exchange?
A.
None
B.
Both
C.
API Client
D.
API Consumer
API Consumer
Explanation: Explanation
Correct Answer: API Consumer
*****************************************
>> API clients are piece of code or programs that use the client credentials of API
consumer but does not directly interact with Anypoint Exchange to get the access
>> API consumer is the one who should get registered and request access to API and then
API client needs to use those client credentials to hit the APIs
So, API consumer is the one who needs to request access on the API from Anypoint
Exchange
4A developer for a transportation organization is implementing exactly one processing
functionality in a Reservation Mule application to process and store passenger
records. This Reservation application will be deployed to multiple CloudHub
workers/replicas. It is possible that several external systems could send duplicate
passenger records
to the Reservation application.
An appropriate storage mechanism must be selected to help the Reservation application
process each passenger record exactly once as much as possible. The selected storage
mechanism must be shared by all the CloudHub workers/replicas in order to synchronize
the state information to assist attempting exactly once processing of each passenger
record by the deployed Reservation Mule application.
Which type of simple storage mechanism in Anypoint Platform allows the Reservation Mule
application to update and share data between the CloudHub workers/replicas exactly
once, with minimal development effort?
A. Persistent Object Store
B. Runtime Fabric Object Store
C. Non-persistent Object Store
D. In-memory Mule Object Store
A company wants to move its Mule API implementations into production as quickly as
possible. To protect access to all Mule application data and metadata, the company
requires that all Mule applications be deployed to the company's customer-hosted
infrastructure within the corporate firewall. What combination of runtime plane and control
plane options meets these project lifecycle goals?
A.
Manually provisioned customer-hosted runtime plane and customer-hosted control plane
B.
MuleSoft-hosted runtime plane and customer-hosted control plane
C.
Manually provisioned customer-hosted runtime plane and MuleSoft-hosted control plane
D.
iPaaS provisioned customer-hosted runtime plane and MuleSoft-hosted control plane
Manually provisioned customer-hosted runtime plane and customer-hosted control plane
Explanation:
Explanation
Correct Answer: Manually provisioned customer-hosted runtime plane and customerhosted
control plane
*****************************************
There are two key factors that are to be taken into consideration from the scenario given in
the question.
>> Company requires both data and metadata to be resided within the corporate firewall
>> Company would like to go with customer-hosted infrastructure.
Any deployment model that is to deal with the cloud directly or indirectly (Mulesoft-hosted
or Customer's own cloud like Azure, AWS) will have to share atleast the metadata.
Application data can be controlled inside firewall by having Mule Runtimes on customer
hosted runtime plane. But if we go with Mulsoft-hosted/ Cloud-based control plane, the
control plane required atleast some minimum level of metadata to be sent outside the
corporate firewall.
As the customer requirement is pretty clear about the data and metadata both to be within
the corporate firewall, even though customer wants to move to production as quickly as
possible, unfortunately due to the nature of their security requirements, they have no other
option but to go with manually provisioned customer-hosted runtime plane and customerhosted
control plane.
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.
| Page 1 out of 19 Pages |