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

For an organization starting with API-led connectivity to integrate a siloed back-end system with a new CRM, the following approach aligns with best practices and MuleSoft’s Center for Enablement (C4E) guidance:

API-led Connectivity: This model organizes APIs into distinct layers (System, Process, and Experience) to improve reusability, modularity, and manageability.

System APIs are used to expose and unlock data from core systems (such as back-end applications or databases).

Process APIs orchestrate data across multiple systems and transform it as needed.

Experience APIs format the data specifically for consumption by applications or devices, such as the CRM in this case.

Step to Support Application Network:

Create a System API for the back-end system. This API should expose the necessary data to support integration with the CRM.

By creating a System API with a RESTful interface, data can be accessed in a standardized way, making it easier to integrate with other systems and supporting future scalability.

Why Option D is Correct:

Creating a System API aligns with the principle of API-led connectivity, ensuring that data is exposed in a reusable manner. This API can then be orchestrated by Process APIs as needed to meet CRM requirements and can easily be extended to other applications.

Explanation of Incorrect Options:

Option A (creating a business process model) does not directly enable connectivity or expose back-end data through APIs.

Option B is unnecessary at this stage; assessing CRM capabilities like OAuth 2.0 support is not directly related to creating the application network via System APIs.

Option C contradicts API-led best practices by suggesting a point-to-point integration, which API-led connectivity seeks to avoid due to its lack of flexibility and scalability.

ReferencesRefer to MuleSoft’s API-led Connectivity resources for a detailed framework on building scalable integration layers using System, Process, and Experience APIs​​.

Explanation

Correct Answer: The CloudHub shared load balancer

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

The scenario in this question can be split as below:

>> There are 3 CloudHub workers (So, there are already good number of workers to handle high volume of requests)

>> The workers are not using static IP addresses (So, one CANNOT use customer load-balancing solutions without static IPs)

>> Looking for most cost-effective component to load balance the client requests among the workers.

Based on the above details given in the scenario:

>> Runtime autoscaling is NOT at all cost-effective as it incurs extra cost. Most over, there are already 3 workers running which is a good number.

>> We cannot go for a customer-hosted load balancer as it is also NOT most cost-effective (needs custom load balancer to maintain and licensing) and same time the Mule App is not having Static IP Addresses which limits from going with custom load balancing.

>> An API Proxy is irrelevant there as it has no role to play w.r.t handling high volumes or load balancing.

So, the only right option to go with and fits the purpose of scenario being most cost-effective is - using a CloudHub Shared Load Balancer.

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

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: GET, OPTIONS, HEAD

http://restcookbook.com/HTTP%20Methods/idempotency/

Explanation

Correct Answer: IP whitelist

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

>> OAuth 2.0 access token and Client ID enforcement policies are VERY common to apply on Experience APIs as API consumers need to register and access the APIs using one of these mechanisms

>> JSON threat protection is also VERY common policy to apply on Experience APIs to prevent bad or suspicious payloads hitting the API implementations.

>> IP whitelisting policy is usually very common in Process and System APIs to only whitelist the IP range inside the local VPC. But also applied occassionally on some experience APIs where the End User/ API Consumers are FIXED.

>> When we know the API consumers upfront who are going to access certain Experience APIs, then we can request for static IPs from such consumers and whitelist them to prevent anyone else hitting the API.

However, the experience API given in the question/ scenario is intended to work with a consumer mobile phone or tablet application. Which means, there is no way we can know all possible IPs that are to be whitelisted as mobile phones and tablets can so many in number and any device in the city/state/country/globe.

So, It is very LEAST LIKELY to apply IP Whitelisting on such Experience APIs whose consumers are typically Mobile Phones or Tablets.

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.

Explanation

Correct Answer: An SLA for the upstream API CANNOT be provided.

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

>> First thing first, the default HTTP response timeout for HTTP connector is 10000 ms (10 seconds). NOT 500 ms.

>> Mule runtime does NOT apply any such "load-dependent" timeouts. There is no such behavior currently in Mule.

>> As there is default 10000 ms time out for HTTP connector, we CANNOT always guarantee that the invocation of the downstream API will run to completion without timing out due to its unreliable SLA times. If the response time crosses 10 seconds then the request may time out.

The main impact due to this is that a proper SLA for the upstream API CANNOT be provided.

Explanation

Correct Answer: API implementations can run successfully in customer-hosted Mule runtimes, 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 using Runtime 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.