Certified MuleSoft Developer I: Salesforce Certified MuleSoft Developer I

API implementations can run successfully in customer-hosted Muleruntimes, even when they are unable to communicate with the control plane.. >>We CANNOT use Shared Load balancer to load balance APIs on customer hosted runtimes

>>For Hybrid deployment models, the on-premises are first connected to Runtime Manager usingRuntime Manager agent.So, the connection is initiated first from On-premises to Runtime Manager. Then all control can be done from Runtime Manager.>>Anypoint Runtime Manager CANNOT ensure automatic HA. Clusters/Server Groups etc should be configured before hand.Only TRUE statement in the given choices is, API implementations can run successfully in customer-hosted Mule runtimes, even when they are unable to communicate with the control plane. There are several references below to justify this statement.https://docs.mulesoft.com/runtime-manager/deployment-strategies#hybrid-deploymentshttps://help.mulesoft.com/s/article/On-Premise-Runtimes-Disconnected-From-US-Control-Plane-June-18th-2018https://help.mulesoft.com/s/article/Runtime-Manager-cannot-manage-On-Prem-Applications-and-Servers-from-US-Control-Plane-June-25th-2019https://help.mulesoft.com/s/article/On-premise-Runtimes-Appear-Disconnected-in-Runtime-Manager-May-29th-2018========================================================

When the response time of API invocations exceeds a threshold. >> Alerts can be setup for all the given options using the default Anypoint Platform functionality>> However, the question insists on an alert whose conditions depend on the end-to-end request processing of the API implementation.>> Alert w.r.t 'Response Times' is the only one which requires end-to-end request processing of API implementation in order to determine if the threshold is exceeded or not.

Create API Notebooks and Include them in the relevant Anypoint exchangeentries. >>API Notebooks are the one on Anypoint Platform that enable us to provide code-centric API documentationBottom of FormTop of Form

Data on past API invocations to help identify anomalies and usagepatterns across various APIs. API Invocation metrics provided by Anypoint Platform:>> Does NOT provide any Return Of Investment (ROI) related information. So the option suggesting it is OUT.>> Does NOT provide any information w.r.t how APIs are reused, whether there is effective usage of APIs or not etc...>> Does NOT prodive any prediction information as such to help us proactively identify any future policy violations.So, the kind of data/information we can get from such metrics is on past API invocations to help identify anomalies and usage patterns across various APIs.

The API policy is defined in API Manager for a specific APIinstance, and then ONLY applied to the specific API instance.. >> Once our API specifications are ready and published to Exchange, we need to visit API Manager and register an API instance for each API.>> API Manager is the place where management of API aspects takes place like addressing NFRs by enforcing policies on them.>> We can create multiple instances for a same API and manage them differently for different purposes.>> One instance can have a set of API policies applied and another instance of same API can have different set of policies applied for some other purpose.>> These APIs and their instances are defined PER environment basis. So, one need to manage them seperately in each environment.>> We can ensure that same configuration of API instances (SLAs, Policies etc..) gets promoted when promoting to higher environments using platform feature. But this is optional only. Still one can change them per environment basis if they have to.>> Runtime Manager is the place to manage API Implementations and their Mule Runtimes but NOT APIs itself. Though API policies gets executed in Mule Runtimes, We CANNOT enforce API policies in Runtime Manager. We would need to do that via API Manager only for a cherry picked instance in an environment.So, based on these facts, right statement in the given choices is - 'The API policy is defined in API Manager for a specific API instance, and then ONLY applied to the specific API instance'.

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.https://blogs.mulesoft.com/biz/connectivity/what-is-a-center-for-enablement-c4e/https://www.mulesoft.com/resources/api/secret-to-managing-it-projects

At the API proxy. >> API Policies can be enforced at two places in Mule platform.>> One - As an Embedded Policy enforcement in the same Mule Runtime where API implementation is running.>> Two - On an API Proxy sitting in front of the Mule Runtime where API implementation is running.>> As the deployment scenario in the question has API Proxy involved, the policies will be enforced at the API Proxy.

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..