The MuleSoft Certified Platform Architect - Level 1 (MCPA-Level-1)

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.

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

Explanation

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

So, API invocations should be sent to port 8082 when calling this HTTPS based app.

References:

https://docs.mulesoft.com/runtime-manager/cloudhub-networking-guide

https://help.mulesoft.com/s/article/Configure-Cloudhub-Application-to-Send-a-HTTPS-Request-Directly-to-Another-Cloudhub-Application

https://help.mulesoft.com/s/question/0D52T00004mXXULSA4/multiple-http-listerners-on-cloudhub-one-with-port-9090

Explanation

Correct Answer: When there is one CloudHub deployment of the API implementation to three CloudHub workers that must share the cache state.

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

Key details in the scenario:

> > Use the CloudHub Object Store via the Object Store connector

Considering above details:

> > CloudHub Object Stores have one-to-one relationship with CloudHub Mule Applications.

> > We CANNOT use an application ' s CloudHub Object Store to be shared among multiple Mule applications running in different Regions or Business Groups or Customer-hosted Mule Runtimes by using Object Store connector.

> > If it is really necessary and very badly needed, then Anypoint Platform supports a way by allowing access to CloudHub Object Store of another application using Object Store REST API. But NOT using Object Store connector.

So, the only scenario where we can use the CloudHub Object Store via the Object Store connector to persist the cache’s state is when there is one CloudHub deployment of the API implementation to multiple CloudHub workers that must share the cache state.

Explanation

Correct Answer :  Workers are randomly distributed across available AZs within that region.

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

> >  Currently, we only have control to choose which AWS Region to choose but there is no control at all using any configurations or deployment options to decide what Availability Zone (AZ) to assign to what worker.

> >  There are  NO  fixed or implicit rules on platform too w.r.t assignment of AZ to workers based on environment or application.

> >  They are completely assigned in  random . However, cloudhub definitely ensures that HA is achieved by assigning the workers to more than on AZ so that all workers are not assigned to same AZ for same application.

Explanation

Correct Answer: The credentials provided by the IdP for identity management

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

Understanding the Need for Cross-API Monitoring :

The Center for Enablement (C4E) needs to investigate potential technical issues across multiple APIs in the application network that may be causing customers to abandon their carts.

This requires a solution that allows viewing metrics across several APIs in real-time to identify any performance issues or bottlenecks.

Evaluating Anypoint Platform Features :

Built-in Dashboards : Anypoint Platform provides built-in dashboards in Anypoint Monitoring, allowing teams to view metrics from multiple APIs in a single interface. This feature is designed to monitor API performance, latency, errors, and throughput, and is ideal for tracking performance across all layers of the application network.

Custom Dashboards : While custom dashboards allow for more tailored views, the built-in dashboards already aggregate metrics for multiple APIs, making it unnecessary to build a custom solution for this scenario.

Functional Monitoring : This feature is used to set up tests to monitor specific API functionality and uptime but is not suited for tracking metrics across multiple APIs in real-time.

API Manager : API Manager primarily focuses on managing API policies, contracts, and access control rather than providing detailed, real-time metrics across the entire application network.

Conclusion :

Option B (Built-in dashboards) is the best choice because it provides a comprehensive view of metrics from all APIs involved, enabling the C4E team to quickly identify any issues that may be contributing to abandoned shopping carts.

Refer to MuleSoft’s documentation on Anypoint Monitoring and built-in dashboards for more details on configuring and using these dashboards effectively.

Explanation

Correct Answer: A higher number of discoverable API-related assets in the application network.

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

> > We do NOT get faster response times in fine-grained approach when compared to coarse-grained approach.

> > In fact, we get faster response times from a network having coarse-grained APIs compared to a network having fine-grained APIs model. The reasons are below.

Fine-grained approach:

1. will have more APIs compared to coarse-grained

2. So, more orchestration needs to be done to achieve a functionality in business process.

3. Which means, lots of API calls to be made. So, more connections will needs to be established. So, obviously more hops, more network i/o, more number of integration points compared to coarse-grained approach where fewer APIs with bulk functionality embedded in them.

4. That is why, because of all these extra hops and added latencies, fine-grained approach will have bit more response times compared to coarse-grained.

5. Not only added latencies and connections, there will be more resources used up in fine-grained approach due to more number of APIs.

That ' s why, fine-grained APIs are good in a way to expose more number of resuable assets in your network and make them discoverable. However, needs more maintenance, taking care of integration points, connections, resources with a little compromise w.r.t network hops and response times.

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.

Understanding API Autodiscovery in MuleSoft :

API Autodiscovery links an API implementation in Anypoint Platform with its configuration in API Manager. This is controlled by the API ID which is set in the API Autodiscovery element in the Mule application.

The API ID remains consistent across minor updates to the API asset version in Exchange (e.g., from 2.0.0 to 2.0.1) as long as it is the same API.

Effect of Asset Version Update on API Autodiscovery :

When the asset version is updated (e.g., from 2.0.0 to 2.0.1), the API ID remains the same . Therefore, no changes are needed in the Autodiscovery configuration within the Mule application. The Autodiscovery will continue to link the API implementation to the latest version in API Manager.

Evaluating the Options :

Option A : Incorrect, as the API ID does not automatically change with minor asset version updates.

Option B : Incorrect, as the API ID remains the same, so no update is needed in the API implementation.

Option C (Correct Answer) : The API ID does not change , so no changes are necessary in the API implementation for the new asset version.

Option D : Incorrect, as there is no need to update the API implementation in the Autodiscovery global element for minor version changes.

Conclusion :

Option C is the correct answer, as the API ID remains unchanged with minor version updates, and no changes are needed in the API Autodiscovery configuration.

Refer to MuleSoft documentation on API Autodiscovery and version management for more details.