Salesforce Certified MuleSoft Developer I Practice Test - Questions Answers, Page 6

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.

The test runs immediately after the Mule application has been compiled and packaged. >> Integration tests are the last layer of tests we need to add to be fully covered.>> These tests actually run against Mule running with your full configuration in place and are tested from external source as they work in PROD.>> These tests exercise the application as a whole with actual transports enabled. So, external systems are affected when these tests run.So, these tests do NOT run immediately after the Mule application has been compiled and packaged.FYI... Unit Tests are the one that run immediately after the Mule application has been compiled and packaged.

When the API implementation changes the structure of the request or response messages. >> RAML definition usually needs to be touched only when there are changes in the request/response schemas or in any traits on API.>> It need not be modified for any internal changes in API implementation like performance tuning, backend system migrations etc..