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
Select the correct Owner-Layer combinations from below options
A.
1. App Developers owns and focuses on Experience Layer APIs
2. Central IT owns and focuses on Process Layer APIs
3. LOB IT owns and focuses on System Layer APIs
B.
1. Central IT owns and focuses on Experience Layer APIs
2. LOB IT owns and focuses on Process Layer APIs
3. App Developers owns and focuses on System Layer APIs
C.
1. App Developers owns and focuses on Experience Layer APIs
2. LOB IT owns and focuses on Process Layer APIs
3. Central IT owns and focuses on System Layer APIs
1. App Developers owns and focuses on Experience Layer APIs
2. LOB IT owns and focuses on Process Layer APIs
3. Central IT owns and focuses on System Layer APIs
Explanation: Explanation
Correct Answer:
1. App Developers owns and focuses on Experience Layer APIs
2. LOB IT owns and focuses on Process Layer APIs
3. Central IT owns and focuses on System Layer APIs
References:
https://blogs.mulesoft.com/biz/api/experience-api-ownership/
https://blogs.mulesoft.com/biz/api/process-api-ownership/
https://blogs.mulesoft.com/biz/api/system-api-ownership
An API has been updated in Anypoint exchange by its API producer from version 3.1.1 to
3.2.0 following accepted semantic versioning practices and the changes have been
communicated via the APIs public portal. The API endpoint does NOT change in the new
version. How should the developer of an API client respond to this change?
A.
The API producer should be requested to run the old version in parallel with the new one
B.
The API producer should be contacted to understand the change to existing functionality
C.
The API client code only needs to be changed if it needs to take advantage of the new features
D.
The API clients need to update the code on their side and need to do full regression
The API client code only needs to be changed if it needs to take advantage of the new features
The responses to some HTTP requests can be cached depending on the HTTP verb used
in the request. According to the HTTP specification, for what HTTP verbs is this safe to do?
A.
PUT, POST, DELETE
B.
GET, HEAD, POST
C.
GET, PUT, OPTIONS
D.
GET, OPTIONS, HEAD
GET, OPTIONS, HEAD
A team is planning to enhance an Experience API specification, and they are following APIled connectivity design principles. What is their motivation for enhancing the API?
A. The primary API consumer wants certain kinds of endpoints changed from the Center for Enablement standard to the consumer system standard
B. The underlying System API is updated to provide more detailed data for several heavily used resources
C. An IP Allowlist policy is being added to the API instances in the Development and Staging environments
D. A Canonical Data Model is being adopted that impacts several types of data included in the API
Explanation:
In API-led design, an Experience API is enhanced to improve how data is
delivered to end-user applications. One primary reason to enhance an Experience API is
when new data standards, such as a Canonical Data Model, are adopted. Here’s why:
A customer has an ELA contract with MuleSoft. An API deployed to CloudHub is consistently experiencing performance issues. Based on the root cause analysis, it is determined that autoscaling needs to be applied. How can this be achieved?
A. Configure a policy so that when the number of HTTP requests reaches a certain threshold the number of workers/replicas increases (horizontal scaling)
B. Configure two separate policies: When CPU and memory reach certain threshold, increase the worker/replica type (vertical sealing) and the number of workers/replicas (horizontal sealing)
C. Configure a policy based on CPU usage so that CloudHub auto-adjusts the number of workers/replicas (horizontal scaling)
D. Configure a policy so that when the response time reaches a certain threshold the worker/replica type increases (vertical scaling)
Explanation:
In MuleSoft CloudHub, autoscaling is essential to managing application load
efficiently. CloudHub supports horizontal scaling based on CPU usage, which is wellsuited
to applications experiencing variable demand and needing responsive resource
allocation.
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.
A retail company is using an Order API to accept new orders. The Order API uses a JMS
queue to submit orders to a backend order management service. The normal load for
orders is being handled using two (2) CloudHub workers, each configured with 0.2 vCore.
The CPU load of each CloudHub worker normally runs well below 70%. However, several
times during the year the Order API gets four times (4x) the average number of orders.
This causes the CloudHub worker CPU load to exceed 90% and the order submission time
to exceed 30 seconds. The cause, however, is NOT the backend order management
service, which still responds fast enough to meet the response SLA for the Order API.
What is the MOST resource-efficient way to configure the Mule application's CloudHub
deployment to help the company cope with this performance challenge?
A.
Permanently increase the size of each of the two (2) CloudHub workers by at least four
times (4x) to one (1) vCore
B.
Use a vertical CloudHub autoscaling policy that triggers on CPU utilization greater than
70%
C.
Permanently increase the number of CloudHub workers by four times (4x) to eight (8)
CloudHub workers
D.
Use a horizontal CloudHub autoscaling policy that triggers on CPU utilization greater
than 70%
Use a horizontal CloudHub autoscaling policy that triggers on CPU utilization greater
than 70%
Explanation: Explanation
Correct Answer: Use a horizontal CloudHub autoscaling policy that triggers on CPU
utilization greater than 70%
*****************************************
The scenario in the question is very clearly stating that the usual traffic in the year is pretty
well handled by the existing worker configuration with CPU running well below 70%. The
problem occurs only "sometimes" occasionally when there is spike in the number of orders
coming in.
So, based on above, We neither need to permanently increase the size of each worker nor
need to permanently increase the number of workers. This is unnecessary as other than
those "occasional" times the resources are idle and wasted.
We have two options left now. Either to use horizontal Cloudhub autoscaling policy to
automatically increase the number of workers or to use vertical Cloudhub autoscaling
policy to automatically increase the vCore size of each worker.
Here, we need to take two things into consideration:
1. CPU
2. Order Submission Rate to JMS Queue
>> From CPU perspective, both the options (horizontal and vertical scaling) solves the
issue. Both helps to bring down the usage below 90%.
>> However, If we go with Vertical Scaling, then from Order Submission Rate perspective,
as the application is still being load balanced with two workers only, there may not be much
improvement in the incoming request processing rate and order submission rate to JMS
queue. The throughput would be same as before. Only CPU utilization comes down.
>> But, if we go with Horizontal Scaling, it will spawn new workers and adds extra hand to
increase the throughput as more workers are being load balanced now. This way we can
address both CPU and Order Submission rate.
Hence, Horizontal CloudHub Autoscaling policy is the right and best answer.
| Page 1 out of 19 Pages |
Contact Us - Privacy Policy ... Copyright © - All Rights Reserved