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.
Refer to the exhibit.
A.
Option A
B.
Option B
C.
Option C
D.
Option D
Option A
Explanation: Explanation
Correct Answer: Ask the Marketing Department to interact with a mocking implementation
of the API using the automatically generated API Console.
*****************************************
As per MuleSoft's IT Operating Model:
>> API consumers need NOT wait until the full API implementation is ready.
>> NO technical test-suites needs to be shared with end users to interact with APIs.
>> Anypoint Platform offers a mocking capability on all the published API specifications to
Anypoint Exchange which also will be rich in documentation covering all details of API
functionalities and working nature.
>> No needs of arranging days of workshops with end users for feedback.
API consumers can use Anypoint Exchange features on the platform and interact with the
API using its mocking feature. The feedback can be shared quickly on the same to
incorporate any changes.
An organization wants MuleSoft-hosted runtime plane features (such as HTTP load balancing, zero downtime, and horizontal and vertical scaling) in its Azure environment. What runtime plane minimizes the organization's effort to achieve these features?
A.
Anypoint Runtime Fabric
B.
Anypoint Platform for Pivotal Cloud Foundry
C.
CloudHub
D.
A hybrid combination of customer-hosted and MuleSoft-hosted Mule runtimes
Anypoint Runtime Fabric
Explanation: Explanation
Correct Answer: Anypoint Runtime Fabric
*****************************************
>> When a customer is already having an Azure environment, It is not at all an ideal
approach to go with hybrid model having some Mule Runtimes hosted on Azure and some
on MuleSoft. This is unnecessary and useless.
>> CloudHub is a Mulesoft-hosted Runtime plane and is on AWS. We cannot customize to
point CloudHub to customer's Azure environment.
>> Anypoint Platform for Pivotal Cloud Foundry is specifically for infrastructure provided by
Pivotal Cloud Foundry
>> Anypoint Runtime Fabric is right answer as it is a container service that automates the
deployment and orchestration of Mule applications and API gateways. Runtime Fabric runs
within a customer-managed infrastructure on AWS, Azure, virtual machines (VMs), and
bare-metal servers.
-Some of the capabilities of Anypoint Runtime Fabric include:
-Isolation between applications by running a separate Mule runtime per application.
-Ability to run multiple versions of Mule runtime on the same set of resources.
-Scaling applications across multiple replicas.
-Automated application fail-over.
-Application management with Anypoint Runtime Manager.
Reference: https://docs.mulesoft.com/runtime-fabric/1.7/
An online store's marketing team has noticed an increase in customers leaving online baskets without checking out. They suspect a technology issue is at the root cause of the baskets being left behind. They approach the Center for Enablement to ask for help identifying the issue. Multiple APIs from across all the layers of their application network are involved in the shopping application. Which feature of the Anypoint Platform can be used to view metrics from all involved APIs at the same time?
A. Custom dashboards
B. Built-in dashboards
C. Functional monitoring
D. API Manager
What correctly characterizes unit tests of Mule applications?
A.
They test the validity of input and output of source and target systems
B.
They must be run in a unit testing environment with dedicated Mule runtimes for the environment
C.
They must be triggered by an external client tool or event source
D.
They are typically written using MUnit to run in an embedded Mule runtime that does not require external connectivity
They are typically written using MUnit to run in an embedded Mule runtime that does not require external connectivity
Explanation: Explanation
Correct Answer: They are typically written using MUnit to run in an embedded Mule runtime
that does not require external connectivity.
*****************************************
Below TWO are characteristics of Integration Tests but NOT unit tests:
>> They test the validity of input and output of source and target systems.
>> They must be triggered by an external client tool or event source.
It is NOT TRUE that Unit Tests must be run in a unit testing environment with dedicated
Mule runtimes for the environment.
MuleSoft offers MUnit for writing Unit Tests and they run in an embedded Mule Runtime
without needing any separate/ dedicated Runtimes to execute them. They also do NOT
need any external connectivity as MUnit supports mocking via stubs.
https://dzone.com/articles/munit-framework
The application network is recomposable: it is built for change because it "bends but does
not break"
A.
TRUE
B.
FALSE
TRUE
Explanation: *****************************************
>> Application Network is a disposable architecture.
>> Which means, it can be altered without disturbing entire architecture and its
components.
>> It bends as per requirements or design changes but does not break
Reference: https://www.mulesoft.com/resources/api/what-is-an-application-network
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.
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
| Page 1 out of 19 Pages |
Contact Us - Privacy Policy ... Copyright © - All Rights Reserved