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

Explanation

Correct Answer: XML over HTTP

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

>> API-led connectivity and Application Networks urge to have the APIs on HTTP based protocols for building most effective APIs and networks on top of them.

>> The HTTP based APIs allow the platform to apply various varities of policies to address many NFRs

>> The HTTP based APIs also allow to implement many standard and effective implementation patterns that adhere to HTTP based w3c rules.

Bottom of Form

Top of Form

Monitoring On-Premise Mule Applications:

For Mule applications deployed on an on-premises cluster, monitoring detailed performance metrics requires communication with the MuleSoft-hosted control plane. The control plane, when used with on-premises runtimes, relies on Anypoint Monitoring and requires a Monitoring Agent to gather and send detailed performance metrics.

Setting Up Monitoring:

To enable detailed metrics, the Monitoring Agent must be installed on each node in the cluster where Mule applications are deployed. This agent collects data on memory usage, CPU load, response times, and other metrics, and sends it to the control plane for aggregation and visualization.

Evaluating the Options:

Option A: Updating settings in the control plane alone does not enable detailed monitoring; the agent must be installed on each node to capture detailed metrics.

Option B (Correct Answer): Installing the Monitoring Agent on each node ensures that each runtime node in the cluster can send its metrics to the control plane, enabling detailed monitoring.

Option C: Installing the agent on a separate server would not be effective, as each node in the cluster needs to independently report its metrics to ensure full visibility.

Option D: The on-prem runtime does not automatically send detailed metrics to the control plane without the Monitoring Agent installed.

Conclusion:

Option B is the correct answer, as installing the Monitoring Agent on each node is essential for detailed performance monitoring of on-prem applications in a cluster.

Refer to MuleSoft’s documentation on configuring Anypoint Monitoring for on-premises deployments and using the Monitoring Agent.

In scenarios where multiple API implementations are deployed across different environments (CloudHub and customer-hosted runtimes), Anypoint Functional Monitoring is the most effective tool to monitor API availability and trigger alerts when an API implementation becomes unresponsive. Here’s how it works:

Using Anypoint Functional Monitoring:

Functional Monitoring allows you to create monitors that periodically invoke specific endpoints on the API implementations, simulating a client request. This helps ensure that the API is responsive, even if no actual client requests are being made.

If an API implementation does not respond as expected, Functional Monitoring can generate alerts, notifying administrators of potential issues.

Why Option A is Correct:

By setting up Functional Monitoring to automatically invoke the API endpoints at regular intervals, you ensure continuous monitoring and alerting capabilities, which are especially useful for APIs that may experience periods of low or no traffic. This approach provides a proactive solution, allowing you to identify and address issues before actual users are impacted.

Explanation of Incorrect Options:

Option B suggests modifying client applications to trigger alerts, which is not a best practice as it shifts monitoring responsibility to clients, reducing control and consistency.

Option C involves handling exceptions within client applications, which does not address situations where no clients are making requests.

Option D proposes a Worker Not Responding alert in Runtime Manager, which is limited to worker-specific alerts and may not reliably monitor the API's actual responsiveness to requests.

ReferencesFor further information, refer to MuleSoft documentation on Anypoint Functional Monitoring setup and usage for API availability monitoring​.

Explanation

Correct Answer: When server-side load-balanced TLS mutual authentication is required between API implementations and API clients

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

Fact/ Memory Tip: Although there are many benefits of CloudHub Dedicated Load balancer, TWO important things that should come to ones mind for considering it are:

>> Having URL endpoints with Custom DNS names on CloudHub deployed apps

>> Configuring custom certificates for both HTTPS and Two-way (Mutual) authentication.

Coming to the options provided for this question:

>> We CANNOT use DLB to perform cross-region load balancing between separate deployments of the same Mule application.

>> We can have mapping rules to have more than one DLB URL pointing to same Mule app. But vicevera (More than one Mule app having same DLB URL) is NOT POSSIBLE

>> It is true that DLB helps to setup custom DNS names for Cloudhub deployed Mule apps but NOT true for apps deployed to Customer-hosted Mule Runtimes.

>> It is true to that we can load balance API invocations across multiple CloudHub workers using DLB but it is NOT A MUST. We can achieve the same (load balancing) using SLB (Shared Load Balancer) too. We DO NOT necessarily require DLB for achieve it.

So the only right option that fits the scenario and requires us to use DLB is when TLS mutual authentication is required between API implementations and API clients.

For applications deployed on CloudHub in a foreign region (e.g., Singapore), MuleSoft handles log and monitoring data in the region where the control plane resides. This data storage policy is standard for CloudHub deployments to maintain centralized log and monitoring data.

Data Location:

For a U.S.-based control plane, all logs and monitoring data are stored in the United States, regardless of the deployment region.

Although the application itself runs in Singapore, data related to application performance and logs is not localized to the deployment region.

Explanation of Correct Answer (B):

Since the control plane is based in the United States, all operational data like logs and monitoring will also be stored there, ensuring compliance with MuleSoft’s data handling policies.

Explanation of Incorrect Options:

Option A and D are incorrect because MuleSoft does not store logs or monitoring data in the application deployment region when the control plane is located in the United States.

Option C suggests mixed storage, which does not align with MuleSoft’s data policy structure.

ReferencesFor details on data residency in CloudHub deployments, refer to MuleSoft’s documentation on CloudHub control planes and data handling policies​.