An organization uses various cloud-based SaaS systems and multiple on-premises
systems. The on-premises systems are an important part of the organization's application
network and can only be accessed from within the organization's intranet.
What is the best way to configure and use Anypoint Platform to support integrations with
both the cloud-based SaaS systems and on-premises systems?
A) Use CloudHub-deployed Mule runtimes in an Anypoint VPC managed by Anypoint
Platform Private Cloud Edition control plane
A.
Option A
B.
Option B
C.
Option C
D.
Option D
Option B
Explanation: •Explanation
Correct Answer: Use a combination of CloudHub-deployed and manually provisioned onpremises
Mule runtimes managed by the MuleSoft-hosted Platform control plane.
*****************************************
Key details to be taken from the given scenario:
>> Organization uses BOTH cloud-based and on-premises systems
>> On-premises systems can only be accessed from within the organization's intranet
Let us evaluate the given choices based on above key details:
>> CloudHub-deployed Mule runtimes can ONLY be controlled using MuleSoft-hosted
control plane. We CANNOT use Private Cloud Edition's control plane to control CloudHub
Mule Runtimes. So, option suggesting this is INVALID
>> Using CloudHub-deployed Mule runtimes in the shared worker cloud managed by the
MuleSoft-hosted Anypoint Platform is completely IRRELEVANT to given scenario and silly
choice. So, option suggesting this is INVALID
>> Using an on-premises installation of Mule runtimes that are completely isolated with NO
external network access, managed by the Anypoint Platform Private Cloud Edition control
plane would work for On-premises integrations. However, with NO external access,
integrations cannot be done to SaaS-based apps. Moreover CloudHub-hosted apps are
best-fit for integrating with SaaS-based applications. So, option suggesting this is BEST
WAY.
The best way to configure and use Anypoint Platform to support these mixed/hybrid
integrations is to use a combination of CloudHub-deployed and manually provisioned onpremises
Mule runtimes managed by the MuleSoft-hosted Platform control plane.
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 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
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
A team is planning to enhance an Experience API specification, and they are following APIled connectivity design principles. What is their motivation for enhancing the API?
A. The primary API consumer wants certain kinds of endpoints changed from the Center for Enablement standard to the consumer system standard
B. The underlying System API is updated to provide more detailed data for several heavily used resources
C. An IP Allowlist policy is being added to the API instances in the Development and Staging environments
D. A Canonical Data Model is being adopted that impacts several types of data included in the API
Explanation:
In API-led design, an Experience API is enhanced to improve how data is
delivered to end-user applications. One primary reason to enhance an Experience API is
when new data standards, such as a Canonical Data Model, are adopted. Here’s why:
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.
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:
Which of the following best fits the definition of API-led connectivity?
A.
API-led connectivity is not just an architecture or technology but also a way to organize people and processes for efficient IT delivery in the organization
B.
API-led connectivity is a 3-layered architecture covering Experience, Process and System layers
C.
API-led connectivity is a technology which enabled us to implement Experience, Process and System layer based APIs
API-led connectivity is not just an architecture or technology but also a way to organize people and processes for efficient IT delivery in the organization
Explanation: Explanation
Correct Answer: API-led connectivity is not just an architecture or technology but also a
way to organize people and processes for efficient IT delivery in the organization.
*****************************************
Reference: https://blogs.mulesoft.com/dev/api-dev/what-is-api-led-connectivity/
| Page 1 out of 19 Pages |
Contact Us - Privacy Policy ... Copyright © - All Rights Reserved