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.
What is a best practice when building System APIs?
A.
Document the API using an easily consumable asset like a RAML definition
B.
Model all API resources and methods to closely mimic the operations of the backend system
C.
Build an Enterprise Data Model (Canonical Data Model) for each backend system and apply it to System APIs
D.
Expose to API clients all technical details of the API implementation's interaction wifch
the backend system
Model all API resources and methods to closely mimic the operations of the backend system
Explanation: Explanation
Correct Answer: Model all API resources and methods to closely mimic the operations of
the backend system.
*****************************************
>> There are NO fixed and straight best practices while opting data models for APIs. They
are completly contextual and depends on number of factors. Based upon those factors, an
enterprise can choose if they have to go with Enterprise Canonical Data Model or Bounded
Context Model etc.
>> One should NEVER expose the technical details of API implementation to their API
clients. Only the API interface/ RAML is exposed to API clients.
>> It is true that the RAML definitions of APIs should be as detailed as possible and should
reflect most of the documentation. However, just that is NOT enough to call your API as
best documented API. There should be even more documentation on Anypoint Exchange
with API Notebooks etc. to make and create a developer friendly API and repository..
>> The best practice always when creating System APIs is to create their API interfaces by
modeling their resources and methods to closely reflect the operations and functionalities
of that backend system.
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 implemented a Customer Address API to retrieve customer address
information. This API has been deployed to multiple environments and has been configured
to enforce client IDs everywhere.
A developer is writing a client application to allow a user to update their address. The
developer has found the Customer Address API in Anypoint Exchange and wants to use it
in their client application.
What step of gaining access to the API can be performed automatically by Anypoint
Platform?
A.
Approve the client application request for the chosen SLA tier
B.
Request access to the appropriate API Instances deployed to multiple environments using the client application's credentials
C.
Modify the client application to call the API using the client application's credentials
D.
Create a new application in Anypoint Exchange for requesting access to the API
Approve the client application request for the chosen SLA tier
Explanation: Explanation
Correct Answer: Approve the client application request for the chosen SLA tier
*****************************************
>> Only approving the client application request for the chosen SLA tier can be automated
>> Rest of the provided options are not valid
Reference: https://docs.mulesoft.com/api-manager/2.x/defining-sla-tiers#defining-a-tier
What is a key requirement when using an external Identity Provider for Client Management in Anypoint Platform?
A.
Single sign-on is required to sign in to Anypoint Platform
B.
The application network must include System APIs that interact with the Identity
Provider
C.
To invoke OAuth 2.0-protected APIs managed by Anypoint Platform, API clients must submit access tokens issued by that same Identity Provider
D.
APIs managed by Anypoint Platform must be protected by SAML 2.0 policies
To invoke OAuth 2.0-protected APIs managed by Anypoint Platform, API clients must submit access tokens issued by that same Identity Provider
Explanation: https://www.folkstalk.com/2019/11/mulesoft-integration-and-platform.html
Explanation
Correct Answer: To invoke OAuth 2.0-protected APIs managed by Anypoint Platform, API
clients must submit access tokens issued by that same Identity Provider
*****************************************
>> It is NOT necessary that single sign-on is required to sign in to Anypoint Platform
because we are using an external Identity Provider for Client Management
>> It is NOT necessary that all APIs managed by Anypoint Platform must be protected by
SAML 2.0 policies because we are using an external Identity Provider for Client
Management
>> Not TRUE that the application network must include System APIs that interact with the
Identity Provider because we are using an external Identity Provider for Client Management
Only TRUE statement in the given options is - "To invoke OAuth 2.0-protected APIs
managed by Anypoint Platform, API clients must submit access tokens issued by that same
Identity Provider"
References:
https://docs.mulesoft.com/api-manager/2.x/external-oauth-2.0-token-validation-policy
https://blogs.mulesoft.com/dev/api-dev/api-security-ways-to-authenticate-and-authorize/
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/
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/
What is a key performance indicator (KPI) that measures the success of a typical C4E that is immediately apparent in responses from the Anypoint Platform APIs?
A.
The number of production outage incidents reported in the last 24 hours
B.
The number of API implementations that have a publicly accessible HTTP endpoint and are being managed by Anypoint Platform
C.
The fraction of API implementations deployed manually relative to those deployed using a CI/CD tool
D.
The number of API specifications in RAML or OAS format published to Anypoint
Exchange
The number of API specifications in RAML or OAS format published to Anypoint
Exchange
Explanation: Explanation
Correct Answer: The number of API specifications in RAML or OAS format published to
Anypoint Exchange
*****************************************
>> The success of C4E always depends on their contribution to the number of reusable
assets that they have helped to build and publish to Anypoint Exchange.
>> It is NOT due to any factors w.r.t # of outages, Manual vs CI/CD deployments or
Publicly accessible HTTP endpoints
>> Anypoint Platform APIs helps us to quickly run and get the number of published
RAML/OAS assets to Anypoint Exchange. This clearly depicts how successful a C4E team
is based on number of returned assets in the response.
Reference: https://help.mulesoft.com/s/question/0D52T00004mXSTUSA4/how-should-acompany-
measure-c4e-success
An organization has created an API-led architecture that uses various API layers to integrate mobile clients with a backend system. The backend system consists of a number of specialized components and can be accessed via a REST API. The process and
experience APIs share the same bounded-context model that is different from the backend
data model. What additional canonical models, bounded-context models, or anti-corruption
layers are best added to this architecture to help process data consumed from the backend
system?
A.
Create a bounded-context model for every layer and overlap them when the boundary
contexts overlap, letting API developers know about the differences between upstream and
downstream data models
B.
Create a canonical model that combines the backend and API-led models to simplify
and unify data models, and minimize data transformations.
C.
Create a bounded-context model for the system layer to closely match the backend data
model, and add an anti-corruption layer to let the different bounded contexts cooperate
across the system and process layers
D.
Create an anti-corruption layer for every API to perform transformation for every data
model to match each other, and let data simply travel between APIs to avoid the complexity
and overhead of building canonical models
Create a bounded-context model for the system layer to closely match the backend data
model, and add an anti-corruption layer to let the different bounded contexts cooperate
across the system and process layers
Explanation: Explanation
Correct Answer: Create a bounded-context model for the system layer to closely match the
backend data model, and add an anti-corruption layer to let the different bounded contexts
cooperate across the system and process layers
*****************************************
>> Canonical models are not an option here as the organization has already put in efforts
and created bounded-context models for Experience and Process APIs.
>> Anti-corruption layers for ALL APIs is unnecessary and invalid because it is mentioned
that experience and process APIs share same bounded-context model. It is just the System
layer APIs that need to choose their approach now.
>> So, having an anti-corruption layer just between the process and system layers will work
well. Also to speed up the approach, system APIs can mimic the backend system data
model.
What is true about automating interactions with Anypoint Platform using tools such as Anypoint Platform REST APIs, Anypoint CU, or the Mule Maven plugin?
A.
Access to Anypoint Platform APIs and Anypoint CU can be controlled separately through the roles and permissions in Anypoint Platform, so that specific users can get access to Anypoint CLI white others get access to the platform APIs
B.
Anypoint Platform APIs can ONLY automate interactions with CloudHub, while the Mule Maven plugin is required for deployment to customer-hosted Mule runtimes
C.
By default, the Anypoint CLI and Mule Maven plugin are NOT included in the Mule runtime, so are NOT available to be used by deployed Mule applications
D.
API policies can be applied to the Anypoint Platform APIs so that ONLY certain LOBs have access to specific functions
By default, the Anypoint CLI and Mule Maven plugin are NOT included in the Mule runtime, so are NOT available to be used by deployed Mule applications
Explanation: Explanation
Correct Answer: By default, the Anypoint CLI and Mule Maven plugin are NOT included in
the Mule runtime, so are NOT available to be used by deployed Mule applications
*****************************************
>> We CANNOT apply API policies to the Anypoint Platform APIs like we can do on our
custom written API instances. So, option suggesting this is FALSE.
>> Anypoint Platform APIs can be used for automating interactions with both CloudHub
and customer-hosted Mule runtimes. Not JUST the CloudHub. So, option opposing this is
FALSE.
>> Mule Maven plugin is NOT mandatory for deployment to customer-hosted Mule
runtimes. It just helps your CI/CD to have smoother automation. But not a compulsory
requirement to deploy. So, option opposing this is FALSE.
>> We DO NOT have any such special roles and permissions on the platform to separately
control access for some users to have Anypoint CLI and others to have Anypoint Platform
APIs. With proper general roles/permissions (API Owner, Cloudhub Admin etc..), one can
use any of the options (Anypoint CLI or Platform APIs). So, option suggesting this is
FALSE.
Only TRUE statement given in the choices is that - Anypoint CLI and Mule Maven plugin
are NOT included in the Mule runtime, so are NOT available to be used by deployed Mule
applications.
Maven is part of Studio or you can use other Maven installation for development.
CLI is convenience only. It is one of many ways how to install app to the runtime.
These are definitely NOT part of anything except your process of deployment or
automation.
Copyright © - All Rights Reserved