The Salesforce Certified MuleSoft Platform Architect (Mule-Arch-201) (MuleSoft-Platform-Architect-I)

Explanation

Correct Answer: The FQDNs are determined by the application name chosen, IRRESPECTIVE of the region

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

> > When deploying applications to Shared Worker Cloud, the FQDN are always determined by application name chosen.

> > It does NOT matter what region the app is being deployed to.

> > Although it is fact and true that the generated FQDN will have the region included in it (Ex: exp-salesorder-api.au-s1.cloudhub.io), it does NOT mean that the same name can be used when deploying to another CloudHub region.

> > Application name should be universally unique irrespective of Region and Organization and solely determines the FQDN for Shared Load Balancers.

Correct Answer: Persistent Object Store

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

> > Redis distributed cache is performant but NOT out-of-the-box solution in Anypoint Platform

> > File-storage is neither performant nor out-of-the-box solution in Anypoint Platform

> > java.util.WeakHashMap needs a completely custom implementation of cache from scratch using Java code and is limited to the JVM where it is running. Which means the state in the cache is not worker aware when running on multiple workers. This type of cache is local to the worker. So, this is neither out-of-the-box nor worker-aware among multiple workers on cloudhub. https://www.baeldung.com/java-weakhashmap

> > Persistent Object Store is an out-of-the-box solution provided by Anypoint Platform which is performant as well as worker aware among multiple workers running on CloudHub. https://docs.mulesoft.com/object-store/

So, Persistent Object Store is the right answer.

Explanation

Correct Answer: It makes API Manager aware of API implementations and hence enables it to enforce policies.

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

> > API Autodiscovery is a mechanism that manages an API from API Manager by pairing the deployed application to an API created on the platform.

> > API Management includes tracking, enforcing policies if you apply any, and reporting API analytics.

> > Critical to the Autodiscovery process is identifying the API by providing the API name and version.

Explanation

Correct Answer: Create separate Anypoint VPCs for non-production and production environments, then configure connections to the backend systems in the corresponding customer-hosted environments.

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

> >  Creating different Business Groups does NOT make any difference w.r.t accessing the non-prod and prod customer-hosted environments. Still they will be accessing from both Business Groups unless process network restrictions are put in place.

> >  We need to modify or couple the Mule Application Implementations with the environment. In fact, we should never implements application coupled with environments by binding them in the properties. Only basic things like endpoint URL etc should be bundled in properties but not environment level access restrictions.

> >  IP addresses on CloudHub are dynamic until unless a special static addresses are assigned. So it is not possible to setup firewall rules in customer-hosted infrastrcture. More over, even if static IP addresses are assigned, there could be 100s of applications running on cloudhub and setting up rules for all of them would be a hectic task, non-maintainable and definitely got a good practice.

> >  The best practice recommended by Mulesoft (In fact any cloud provider), is to have your Anypoint VPCs seperated for Prod and Non-Prod and perform the VPC peering or VPN tunneling for these Anypoint VPCs to respective Prod and Non-Prod customer-hosted environment networks.

 https://docs.mulesoft.com/runtime-manager/virtual-private-cloud

Bottom of Form

Top of Form

To create a unified schema in MuleSoft ' s DataGraph, APIs must be exposed in a way that allows DataGraph to pull and consolidate data from these APIs into a single schema accessible to consumers. DataGraph provides a federated approach, combining multiple APIs to form a single, unified API endpoint.

In this setup:

APIs 1, 2, 3, and 4 are suitable candidates for DataGraph because they are hosted within the Customer VPC on CloudHub and are accessible either through a Shared Load Balancer (LB) or a Dedicated Load Balancer (DLB). Both of these load balancers provide public access, which is a necessary condition for DataGraph as it must access the APIs to aggregate data.

APIs 5 and 6 are hosted on Customer Hosted Server 2, which is explicitly marked as " Not public " . Since DataGraph requires API access through a publicly reachable endpoint to aggregate them into a unified schema, APIs 5 and 6 cannot be used with DataGraph in this configuration.

APIs 3 and 4 on Customer Hosted Server 1 appear accessible through a Shared LB, implying public accessibility that meets DataGraph’s requirements.

By combining APIs 1, 2, 3, and 4 within DataGraph, you can create a unified schema that enables clients to query data seamlessly from all these APIs as if it were from a single source.

This setup allows for efficient data retrieval and can simplify API consumption by reducing the need to call multiple APIs individually, thus optimizing performance and developer experience.

ReferencesFor more detailed information on setting up and managing unified schemas in DataGraph, refer to the DataWeave documentation and MuleSoft DataGraph resources which provide in-depth guidelines on schema aggregation and API federation​​.

Explanation

Correct Answer: API Consumer

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

> > API clients are piece of code or programs that use the client credentials of API consumer but does not directly interact with Anypoint Exchange to get the access

> > API consumer is the one who should get registered and request access to API and then API client needs to use those client credentials to hit the APIs

So, API consumer is the one who needs to request access on the API from Anypoint Exchange

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

Explanation

Correct Answer: Traffic between Mule applications deployed to an Anypoint VPC and on-premises systems can stay within a private network

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

> > The private IP address range of an Anypoint VPC is NOT automatically chosen by CloudHub. It is chosen by us at the time of creating VPC using thr CIDR blocks.

CIDR Block: The size of the Anypoint VPC in Classless Inter-Domain Routing (CIDR) notation.

For example, if you set it to 10.111.0.0/24, the Anypoint VPC is granted 256 IP addresses from 10.111.0.0 to 10.111.0.255.

Ideally, the CIDR Blocks you choose for the Anypoint VPC come from a private IP space, and should not overlap with any other Anypoint VPC’s CIDR Blocks, or any CIDR Blocks in use in your corporate network.

that each CloudHub environment requires a separate Anypoint VPC. Once an Anypoint VPC is created, we can choose a same VPC by multiple environments. However, it is generally a best and recommended practice to always have seperate Anypoint VPCs for Non-Prod and Prod environments.

> > We use Anypoint VPN to link the underlying AWS VPC to an on-premises (non AWS) private network. NOT VPC Peering.

Explanation

Correct Answer: Implement required changes to the Process API implementation so that, whenever possible, the Process API’s RAML definition remains unchanged.

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

Key requirement in the question is:

> > Approach that minimizes the impact of this change on API clients

Based on above:

> > Updating the RAML definition would possibly impact the API clients if the changes require any thing mandatory from client side. So, one should try to avoid doing that until really necessary.

> > Implementing the changes as a completely different API and then redirectly the clients with 3xx status code is really upsetting design and heavily impacts the API clients.

> > Organisations and IT cannot simply postpone the changes required until all API consumers acknowledge they are ready to migrate to a new Process API or API version. This is unrealistic and not possible.

The best way to handle the changes always is to implement required changes to the API implementations so that, whenever possible, the API’s RAML definition remains unchanged.