Salesforce Certified MuleSoft Developer I Practice Test - Questions Answers

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.

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 LBSo, API invocations should be sent to port 8082 when calling this HTTPS based app.https://docs.mulesoft.com/runtime-manager/cloudhub-networking-guidehttps://help.mulesoft.com/s/article/Configure-Cloudhub-Application-to-Send-a-HTTPS-Request-Directly-to-Another-Cloudhub-Applicationhttps://help.mulesoft.com/s/question/0D52T00004mXXULSA4/multiple-http-listerners-on-cloudhub-one-with-port-9090

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

4.0.0. As per semver.org semantic versioning specification:Given a version number MAJOR.MINOR.PATCH, increment the:- MAJOR version when you make incompatible API changes.- MINOR version when you add functionality in a backwards compatible manner.- PATCH version when you make backwards compatible bug fixes.As per the scenario given in the question, the API implementation is completely changing its behavior. Although the format of the time is still being maintained as hh:mm:ss and there is no change in schema w.r.t format, the API will start functioning different after this change as the times are going to come completely different.Example: Before the change, say, time is going as 09:00:00 representing the PST. Now on, after the change, the same time will go as 18:00:00 as Central European Summer Time is 9 hours ahead of Pacific Time.>> This may lead to some uncertain behavior on API clients depending on how they are handling the times in the API response. All the API clients need to be informed that the API functionality is going to change and will return in CEST format. So, this considered as a MAJOR change and the version of API for this new change would be 4.0.0

Process Layer. >> Experience layer is dedicated for enrichment of end user experience. This layer is to meet the needs of different API clients/ consumers.>> System layer is dedicated to APIs which are modular in nature and implement/ expose various individual functionalities of backend systems>> Process layer is the place where simple or complex business orchestration logic is written by invoking one or many System layer modular APIsSo, Process Layer is the right answer.

Invoke the system API deployed to the primary environment; add timeout and retry logic to the process API to avoid intermittent failures; if it still fails, invoke the system API deployed to the DR environment. There is one important consideration to be noted in the question which is - System API in DR environment provides only 20% of the rate limiting offered by the primary environment. So, comparitively, very less calls will be allowed into the DR environment API opposed to its primary environment. With this in mind, lets analyse what is the right and best fault-tolerant invocation strategy.1. Invoking both the system APIs in parallel is definitely NOT a feasible approach because of the 20% limitation we have on DR environment. Calling in parallel every time would easily and quickly exhaust the rate limits on DR environment and may not give chance to genuine intermittent error scenarios to let in during the time of need.2. Another option given is suggesting to add timeout and retry logic to process API while invoking primary environment's system API. This is good so far. However, when all retries failed, the option is suggesting to invoke the copy of process API on DR environment which is not right or recommended. Only system API is the one to be considered for fallback and not the whole process API. Process APIs usually have lot of heavy orchestration calling many other APIs which we do not want to repeat again by calling DR's process API. So this option is NOT right.3. One more option given is suggesting to add the retry (no timeout) logic to process API to directly retry on DR environment's system API instead of retrying the primary environment system API first. This is not at all a proper fallback. A proper fallback should occur only after all retries are performed and exhausted on Primary environment first. But here, the option is suggesting to directly retry fallback API on first failure itself without trying main API. So, this option is NOT right too.This leaves us one option which is right and best fit.- Invoke the system API deployed to the primary environment- Add Timeout and Retry logic on it in process API- If it fails even after all retries, then invoke the system API deployed to the DR environment.

Bundle properties files for each environment into the Mule API implementation's deployable archive, then promote the Mule API implementation to the Production environment using Anypoint CLI or the Anypoint Platform REST APIs. >> Anypoint Exchange is for asset discovery and documentation. It has got no provision to modify the properties of Mule API implementations at all.>> API Manager is for managing API instances, their contracts, policies and SLAs. It has also got no provision to modify the properties of API implementations.>> API policies are to address Non-functional requirements of APIs and has again got no provision to modify the properties of API implementations.So, the right way and recommended way to do this as part of development practice is to bundle properties files for each environment into the Mule API implementation and just point and refer to respective file per environment.

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.

Manually provisioned customer-hosted runtime plane and customer-hosted control plane. There are two key factors that are to be taken into consideration from the scenario given in the question.>> Company requires both data and metadata to be resided within the corporate firewall>> Company would like to go with customer-hosted infrastructure.Any deployment model that is to deal with the cloud directly or indirectly (Mulesoft-hosted or Customer's own cloud like Azure, AWS) will have to share atleast the metadata.Application data can be controlled inside firewall by having Mule Runtimes on customer hosted runtime plane. But if we go with Mulsoft-hosted/ Cloud-based control plane, the control plane required atleast some minimum level of metadata to be sent outside the corporate firewall.As the customer requirement is pretty clear about the data and metadata both to be within the corporate firewall, even though customer wants to move to production as quickly as possible, unfortunately due to the nature of their security requirements, they have no other option but to go with manually provisioned customer-hosted runtime plane and customer-hosted control plane.