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
C. 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
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
What API policy would be LEAST LIKELY used when designing an Experience API that is intended to work with a consumer mobile phone or tablet application?
A. OAuth 2.0 access token enforcement
B. Client ID enforcement
C. JSON threat protection
D. IPwhitellst
Explanation
Correct Answer: IP whitelist
*****************************************
>> OAuth 2.0 access token and Client ID enforcement policies are VERY common to apply
on Experience APIs as API consumers need to register and access the APIs using one of
these mechanisms
>> JSON threat protection is also VERY common policy to apply on Experience APIs to
prevent bad or suspicious payloads hitting the API implementations.
>> IP whitelisting policy is usually very common in Process and System APIs to only
whitelist the IP range inside the local VPC. But also applied occassionally on some
experience APIs where the End User/ API Consumers are FIXED.
>> When we know the API consumers upfront who are going to access certain Experience
APIs, then we can request for static IPs from such consumers and whitelist them to prevent
anyone else hitting the API.
However, the experience API given in the question/ scenario is intended to work with a
consumer mobile phone or tablet application. Which means, there is no way we can know
all possible IPs that are to be whitelisted as mobile phones and tablets can so many in
number and any device in the city/state/country/globe.
So, It is very LEAST LIKELY to apply IP Whitelisting on such Experience APIs whose
consumers are typically Mobile Phones or Tablets.
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
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 do the API invocation metrics provided by Anypoint Platform provide?
A. ROI metrics from APIs that can be directly shared with business users
B. Measurements of the effectiveness of the application network based on the level of reuse
C. Data on past API invocations to help identify anomalies and usage patterns across various APIs
D. Proactive identification of likely future policy violations that exceed a given threat threshold
Explanation
Correct Answer: Data on past API invocations to help identify anomalies and usage
patterns across various APIs
*****************************************
API Invocation metrics provided by Anypoint Platform:
>> Does NOT provide any Return Of Investment (ROI) related information. So the option
suggesting it is OUT.
>> Does NOT provide any information w.r.t how APIs are reused, whether there is effective
usage of APIs or not etc...
>> Does NOT prodive any prediction information as such to help us proactively identify any
future policy violations.
So, the kind of data/information we can get from such metrics is on past API invocations to
help identify anomalies and usage patterns across various APIs.
Reference:
https://usermanual.wiki/Document/APAAppNetstudentManual02may2018.991784750.pdf
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
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.
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
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
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.
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
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
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
When could the API data model of a System API reasonably mimic the data model exposed by the corresponding backend system, with minimal improvements over the backend system's data model?
A. When there is an existing Enterprise Data Model widely used across the organization
B. When the System API can be assigned to a bounded context with a corresponding data model
C. When a pragmatic approach with only limited isolation from the backend system is deemed appropriate
D. When the corresponding backend system is expected to be replaced in the near future
Explanation
Correct Answer: When a pragmatic approach with only limited isolation from the backend
system is deemed appropriate.
*****************************************
General guidance w.r.t choosing Data Models:
>> If an Enterprise Data Model is in use then the API data model of System APIs should
make use of data types from that Enterprise Data Model and the corresponding API
implementation should translate between these data types from the Enterprise Data Model
and the native data model of the backend system.
>> If no Enterprise Data Model is in use then each System API should be assigned to a
Bounded Context, the API data model of System APIs should make use of data types from
the corresponding Bounded Context Data Model and the corresponding API
implementation should translate between these data types from the Bounded Context Data
Model and the native data model of the backend system. In this scenario, the data types in
the Bounded Context Data Model are defined purely in terms of their business
characteristics and are typically not related to the native data model of the backend system.
In other words, the translation effort may be significant.
>> If no Enterprise Data Model is in use, and the definition of a clean Bounded Context
Data Model is considered too much effort, then the API data model of System APIs should
make use of data types that approximately mirror those from the backend system, same
semantics and naming as backend system, lightly sanitized, expose all fields needed for
the given System API’s functionality, but not significantly more and making good use of
REST conventions.
The latter approach, i.e., exposing in System APIs an API data model that basically mirrors
that of the backend system, does not provide satisfactory isolation from backend systems
through the System API tier on its own. In particular, it will typically not be possible to
"swap out" a backend system without significantly changing all System APIs in front of that
backend system and therefore the API implementations of all Process APIs that depend on
those System APIs! This is so because it is not desirable to prolong the life of a previous
backend system’s data model in the form of the API data model of System APIs that now
front a new backend system. The API data models of System APIs following this approach
must therefore change when the backend system is replaced.
On the other hand:
>> It is a very pragmatic approach that adds comparatively little overhead over accessing
the backend system directly
>> Isolates API clients from intricacies of the backend system outside the data model
(protocol, authentication, connection pooling, network address, …)
>> Allows the usual API policies to be applied to System APIs
>> Makes the API data model for interacting with the backend system explicit and visible,
by exposing it in the RAML definitions of the System APIs
>> Further isolation from the backend system data model does occur in the API
implementations of the Process API tier
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
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..
What is true about API implementations when dealing with legal regulations that require all data processing to be performed within a certain jurisdiction (such as in the USA or the EU)?
A. They must avoid using the Object Store as it depends on services deployed ONLY to the US East region
B. They must use a Jurisdiction-local external messaging system such as Active MQ rather than Anypoint MQ
C. They must te deployed to Anypoint Platform runtime planes that are managed by Anypoint Platform control planes, with both planes in the same Jurisdiction
D. They must ensure ALL data is encrypted both in transit and at rest
Explanation
Correct Answer: They must be deployed to Anypoint Platform runtime planes that are
managed by Anypoint Platform control planes, with both planes in the same Jurisdiction.
*****************************************
>> As per legal regulations, all data processing to be performed within a certain jurisdiction.
Meaning, the data in USA should reside within USA and should not go out. Same way, the
data in EU should reside within EU and should not go out.
>> So, just encrypting the data in transit and at rest does not help to be compliant with the
rules. We need to make sure that data does not go out too.
>> The data that we are talking here is not just about the messages that are published to
Anypoint MQ. It includes the apps running, transaction states, application logs, events,
metric info and any other metadata. So, just replacing Anypoint MQ with a locally hosted
ActiveMQ does NOT help.
>> The data that we are talking here is not just about the key/value pairs that are stored in
Object Store. It includes the messages published, apps running, transaction states,
application logs, events, metric info and any other metadata. So, just avoiding using Object
Store does NOT help.
>> The only option left and also the right option in the given choices is to deploy application
on runtime and control planes that are both within the jurisdiction.
| Page 3 out of 13 Pages |
| Previous |