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

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.

References:

https://docs.mulesoft.com/api-manager/2.x/api-auto-discovery-new-concept

https://docs.mulesoft.com/api-manager/1.x/api-auto-discovery

https://docs.mulesoft.com/api-manager/2.x/api-auto-discovery-new-conc ept

Understanding Control and Runtime Planes:

Control Plane: The control plane is responsible for managing, monitoring, and deploying Mule applications. In a Private Cloud Edition (PCE), this control plane is deployed on-premises within the customer’s infrastructure, meeting data residency and security requirements.

Runtime Plane: The runtime plane consists of Mule runtimes that execute Mule applications. By hosting these runtimes within the customer’s infrastructure, data and metadata can remain local, which complies with corporate policies regarding data residency.

Evaluating the Options:

Option A: Using Anypoint Platform Private Cloud Edition for the control plane and the MuleSoft-hosted runtime plane would not meet the requirement, as the runtime plane is hosted by MuleSoft and would not keep data local.

Option B: The MuleSoft-hosted control plane with Anypoint Runtime Fabric for the runtime plane would still mean that metadata is managed in MuleSoft’s cloud, which does not comply with the requirement to keep data and metadata on-premises.

Option C: A MuleSoft-hosted control plane and customer-hosted Mule runtimes also mean that metadata resides in the cloud, not on-premises, failing the residency requirement.

Option D (Correct Answer): Anypoint Platform Private Cloud Edition (PCE) for the control plane and customer-hosted Mule runtimes fulfill both requirements, as both the control plane and runtime plane would be hosted within the customer’s data center.

Conclusion:

Option D is the correct answer, as it ensures that both the control plane and runtime plane are hosted on-premises, allowing data and metadata to reside locally per the corporate IT policy.

Refer to MuleSoft's documentation on Private Cloud Edition deployment and on-premise runtime configurations for further details.

Explanation

Correct Answer: Manually provisioned customer-hosted runtime plane and customer-hosted control plane

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

There are two key factors that are to be taken into consideration from the scenario given in the question.

>> Company requires both data and metadata to be resided within the corporate firewall

>> Company would like to go with customer-hosted infrastructure.

Any deployment model that is to deal with the cloud directly or indirectly (Mulesoft-hosted or Customer's own cloud like Azure, AWS) will have to share atleast the metadata.

Application data can be controlled inside firewall by having Mule Runtimes on customer hosted runtime plane. But if we go with Mulsoft-hosted/ Cloud-based control plane, the control plane required atleast some minimum level of metadata to be sent outside the corporate firewall.

As the customer requirement is pretty clear about the data and metadata both to be within the corporate firewall, even though customer wants to move to production as quickly as possible, unfortunately due to the nature of their security requirements, they have no other option but to go with manually provisioned customer-hosted runtime plane and customer-hosted control plane.

Explanation

Correct Answer:

1. App Developers owns and focuses on Experience Layer APIs

2. LOB IT owns and focuses on Process Layer APIs

3. Central IT owns and focuses on System Layer APIs

References:

https://blogs.mulesoft.com/biz/api/experience-api-ownership/

https://blogs.mulesoft.com/biz/api/process-api-ownership/

https://blogs.mulesoft.com/biz/api/system-api-ownership/

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.

Center for Enablement (C4E) KPIs:

A Center for Enablement (C4E) in MuleSoft focuses on enabling self-service and reuse by providing APIs that can be consumed across the organization. A key metric of success is how many consumers are utilizing the published APIs.

The number of consumers who have requested and received access to an API indicates the level of adoption and reuse, which aligns with the goals of a C4E.

Evaluating the Options:

Option A: This metric could indicate deployment automation, but it is not a direct measure of C4E’s success in enabling API reuse and consumption.

Option B: Bandwidth usage per API implementation provides insight into API traffic but does not measure C4E enablement or consumer engagement.

Option C: The number of developers downloading an API specification can be an indicator of interest but does not confirm actual usage or enablement.

Option D (Correct Answer): The number of consumers who have requested and received access to an API in production is a key metric indicating API adoption and reuse, which aligns with C4E’s goals.

Conclusion:

Option D is the correct answer as it provides a direct measure of consumer engagement and adoption, indicating the success of the C4E in promoting API usage across the organization.

Refer to MuleSoft’s documentation on C4E KPIs and API usage metrics for additional insights.

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: The test runs immediately after the Mule application has been compiled and packaged

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

>> Integration tests are the last layer of tests we need to add to be fully covered.

>> These tests actually run against Mule running with your full configuration in place and are tested from external source as they work in PROD.

>> These tests exercise the application as a whole with actual transports enabled. So, external systems are affected when these tests run.

So, these tests do NOT run immediately after the Mule application has been compiled and packaged.

FYI... Unit Tests are the one that run immediately after the Mule application has been compiled and packaged.

For a European company with requirements such as zero-downtime redeployment, deployment to multiple runtime versions, secure and fast performance, and the use of Anypoint MQ without additional network configuration, CloudHub is the best choice for the following reasons:

Zero-Downtime Redeployment: CloudHub supports zero-downtime deployment, which allows seamless redeployment of applications without impacting availability.

Support for Multiple Runtime Versions: CloudHub allows deploying applications across different Mule runtime versions, giving flexibility to test and migrate applications as needed.

Integrated Anypoint MQ: Anypoint MQ, which is fully integrated with CloudHub, provides reliable messaging across applications. Choosing CloudHub removes the need for additional network configurations, as Anypoint MQ can be directly accessed in this hosted environment.

Security and Performance: CloudHub offers secure networking, automatic scaling, and optimized performance without requiring a complex setup. This is managed by MuleSoft’s infrastructure, meeting the speed and security requirements with minimal overhead.

Explanation of Incorrect Options:

Option A and D (Runtime Fabric on VMs or Self-Managed Kubernetes): While Runtime Fabric offers flexibility, it requires more complex network and infrastructure configurations, which is not ideal if the company seeks simplicity.

Option B (Customer-hosted): This would require additional network and security configuration, which does not align with the requirement of minimizing setup complexity.

ReferencesFor more information on CloudHub’s capabilities regarding zero-downtime deployments and integration with Anypoint MQ, refer to MuleSoft documentation on CloudHub​​.