A Mule application exposes an HTTPS endpoint and is deployed to the CloudHub Shared Worker Cloud. All traffic to that Mule application must stay inside the AWS VPC. To what TCP port do API invocations to that Mule application need to be sent?
A.
443
B.
8081
C.
8091
D.
8082
8082
Explanation: Explanation
Correct Answer: 8082
*****************************************
>> 8091 and 8092 ports are to be used when keeping your HTTP and HTTPS app private
to the LOCAL VPC respectively.
>> Above TWO ports are not for Shared AWS VPC/ Shared Worker Cloud.
>> 8081 is to be used when exposing your HTTP endpoint app to the internet through
Shared LB
>> 8082 is to be used when exposing your HTTPS endpoint app to the internet through
Shared LB
So, API invocations should be sent to port 8082 when calling this HTTPS based app.
References:
https://docs.mulesoft.com/runtime-manager/cloudhub-networking-guide
https://help.mulesoft.com/s/article/Configure-Cloudhub-Application-to-Send-a-HTTPSRequest-
Directly-to-Another-Cloudhub-Application
https://help.mulesoft.com/s/question/0D52T00004mXXULSA4/multiple-http-listerners-oncloudhub-
one-with-port-9090
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.
An organization makes a strategic decision to move towards an IT operating model that emphasizes consumption of reusable IT assets using modern APIs (as defined by MuleSoft). What best describes each modern API in relation to this new IT operating model?
A.
Each modern API has its own software development lifecycle, which reduces the need for documentation and automation
B.
Each modem API must be treated like a product and designed for a particular target audience (for instance, mobile app developers)
C.
Each modern API must be easy to consume, so should avoid complex authentication mechanisms such as SAML or JWT D
D.
Each modern API must be REST and HTTP based
Each modem API must be treated like a product and designed for a particular target audience (for instance, mobile app developers)
Explanation: Explanation
Correct Answers:
1. Each modern API must be treated like a product and designed for a particular target
audience (for instance mobile app developers)
*****************************************
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
Refer to the exhibit.
A.
Option A
B.
Option B
C.
Option C
D.
Option D
Option A
Explanation: Explanation
Correct Answer: Ask the Marketing Department to interact with a mocking implementation
of the API using the automatically generated API Console.
*****************************************
As per MuleSoft's IT Operating Model:
>> API consumers need NOT wait until the full API implementation is ready.
>> NO technical test-suites needs to be shared with end users to interact with APIs.
>> Anypoint Platform offers a mocking capability on all the published API specifications to
Anypoint Exchange which also will be rich in documentation covering all details of API
functionalities and working nature.
>> No needs of arranging days of workshops with end users for feedback.
API consumers can use Anypoint Exchange features on the platform and interact with the
API using its mocking feature. The feedback can be shared quickly on the same to
incorporate any changes.
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
Say, there is a legacy CRM system called CRM-Z which is offering below functions:
1. Customer creation
2. Amend details of an existing customer
3. Retrieve details of a customer
4. Suspend a customer
A.
Implement a system API named customerManagement which has all the functionalities
wrapped in it as various operations/resources
B.
Implement different system APIs named createCustomer, amendCustomer,
retrieveCustomer and suspendCustomer as they are modular and has seperation of concerns
C.
Implement different system APIs named createCustomerInCRMZ,
amendCustomerInCRMZ, retrieveCustomerFromCRMZ and suspendCustomerInCRMZ as
they are modular and has seperation of concerns
Implement different system APIs named createCustomer, amendCustomer,
retrieveCustomer and suspendCustomer as they are modular and has seperation of concerns
Correct Answer: Implement different system APIs named createCustomer,
amendCustomer, retrieveCustomer and suspendCustomer as they are modular and has
seperation of concerns
*****************************************
>> It is quite normal to have a single API and different Verb + Resource combinations.
However, this fits well for an Experience API or a Process API but not a best architecture
style for System APIs. So, option with just one customerManagement API is not the best
choice here.
>> The option with APIs in createCustomerInCRMZ format is next close choice w.r.t
modularization and less maintenance but the naming of APIs is directly coupled with the
legacy system. A better foreseen approach would be to name your APIs by abstracting the
backend system names as it allows seamless replacement/migration of any backend
system anytime. So, this is not the correct choice too.
>> createCustomer, amendCustomer, retrieveCustomer and suspendCustomer is the right
approach and is the best fit compared to other options as they are both modular and same
time got the names decoupled from backend system and it has covered all requirements a
System API needs.
When must an API implementation be deployed to an Anypoint VPC?
A.
When the API Implementation must invoke publicly exposed services that are deployed outside of CloudHub in a customer- managed AWS instance
B.
When the API implementation must be accessible within a subnet of a restricted customer-hosted network that does not allow public access
C.
When the API implementation must be deployed to a production AWS VPC using the Mule Maven plugin
D.
When the API Implementation must write to a persistent Object Store
When the API Implementation must invoke publicly exposed services that are deployed outside of CloudHub in a customer- managed AWS instance
| Page 1 out of 19 Pages |
Contact Us - Privacy Policy ... Copyright © - All Rights Reserved