Free Practice Questions for Salesforce MuleSoft-Platform-Architect-I Exam

Explanation

Correct Answer: Apply a JSON threat protection policy to all APIs to detect potential threat vectors

*****************************************

>> Usually, if the APIs are designed and developed for specific consumers (known consumers/customers) then we would IP Whitelist the same to ensure that traffic only comes from them.

>> However, as this scenario states that the APIs are publicly available and being used by so many mobile and web applications, it is NOT possible to identify and blacklist all possible bad actors.

>> So, JSON threat protection policy is the best chance to prevent any bad JSON payloads from such bad actors.

Explanation

Correct Answer: In parallel, invoke the system API deployed to the primary environment and the system API deployed to the DR environment, and ONLY use the first response.

*****************************************

>> The API requirement in the given scenario is to respond in least possible time.

>> The option that is suggesting to first try the API in primary environment and then fallback to API in DR environment would result in successful response but NOT in least possible time. So, this is NOT a right choice of implementation for given requirement.

>> Another option that is suggesting to ONLY invoke API in primary environment and to add timeout and retries may also result in successful response upon retries but NOT in least possible time. So, this is also NOT a right choice of implementation for given requirement.

>> One more option that is suggesting to invoke API in primary environment and API in DR environment in parallel using Scatter-Gather would result in wrong API response as it would return merged results and moreover, Scatter-Gather does things in parallel which is true but still completes its scope only on finishing all routes inside it. So again, NOT a right choice of implementation for given requirement

The Correct choice is to invoke the API in primary environment and the API in DR environment parallelly, and using ONLY the first response received from one of them.

Explanation

Correct Answer: System Layer

The APIs used in an API-led approach to connectivity fall into three categories:

System APIs – these usually access the core systems of record and provide a means of insulating the user from the complexity or any changes to the underlying systems. Once built, many users, can access data without any need to learn the underlying systems and can reuse these APIs in multiple projects.

Process APIs – These APIs interact with and shape data within a single system or across systems (breaking down data silos) and are created here without a dependence on the source systems from which that data originates, as well as the target channels through which that data is delivered.

Experience APIs – Experience APIs are the means by which data can be reconfigured so that it is most easily consumed by its intended audience, all from a common data source, rather than setting up separate point-to-point integrations for each channel. An Experience API is usually created with API-first design principles where the API is designed for the specific user experience in mind.

Explanation

Correct Answer: Implement different system APIs named createCustomer, amendCustomer, retrieveCustomer and suspendCustomer as they are modular and has seperation of concerns

*****************************************

>> It is quite normal to have a single API and different Verb + Resource combinations. However, this fits well for an Experience API or a Process API but not a best architecture style for System APIs. So, option with just one customerManagement API is not the best choice here.

>> The option with APIs in createCustomerInCRMZ format is next close choice w.r.t modularization and less maintenance but the naming of APIs is directly coupled with the legacy system. A better foreseen approach would be to name your APIs by abstracting the backend system names as it allows seamless replacement/migration of any backend system anytime. So, this is not the correct choice too.

>> createCustomer, amendCustomer, retrieveCustomer and suspendCustomer is the right approach and is the best fit compared to other options as they are both modular and same time got the names decoupled from backend system and it has covered all requirements a System API needs.

MuleSoft offers various tools to automate the deployment of Mule applications, which can streamline deployment and management processes. Here’s how each tool supports automated deployment:

Runtime Manager:

Anypoint Runtime Manager is MuleSoft’s web-based interface that allows users to deploy, manage, and monitor applications directly. It provides deployment automation through its user-friendly interface.

Anypoint Platform CLI:

The Anypoint CLI enables scripting of deployment and management tasks, making it possible to automate deployments via command-line scripts. This tool is ideal for CI/CD pipelines as it integrates with automated processes.

Platform APIs:

MuleSoft’s Platform APIs allow programmatic access to deployment functions, enabling integration with external automation tools and CI/CD systems. These APIs facilitate deployment through RESTful calls, which can be automated for continuous delivery.

Explanation of Incorrect Options:

Option D (Anypoint Studio) is primarily for development and does not support deployment automation.

Option E (Maven Plugin) can be used for building and deploying Mule applications but isn’t classified as a platform tool for deployment.

Option F (API Community Manager) is unrelated to deployment and instead focuses on managing API communities.

ReferencesFor detailed steps on automating deployments with these tools, refer to MuleSoft documentation on Runtime Manager, CLI, and Platform APIs​.

When an API implementation is deployed on CloudHub without configuring automatic restarts in case of worker non-responsiveness, MuleSoft’s monitoring and alerting behavior is as follows:

API Invocation Alerts:

If no clients are invoking the API, there will be no invocation alerts triggered, as alerts related to invocations depend on actual client requests.

Implementation-Level Alerts:

Even without invocation, CloudHub can still monitor the state of the API implementation. If the worker becomes unresponsive, an alert related to the API implementation's health or availability could still be raised.

Why Option C is Correct:

This option correctly identifies that no invocation-related alerts would be triggered in the absence of client requests, while implementation-level alerts could still be generated based on the worker's state.

ReferencesFor additional information, check MuleSoft documentation on CloudHub monitoring and alert configurations to understand worker status alerts versus invocation alerts​.

Role of Process API in API-led Connectivity:

In MuleSoft’s API-led connectivity approach, a Process API is used to coordinate, aggregate, and orchestrate data from various System APIs. It is primarily responsible for implementing business logic that spans multiple backend systems or entities, transforming and combining data as needed to support business processes.

Process APIs are not directly exposed to end-user clients; rather, they work between System APIs and Experience APIs, providing business logic and orchestration capabilities.

Evaluating the Options:

Option A: Process APIs are not typically responsible for large data dumps or data synchronization. That function would be handled by a System API or a specialized batch process.

Option B: Managing direct, secure communication between back-end systems and end-user clients is typically the role of Experience APIs rather than Process APIs.

Option C (Correct Answer): Process APIs are designed to coordinate and orchestrate calls to multiple other APIs in the network, which supports the automation of business processes.

Option D: Securing and managing communication with end-user clients is typically the role of Experience APIs, not Process APIs.

Conclusion:

Option C is the correct answer, as the main role of a Process API is to coordinate and orchestrate interactions between other APIs, enabling business processes to function seamlessly across multiple systems.

Refer to MuleSoft's API-led connectivity documentation for further explanation of the roles and responsibilities of Process APIs in an application network.

Understanding Circuit Breaker Policy:

A circuit breaker is a design pattern used to detect failures and prevent an application from continually trying to execute a failing operation. In this case, it will help improve response time and reduce demand on the downstream API.

The specified configuration includes conditions for opening, half-opening, and closing the circuit based on error rates over time:

Circuit Open: Triggered if there are more than 10 errors per minute for three consecutive minutes.

Circuit Half-Open: The circuit transitions to half-open if there is one error per minute.

Circuit Closed: The circuit closes if the error rate is less than one error per minute for five minutes.

Evaluating the Options:

Option A: Creating a custom policy with template expressions could work, but it would require custom development. Since the Anypoint Platform already has a Circuit Breaker policy available, this would be a less efficient and more complex solution.

Option B: Anypoint Monitoring alerts can be used for monitoring the API, but they do not provide circuit-breaking functionality. Additionally, implementing a retry strategy for the half-open state is not sufficient to achieve the required circuit breaker behavior.

Option C (Correct Answer): Adding the Circuit Breaker policy to the API instance on Anypoint Platform allows you to set up circuit-breaking conditions directly. This approach uses the built-in Circuit Breaker policy, where you can configure parameters such as error thresholds and time intervals to match the requirements. This solution is efficient, reliable, and leverages Anypoint’s out-of-the-box capabilities.

Option D: Implementing the strategy within a Mule application with a YAML configuration could be complex and less manageable. Additionally, it does not leverage Anypoint Platform’s built-in Circuit Breaker policy, which is more suited to this scenario.

Conclusion:

Option C is the correct choice, as it leverages Anypoint Platform’s Circuit Breaker policy. This solution allows for configuring thresholds and time intervals as specified, improving response time and reducing demand on the downstream API while utilizing Anypoint's managed policy feature.

Refer to MuleSoft’s documentation on implementing the Circuit Breaker policy in API Manager for detailed configuration guidance.

Explanation

Correct Answer: Create a bounded-context model for the system layer to closely match the backend data model, and add an anti-corruption layer to let the different bounded contexts cooperate across the system and process layers

*****************************************

>> Canonical models are not an option here as the organization has already put in efforts and created bounded-context models for Experience and Process APIs.

>> Anti-corruption layers for ALL APIs is unnecessary and invalid because it is mentioned that experience and process APIs share same bounded-context model. It is just the System layer APIs that need to choose their approach now.

>> So, having an anti-corruption layer just between the process and system layers will work well. Also to speed up the approach, system APIs can mimic the backend system data model.