Refer to the exhibit.
A Mule application has an HTTP Listener that accepts HTTP DELETE requests. This Mule application Is deployed to three CloudHub workers under the control of the CloudHub Shared Load Balancer.
A web client makes a sequence of requests to the Mule application's public URL.
How is this sequence of web client requests distributed among the HTTP Listeners running in the three CloudHub workers?

• A.Each request is routed to the PRIMARY CloudHub worker in the PRIMARY Availability Zone (AZ)
• B.Each request is routed to ONE ARBiTRARY CloudHub worker in the PRIMARY Availability Zone (AZ)
• C.Each request Is routed to ONE ARBiTRARY CloudHub worker out of ALL three CloudHub workers
• D.Each request is routed (scattered) to ALL three CloudHub workers at the same time

Comment: *

Name: *

Email: *

Verification: *

The retrieveBalances flow in the Mule application is designed to use an operation in a connector to the Finance system (the Finance operation) that can only look up one account record at a time, and a operation from a different connector to the Audit system (the Audit operation) that can only insert one account record at a time.
To best meet the performance-related requirements, what scope or scopes should be used and how should they be used to incorporate the Finance operation and Audit operation into the retrieveBalances flow?

• A.Wrap the Finance operation in a Parallel For-Each scope. Wrap the Audit operation in a Async scope.
• B.Wrap the Finance operation in a Until-Successful scope. Wrap the Audit operation in a Try-Catch scope.
• C.Wrap both connector operations in a Async scope.
• D.Wrap both connector operations in a For-Each scope.

Comment: *

Name: *

Email: *

Verification: *

When designing an upstream API and its implementation, the development team has been advised to not set timeouts when invoking downstream API. Because the downstream API has no SLA that can be relied upon. This is the only donwstream API dependency of that upstream API. Assume the downstream API runs uninterrupted without crashing. What is the impact of this advice?

• A.The invocation of the downstream API will run to completion without timing out.
• B.An SLA for the upstream API CANNOT be provided.
• C.A default timeout of 500 ms will automatically be applied by the Mule runtime in which the upstream API implementation executes.
• D.A load-dependent timeout of less than 1000 ms will be applied by the Mule runtime in which the downstream API implementation executes.

Comment: *

Name: *

Email: *

Verification: *

According to MuleSoft, which major benefit does a Center for Enablement (C4E) provide for an enterprise and its lines of business?

• A.Enabling Edge security between the lines of business and public devices
• B.Centralizing project management across the lines of business
• C.Centrally managing return on investment (ROI) reporting from lines of business to leadership
• D.Accelerating self-service by the lines of business

Comment: *

Name: *

Email: *

Verification: *

An organization needs to enable access to their customer data from both a mobile app and a web application, which each need access to common fields as well as certain unique fields. The data is available partially in a database and partially in a 3rd-party CRM system. What APIs should be created to best fit these design requirements?

• A.A Process API that contains the data required by both the web and mobile apps, allowing these applications to invoke it directly and access the data they need thereby providing the flexibility to add more fields in the future without needing API changes.
• B.One set of APIs (Experience API, Process API, and System API) for the web app, and another set for the mobile app.
• C.Separate Experience APIs for the mobile and web app, but a common Process API that invokes separate System APIs created for the database and CRM system
• D.A common Experience API used by both the web and mobile apps, but separate Process APIs for the web and mobile apps that interact with the database and the CRM System.

Correct Answer: C

Lets analyze the situation in regards to the different options available Option : A common Experience API but separate Process APIs Analysis : This solution will not work because having common experience layer will not help the purpose as mobile and web applications will have different set of requirements which cannot be fulfilled by single experience layer API Option : Common Process API Analysis : This solution will not work because creating a common process API will impose limitations in terms of flexibility to customize API;s as per the requirements of different applications. It is not a recommended approach.
Option : Separate set of API's for both the applications Analysis : This goes against the principle of Anypoint API-led connectivity approach which promotes creating reusable assets. This solution may work but this is not efficient solution and creates duplicity of code.
Hence the correct answer is: Separate Experience APIs for the mobile and web app, but a common Process API that invokes separate System APIs created for the database and CRM system

Lets analyze the situation in regards to the different options available Option : A common Experience API but separate Process APIs Analysis : This solution will not work because having common experience layer will not help the purpose as mobile and web applications will have different set of requirements which cannot be fulfilled by single experience layer API Option : Common Process API Analysis : This solution will not work because creating a common process API will impose limitations in terms of flexibility to customize API;s as per the requirements of different applications. It is not a recommended approach.
Option : Separate set of API's for both the applications Analysis : This goes against the principle of Anypoint API-led connectivity approach which promotes creating reusable assets. This solution may work but this is not efficient solution and creates duplicity of code.
Hence the correct answer is: Separate Experience APIs for the mobile and web app, but a common Process API that invokes separate System APIs created for the database and CRM system

Comment: *

Name: *

Email: *

Verification: *