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
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
An Order API must be designed that contains significant amounts of integration logic and
involves the invocation of the Product API.
The power relationship between Order API and Product API is one of "Customer/Supplier",
because the Product API is used heavily throughout the organization and is developed by a
dedicated development team located in the office of the CTO.
What strategy should be used to deal with the API data model of the Product API within the
Order API?
A.
Convince the development team of the Product API to adopt the API data model of the Order API such that the integration logic of the Order API can work with one consistent internal data model
B.
Work with the API data types of the Product API directly when implementing the integration logic of the Order API such that the Order API uses the same (unchanged) data types as the Product API
C.
Implement an anti-corruption layer in the Order API that transforms the Product API data
model into internal data types of the Order API
D.
Start an organization-wide data modeling initiative that will result in an Enterprise Data
Model that will then be used in both the Product API and the Order API
Implement an anti-corruption layer in the Order API that transforms the Product API data
model into internal data types of the Order API
Explanation: Explanation
Correct Answer: Convince the development team of the product API to adopt the API data
model of the Order API such that integration logic of the Order API can work with one
consistent internal data model
*****************************************
Key details to note from the given scenario:
>> Power relationship between Order API and Product API is customer/supplier
So, as per below rules of "Power Relationships", the caller (in this case Order API) would
request for features to the called (Product API team) and the Product API team would need
to accomodate those requests.
A European company has customers all across Europe, and the IT department is migrating from an older platform to MuleSoft. The main requirements are that the new platform should allow redeployments with zero downtime and deployment of applications to multiple runtime versions, provide security and speed, and utilize Anypoint MQ as the message service. Which runtime plane should the company select based on the requirements without additional network configuration?
A. Runtime Fabric on VMs / Bare Metal for the runtime plane
B. Customer-hosted runtime plane
C. MuleSoft-hosted runtime plane (CloudHub)
D. Anypoint Runtime Fabric on Self-Managed Kubernetes for the runtime plane
Explanation:
For a European company with requirements such as zero-downtime
redeployment, deployment to multiple runtime versions, secure and fast
performance, and the use of Anypoint MQ without additional network configuration,
CloudHub is the best choice for the following reasons:
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 organization requires several APIs to be secured with OAuth 2.0, and PingFederate has been identified as the identity provider for API client authorization, The PingFederate Client Provider is configured in access management, and the PingFederate OAuth 2.0 Token Enforcement policy is configured for the API instances required by the organization. The API instances reside in two business groups (Group A and Group B) within the Master Organization (Master Org). What should be done to allow API consumers to access the API instances?
A. The API administrator should configure the correct client discovery URL in both child business groups, and the API consumer should request access to the API in Ping Identity
B. The API administrator should grant access to the API consumers by creating contracts in the relevant API instances in API Manager
C. The APL consumer should create a client application and request access to the APT in Anypoint Exchange, and the API administrator should approve the request
D. The APT consumer should create a client application and request access to the API in Ping Identity, and the organization's Ping Identity workflow will grant access
An API client calls one method from an existing API implementation. The API
implementation is later updated. What change to the API implementation would require the API client's invocation logic to also be updated?
A.
When the data type of the response is changed for the method called by the API client
B.
When a new method is added to the resource used by the API client
C.
When a new required field is added to the method called by the API client
D.
When a child method is added to the method called by the API client
When a new required field is added to the method called by the API client
Explanation: Explanation
Correct Answer: When a new required field is added to the method called by the API client
*****************************************
>> Generally, the logic on API clients need to be updated when the API contract breaks.
>> When a new method or a child method is added to an API , the API client does not
break as it can still continue to use its existing method. So these two options are out.
>> We are left for two more where "datatype of the response if changed" and "a new
required field is added".
>> Changing the datatype of the response does break the API contract. However, the
question is insisting on the "invocation" logic and not about the response handling logic.
The API client can still invoke the API successfully and receive the response but the
response will have a different datatype for some field.
>> Adding a new required field will break the API's invocation contract. When adding a new
required field, the API contract breaks the RAML or API spec agreement that the API
client/API consumer and API provider has between them. So this requires the API client
invocation logic to also be updated.
Version 3.0.1 of a REST API implementation represents time values in PST time using ISO 8601 hh:mm:ss format. The API implementation needs to be changed to instead represent time values in CEST time using ISO 8601 hh:mm:ss format. When following the semver.org semantic versioning specification, what version should be assigned to the updated API implementation?
A.
3.0.2
B.
4.0.0
C.
3.1.0
D.
3.0.1
4.0.0
Explanation: Explanation
Correct Answer: 4.0.0
*****************************************
As per semver.org semantic versioning specification:
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes.
- MINOR version when you add functionality in a backwards compatible manner.
- PATCH version when you make backwards compatible bug fixes.
As per the scenario given in the question, the API implementation is completely changing
its behavior. Although the format of the time is still being maintained as hh:mm:ss and there
is no change in schema w.r.t format, the API will start functioning different after this change
as the times are going to come completely different.
Example: Before the change, say, time is going as 09:00:00 representing the PST. Now on,
after the change, the same time will go as 18:00:00 as Central European Summer Time is
9 hours ahead of Pacific Time.
>> This may lead to some uncertain behavior on API clients depending on how they are
handling the times in the API response. All the API clients need to be informed that the API
functionality is going to change and will return in CEST format. So, this considered as a
MAJOR change and the version of API for this new change would be 4.0.0
| Page 1 out of 19 Pages |