Salesforce Certified MuleSoft Platform Architect I Practice Test - Questions Answers, Page 5

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

A higher number of discoverable API-related assets in theapplication network. >> We do NOT get faster response times in fine-grained approach when compared to coarse-grained approach.>> In fact, we get faster response times from a network having coarse-grained APIs compared to a network having fine-grained APIs model. The reasons are below.Fine-grained approach:1. will have more APIs compared to coarse-grained2. So, more orchestration needs to be done to achieve a functionality in business process.3. Which means, lots of API calls to be made. So, more connections will needs to be established. So, obviously more hops, more network i/o, more number of integration points compared to coarse-grained approach where fewer APIs with bulk functionality embedded in them.4. That is why, because of all these extra hops and added latencies, fine-grained approach will have bit more response times compared to coarse-grained.5. Not only added latencies and connections, there will be more resources used up in fine-grained approach due to more number of APIs.That's why, fine-grained APIs are good in a way to expose more number of resuable assets in your network and make them discoverable. However, needs more maintenance, taking care of integration points, connections, resources with a little compromise w.r.t network hops and response times.

They are typically written using MUnit to run in an embedded Muleruntime that does not require external connectivity. Below TWO are characteristics of Integration Tests but NOT unit tests:>> They test the validity of input and output of source and target systems.>> They must be triggered by an external client tool or event source.It is NOT TRUE that Unit Tests must be run in a unit testing environment with dedicated Mule runtimes for the environment.MuleSoft offers MUnit for writing Unit Tests and they run in an embedded Mule Runtime without needing any separate/ dedicated Runtimes to execute them. They also do NOT need any external connectivity as MUnit supports mocking via stubs.https://dzone.com/articles/munit-framework

A CloudHub worker fails with an out-of-memory exception. >> An AWS Region itself going down will definitely result in an outage as it does not matter how many workers are assigned to the Mule App as all of those in that region will go down. This is a complete downtime and outage.>> Extended outage of API manager during initial deployment of API implementation will of course cause issues in proper application startup itself as the API Autodiscovery might fail or API policy templates and polices may not be downloaded to embed at the time of applicaiton startup etc... there are many reasons that could cause issues.>> A network outage onpremises would of course cause the Order Management System not accessible and it does not matter how many workers are assigned to the app they all will fail and cause outage for sure.The only option that does NOT result in a service outage is if a cloudhub worker fails with an out-of-memory exception. Even if a worker fails and goes down, there are still other workers to handle the requests and keep the API UP and Running. So, this is the right answer.

Convince the development team of the product API to adopt the APIdata 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/supplierSo, 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.

Search Anypoint exchange for a suitable existing fallback API, andthen implement invocations to this fallback API in addition to the order API >> It is not ideal and good approach, until unless there is a pre-approved agreement with the API clients that they will receive a HTTP 3xx temporary redirect status code and they have to implement fallback logic their side to call another API.>> Creating separate entry of same Order API in API manager would just create an another instance of it on top of same API implementation. So, it does NO GOOD by using clone od same API as a fallback API. Fallback API should be ideally a different API implementation that is not same as primary one.>> There is NO option currently provided by Anypoint HTTP Connector that allows us to invoke a fallback API when we receive certain HTTP status codes in response.The only statement TRUE in the given options is to Search Anypoint exchange for a suitable existing fallback API, and then implement invocations to this fallback API in addition to the order API.

The API consumer creates an API client, which sends APIinvocations to an API such that they are processed by an API implementation Terminology:>> API Client - It is a piece of code or program the is written to invoke an API>> API Consumer - An owner/entity who owns the API Client. API Consumers write API clients.>> API - The provider of the API functionality. Typically an API Instance on API Manager where they are managed and operated.>> API Implementation - The actual piece of code written by API provider where the functionality of the API is implemented. Typically, these are Mule Applications running on Runtime Manager.

Use a combination of CloudHub-deployed and manually provisionedon-premises Mule runtimes managed by the MuleSoft-hosted Platform control plane. Key details to be taken from the given scenario:>> Organization uses BOTH cloud-based and on-premises systems>> On-premises systems can only be accessed from within the organization's intranetLet us evaluate the given choices based on above key details:>> CloudHub-deployed Mule runtimes can ONLY be controlled using MuleSoft-hosted control plane. We CANNOT use Private Cloud Edition's control plane to control CloudHub Mule Runtimes. So, option suggesting this is INVALID>> Using CloudHub-deployed Mule runtimes in the shared worker cloud managed by the MuleSoft-hosted Anypoint Platform is completely IRRELEVANT to given scenario and silly choice. So, option suggesting this is INVALID>> Using an on-premises installation of Mule runtimes that are completely isolated with NO external network access, managed by the Anypoint Platform Private Cloud Edition control plane would work for On-premises integrations. However, with NO external access, integrations cannot be done to SaaS-based apps. Moreover CloudHub-hosted apps are best-fit for integrating with SaaS-based applications. So, option suggesting this is BEST WAY.The best way to configure and use Anypoint Platform to support these mixed/hybrid integrations is to use a combination of CloudHub-deployed and manually provisioned on-premises Mule runtimes managed by the MuleSoft-hosted Platform control plane.