What is the main change to the IT operating model that MuleSoft recommends to
organizations to improve innovation and clock speed?
A.
Drive consumption as much as production of assets; this enables developers to discover
and reuse assets from other projects and encourages standardization
B.
Expose assets using a Master Data Management (MDM) system; this standardizes
projects and enables developers to quickly discover and reuse assets from other projects
C.
Implement SOA for reusable APIs to focus on production over consumption; this
standardizes on XML and WSDL formats to speed up decision making
D.
Create a lean and agile organization that makes many small decisions everyday; this
speeds up decision making and enables each line of business to take ownership of its
projects
Drive consumption as much as production of assets; this enables developers to discover
and reuse assets from other projects and encourages standardization
Explanation: Explanation
Correct Answer: Drive consumption as much as production of assets; this enables
developers to discover and reuse assets from other projects and encourages
standardization
*****************************************
>> The main motto of the new IT Operating Model that MuleSoft recommends and made
popular is to change the way that they are delivered from a production model to a
production + consumption model, which is done through an API strategy called API-led
connectivity.
>> The assets built should also be discoverable and self-serveable for reusablity across
LOBs and organization.
>> MuleSoft's IT operating model does not talk about SDLC model (Agile/ Lean etc) or
MDM at all. So, options suggesting these are not valid.
References:
https://blogs.mulesoft.com/biz/connectivity/what-is-a-center-for-enablement-c4e/
https://www.mulesoft.com/resources/api/secret-to-managing-it-projects
An API experiences a high rate of client requests (TPS) vwth small message paytoads.
How can usage limits be imposed on the API based on the type of client application?
A.
Use an SLA-based rate limiting policy and assign a client application to a matching SLA
tier based on its type
B.
Use a spike control policy that limits the number of requests for each client application
type
C.
Use a cross-origin resource sharing (CORS) policy to limit resource sharing between
client applications, configured by the client application type
D.
Use a rate limiting policy and a client ID enforcement policy, each configured by the
client application type
Use an SLA-based rate limiting policy and assign a client application to a matching SLA
tier based on its type
Explanation: Correct Answer: Use an SLA-based rate limiting policy and assign a client
application to a matching SLA tier based on its type.
*****************************************
>> SLA tiers will come into play whenever any limits to be imposed on APIs based on client
type
Reference: https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling-slabased-
policies
In an organization, the InfoSec team is investigating Anypoint Platform related data traffic. From where does most of the data available to Anypoint Platform for monitoring and alerting originate?
A.
From the Mule runtime or the API implementation, depending on the deployment model
B.
From various components of Anypoint Platform, such as the Shared Load Balancer, VPC, and Mule runtimes
C.
From the Mule runtime or the API Manager, depending on the type of data
D.
From the Mule runtime irrespective of the deployment model
From the Mule runtime irrespective of the deployment model
Explanation: Explanation
Correct Answer: From the Mule runtime irrespective of the deployment model
*****************************************
>> Monitoring and Alerting metrics are always originated from Mule Runtimes irrespective
of the deployment model.
>> It may seems that some metrics (Runtime Manager) are originated from Mule Runtime
and some are (API Invocations/ API Analytics) from API Manager. However, this is
realistically NOT TRUE. The reason is, API manager is just a management tool for API
instances but all policies upon applying on APIs eventually gets executed on Mule
Runtimes only (Either Embedded or API Proxy).
>> Similarly all API Implementations also run on Mule Runtimes.
So, most of the day required for monitoring and alerts are originated fron Mule Runtimes
only irrespective of whether the deployment model is MuleSoft-hosted or Customer-hosted
or Hybrid.
What condition requires using a CloudHub Dedicated Load Balancer?
A.
When cross-region load balancing is required between separate deployments of the same Mule application
B.
When custom DNS names are required for API implementations deployed to customerhosted Mule runtimes
C.
When API invocations across multiple CloudHub workers must be load balanced
D.
When server-side load-balanced TLS mutual authentication is required between API
implementations and API clients
When server-side load-balanced TLS mutual authentication is required between API
implementations and API clients
Explanation: Explanation
Correct Answer: When server-side load-balanced TLS mutual authentication is required
between API implementations and API clients
*****************************************
Fact/ Memory Tip: Although there are many benefits of CloudHub Dedicated Load
balancer, TWO important things that should come to ones mind for considering it are:
>> Having URL endpoints with Custom DNS names on CloudHub deployed apps
>> Configuring custom certificates for both HTTPS and Two-way (Mutual) authentication.
Coming to the options provided for this question:
>> We CANNOT use DLB to perform cross-region load balancing between separate
deployments of the same Mule application.
>> We can have mapping rules to have more than one DLB URL pointing to same Mule
app. But vicevera (More than one Mule app having same DLB URL) is NOT POSSIBLE
>> It is true that DLB helps to setup custom DNS names for Cloudhub deployed Mule apps
but NOT true for apps deployed to Customer-hosted Mule Runtimes.
>> It is true to that we can load balance API invocations across multiple CloudHub workers
using DLB but it is NOT A MUST. We can achieve the same (load balancing) using SLB
(Shared Load Balancer) too. We DO NOT necessarily require DLB for achieve it.
So the only right option that fits the scenario and requires us to use DLB is when TLS
mutual authentication is required between API implementations and API clients.
Reference: https://docs.mulesoft.com/runtime-manager/cloudhub-dedicated-load-balancer
What is true about where an API policy is defined in Anypoint Platform and how it is then applied to API instances?
A.
The API policy Is defined In Runtime Manager as part of the API deployment to a Mule
runtime, and then ONLY applied to the specific API Instance
B.
The API policy Is defined In API Manager for a specific API Instance, and then ONLY
applied to the specific API instance
C.
The API policy Is defined in API Manager and then automatically applied to ALL API instances
D.
The API policy is defined in API Manager, and then applied to ALL API instances in the
specified environment
The API policy Is defined In API Manager for a specific API Instance, and then ONLY
applied to the specific API instance
Explanation: Explanation
Correct Answer: The API policy is defined in API Manager for a specific API instance, and
then ONLY applied to the specific API instance.
*****************************************
>> Once our API specifications are ready and published to Exchange, we need to visit API
Manager and register an API instance for each API.
>> API Manager is the place where management of API aspects takes place like
addressing NFRs by enforcing policies on them.
>> We can create multiple instances for a same API and manage them differently for
different purposes.
>> One instance can have a set of API policies applied and another instance of same API
can have different set of policies applied for some other purpose.
>> These APIs and their instances are defined PER environment basis. So, one need to
manage them seperately in each environment.
>> We can ensure that same configuration of API instances (SLAs, Policies etc..) gets
promoted when promoting to higher environments using platform feature. But this is
optional only. Still one can change them per environment basis if they have to.
>> Runtime Manager is the place to manage API Implementations and their Mule Runtimes
but NOT APIs itself. Though API policies gets executed in Mule Runtimes, We CANNOT
enforce API policies in Runtime Manager. We would need to do that via API Manager only
for a cherry picked instance in an environment.
So, based on these facts, right statement in the given choices is - "The API policy is
defined in API Manager for a specific API instance, and then ONLY applied to the specific
API instance".
Reference: https://docs.mulesoft.com/api-manager/2.x/latest-overview-concept
Mule applications that implement a number of REST APIs are deployed to their own subnet
that is inaccessible from outside the organization.
External business-partners need to access these APIs, which are only allowed to be
invoked from a separate subnet dedicated to partners - called Partner-subnet. This subnet
is accessible from the public internet, which allows these external partners to reach it.
Anypoint Platform and Mule runtimes are already deployed in Partner-subnet. These Mule
runtimes can already access the APIs.
What is the most resource-efficient solution to comply with these requirements, while
having the least impact on other applications that are currently using the APIs?
A.
Implement (or generate) an API proxy Mule application for each of the APIs, then deploy the API proxies to the Mule runtimes
B.
Redeploy the API implementations to the same servers running the Mule runtimes
C.
Add an additional endpoint to each API for partner-enablement consumption
D.
Duplicate the APIs as Mule applications, then deploy them to the Mule runtimes
Implement (or generate) an API proxy Mule application for each of the APIs, then deploy the API proxies to the Mule runtimes
What is true about the technology architecture of Anypoint VPCs?
A.
The private IP address range of an Anypoint VPC is automatically chosen by CloudHub
B.
Traffic between Mule applications deployed to an Anypoint VPC and on-premises
systems can stay within a private network
C.
Each CloudHub environment requires a separate Anypoint VPC
D.
VPC peering can be used to link the underlying AWS VPC to an on-premises (non
AWS) private network
Traffic between Mule applications deployed to an Anypoint VPC and on-premises
systems can stay within a private network
Explanation: Explanation
Correct Answer: Traffic between Mule applications deployed to an Anypoint VPC and onpremises
systems can stay within a private network
*****************************************
>> The private IP address range of an Anypoint VPC is NOT automatically chosen by
CloudHub. It is chosen by us at the time of creating VPC using thr CIDR blocks.
CIDR Block: The size of the Anypoint VPC in Classless Inter-Domain Routing (CIDR)
notation.
For example, if you set it to 10.111.0.0/24, the Anypoint VPC is granted 256 IP addresses
from 10.111.0.0 to 10.111.0.255.
Ideally, the CIDR Blocks you choose for the Anypoint VPC come from a private IP space,
and should not overlap with any other Anypoint VPC’s CIDR Blocks, or any CIDR Blocks in
use in your corporate network.
Which of the following sequence is correct?
A.
API Client implementes logic to call an API >> API Consumer requests access to API >>
API Implementation routes the request to >> API
B.
API Consumer requests access to API >> API Client implementes logic to call an API >>
API routes the request to >> API Implementation
C.
API Consumer implementes logic to call an API >> API Client requests access to API >>
API Implementation routes the request to >> API
D.
API Client implementes logic to call an API >> API Consumer requests access to API >>
API routes the request to >> API Implementation
API Consumer requests access to API >> API Client implementes logic to call an API >>
API routes the request to >> API Implementation
Explanation: Explanation
Correct Answer: API Consumer requests access to API >> API Client implementes logic to
call an API >> API routes the request to >> API Implementation
*****************************************
>> API consumer does not implement any logic to invoke APIs. It is just a role. So, the
option stating "API Consumer implementes logic to call an API" is INVALID.
>> API Implementation does not route any requests. It is a final piece of logic where
functionality of target systems is exposed. So, the requests should be routed to the API
implementation by some other entity. So, the options stating "API Implementation routes
the request to >> API" is INVALID
>> The statements in one of the options are correct but sequence is wrong. The sequence
is given as "API Client implementes logic to call an API >> API Consumer requests access
to API >> API routes the request to >> API Implementation". Here, the statements in the
options are VALID but sequence is WRONG.
>> Right option and sequence is the one where API consumer first requests access to API
on Anypoint Exchange and obtains client credentials. API client then writes logic to call an
API by using the access client credentials requested by API consumer and the requests will
be routed to API implementation via the API which is managed by API Manager
| Page 1 out of 19 Pages |
Contact Us - Privacy Policy ... Copyright © - All Rights Reserved