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

Correct Answer: Use an SLA-based rate limiting policy and assign a client application to a matching SLA tier based on its type.

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

>> SLA tiers will come into play whenever any limits to be imposed on APIs based on client type

Scenario Analysis:

The API implementation is experiencing high CPU usage (over 90%) during bursts of requests, which correlates with slow response times, as indicated by a 99th percentile response time greater than 120 seconds.

The API implementation is running on Anypoint Runtime Fabric with two non-clustered replicas and has a reserved vCPU of 1.0 and a vCPU limit of 2.0.

The high CPU usage during bursts suggests that the current resources may not be sufficient to handle peak loads.

Evaluating the Options:

Option A (Correct Answer): Increasing the vCPU resources for each replica would provide more processing power to handle high traffic volumes, potentially reducing the response time during spikes. Since the CPU usage is consistently high during bursts, this option directly addresses the resource bottleneck.

Option B: Modifying the API client to split requests may reduce individual request load but could be complex to implement on the client side and may not fully address the high CPU issue.

Option C: Increasing the number of replicas could help distribute the load; however, with a high CPU load on each replica, adding more replicas without increasing CPU resources may not fully resolve the problem.

Option D: Throttling the client would reduce the number of requests, but this may not be acceptable if the client needs to maintain a high request rate. It also does not directly address the CPU limitations of the API implementation.

Conclusion:

Option A is the best choice as it addresses the root cause of high CPU usage by increasing the vCPU allocation, allowing the API to handle more requests efficiently. This should be pursued first before considering other options.

Refer to MuleSoft’s documentation on Runtime Fabric and vCPU resource allocation for more details on optimizing API performance in high-demand environments.

Explanation

Correct Answer: Unit tests (Whitebox)

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

For organizations with established CI/CD practices, the Mule Maven plugin is the recommended tool for automating packaging and deployment across multiple environments, including CloudHub, on-premise Mule runtimes, and Anypoint Runtime Fabric. Here’s why:

Automation with Maven:

The Mule Maven plugin allows for CI/CD integration by supporting automated build and deployment processes. It is commonly used in CI/CD pipelines to handle application packaging and deployment directly through Maven commands, making it ideal for teams that want consistent deployment automation across different MuleSoft environments.

Supported Deployment Targets:

The Mule Maven plugin supports deployment to various targets, including CloudHub, Runtime Fabric, and on-premises servers, thus meeting the needs of environments with diverse deployment destinations.

Why Option B is Correct:

The Mule Maven plugin is specifically designed for CI/CD pipelines and integrates with Jenkins, GitLab, and other CI/CD tools to facilitate continuous deployment. It is the most efficient MuleSoft-provided tool for this purpose.

Explanation of Incorrect Options:

Option A (Anypoint Runtime Manager) provides deployment management but does not automate CI/CD processes.

Option C (Anypoint Platform CLI) can script deployments but lacks direct integration with CI/CD tools.

Option D (Anypoint Platform REST APIs) requires custom scripting for deployment, which can be more complex than using the Mule Maven plugin.

ReferencesFor more details, refer to MuleSoft documentation on using the Mule Maven plugin for CI/CD​​.

Explanation

Correct Answer: 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

Explanation

Correct Answer: Spike control

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

>> First things first, HTTP Caching policy is for purposes different than avoiding the backend system from overloading. So this is OUT.

>> Rate Limiting and Throttling/ Spike Control policies are designed to limit API access, but have different intentions.

>> Rate limiting protects an API by applying a hard limit on its access.

>> Throttling/ Spike Control shapes API access by smoothing spikes in traffic.

That is why, Spike Control is the right option.

To monitor an application network and predict issues without custom scripts, policy violation metrics are critical. They provide insights into potential problems by tracking instances where API usage does not conform to defined policies. Here’s why this approach is suitable:

Predictive Monitoring:

Tracking API policy violations (such as rate limits or spike controls being hit) can indicate surges in traffic or misuse, which may lead to throttling or service degradation if not addressed.

By monitoring these violations, teams can proactively adjust limits or optimize API handling to prevent actual failures.

No Custom Scripting Needed:

Policy violation metrics are available within MuleSoft’s Anypoint Monitoring, meaning there’s no need to implement custom solutions or external tools to gather and interpret this data.

Explanation of Incorrect Options:

Option B (effectiveness based on reuse) does not directly predict failures.

Option C (past invocation counts) offers historical usage data but does not inherently identify issues.

Option D (ROI from API invocation) is a business metric and does not provide technical insights for failure prediction.

ReferencesFor more details on leveraging policy violation metrics for proactive monitoring, refer to MuleSoft documentation on Anypoint Monitoring​​.

Explanation

Correct Answer: 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.

Explanation

Correct Answer: Build several Bounded Context Data Models that align with coherent parts of the business processes and the definitions of associated business entities.

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

>> The options w.r.t building API data models using XML schema/ Agile API-centric practices are irrelevant to the scenario given in the question. So these two are INVALID.

>> Building EDM (Enterprise Data Model) is not feasible or right fit for this scenario as the teams and LOBs work in silo and they all have different initiatives, budget etc.. Building EDM needs intensive coordination among all the team which evidently seems not possible in this scenario.

So, the right fit for this scenario is to build several Bounded Context Data Models that align with coherent parts of the business processes and the definitions of associated business entities.