Practice Free MuleSoft Platform Architect I Exam Online Questions
Question #31
A Platform Architect inherits a legacy monolithic SOAP-based web service that performs a number of tasks, including showing all policies belonging to a client. The service connects to two back-end systems ― a life-insurance administration system and a general-insurance administration system ― and then queries for insurance policy information within each system, aggregates the results, and presents a SOAP-based response to a user interface (UI).
The architect wants to break up the monolithic web service to follow API-led conventions.
Which part of the service should be put into the process layer?
- A . Combining the insurance policy information from the administration systems
- B . Presenting the SOAP-based response to the UI
- C . Authenticating and maintaining connections to each of the back-end administration systems
- D . Querying the data from the administration systems
Correct Answer: A
A
Explanation:
In the API-led connectivity approach, each layer (System, Process, and Experience) has a distinct purpose:
System APIs: These APIs connect directly to backend systems to expose and unlock data in a standardized way.
Process APIs: These are responsible for orchestrating and processing data across different systems, combining information where needed.
Experience APIs: These are designed for specific user interfaces or applications, often transforming data formats to fit the needs of each consumer application.
Why Option A is Correct:
Process APIs are designed to combine data from multiple systems, which aligns with the function of aggregating policy information from both the life and general insurance systems. This aggregation logic would ideally reside in the Process layer, separating data retrieval from data orchestration. Moving this functionality to the Process layer enables reusability and modularity, as other Experience APIs or services could also leverage the combined policy data if needed. of Incorrect Options:
Option B (Presenting the SOAP-based response) would be managed by the Experience layer, as this layer adapts data formats for specific interfaces.
Option C (Authenticating and maintaining backend connections) would typically be handled within the System layer, where backend integration and security handling occurs.
Option D (Querying data) is the function of System APIs, which access the backend systems directly and expose the raw data without additional processing. Reference
For further details on API-led architecture and the roles of each layer, refer to MuleSoft’s documentation on API-led connectivity and API layers.
A
Explanation:
In the API-led connectivity approach, each layer (System, Process, and Experience) has a distinct purpose:
System APIs: These APIs connect directly to backend systems to expose and unlock data in a standardized way.
Process APIs: These are responsible for orchestrating and processing data across different systems, combining information where needed.
Experience APIs: These are designed for specific user interfaces or applications, often transforming data formats to fit the needs of each consumer application.
Why Option A is Correct:
Process APIs are designed to combine data from multiple systems, which aligns with the function of aggregating policy information from both the life and general insurance systems. This aggregation logic would ideally reside in the Process layer, separating data retrieval from data orchestration. Moving this functionality to the Process layer enables reusability and modularity, as other Experience APIs or services could also leverage the combined policy data if needed. of Incorrect Options:
Option B (Presenting the SOAP-based response) would be managed by the Experience layer, as this layer adapts data formats for specific interfaces.
Option C (Authenticating and maintaining backend connections) would typically be handled within the System layer, where backend integration and security handling occurs.
Option D (Querying data) is the function of System APIs, which access the backend systems directly and expose the raw data without additional processing. Reference
For further details on API-led architecture and the roles of each layer, refer to MuleSoft’s documentation on API-led connectivity and API layers.
Question #32
True or False. We should always make sure that the APIs being designed and developed are self-servable even if it needs more man-day effort and resources.
- A . FALSE
- B . TRUE
Correct Answer: B
B
Explanation:
Correct Answer TRUE
>> As per MuleSoft proposed IT Operating Model, designing APIs and making sure that they are discoverable and self-servable is VERY VERY IMPORTANT and decides the success of an API and its application network.
B
Explanation:
Correct Answer TRUE
>> As per MuleSoft proposed IT Operating Model, designing APIs and making sure that they are discoverable and self-servable is VERY VERY IMPORTANT and decides the success of an API and its application network.
Question #33
An organization is implementing a Quote of the Day API that caches today’s quote.
What scenario can use the GoudHub Object Store via the Object Store connector to persist the cache’s state?
- A . When there are three CloudHub deployments of the API implementation to three separate CloudHub regions that must share the cache state
- B . When there are two CloudHub deployments of the API implementation by two Anypoint Platform business groups to the same CloudHub region that must share the cache state
- C . When there is one deployment of the API implementation to CloudHub and anottV deployment to a customer-hosted Mule runtime that must share the cache state
- D . When there is one CloudHub deployment of the API implementation to three CloudHub workers that must share the cache state
Correct Answer: D
D
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.
D
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.
Question #34
A Platinum customer uses the U.S. control plane and deploys applications to CloudHub in Singapore with a default log configuration.
The compliance officer asks where the logs and monitoring data reside?
- A . Logs are held in:Singapore and monitoring data is held in the United States
- B . Logs and monitoring data are held in the United States
- C . Logs are held in the United States and monitoring data is held in Singapore
- D . Logs and monitoring data are held in Singapore
Correct Answer: B
B
Explanation:
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.
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. 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.
Reference
For details on data residency in CloudHub deployments, refer to MuleSoft’s documentation on CloudHub control planes and data handling policies.
B
Explanation:
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.
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. 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.
Reference
For details on data residency in CloudHub deployments, refer to MuleSoft’s documentation on CloudHub control planes and data handling policies.
Question #35
What best describes the Fully Qualified Domain Names (FQDNs), also known as DNS entries, created when a Mule application is deployed to the CloudHub Shared Worker Cloud?
- A . A fixed number of FQDNs are created, IRRESPECTIVE of the environment and VPC design
- B . The FQDNs are determined by the application name chosen, IRRESPECTIVE of the region
- C . The FQDNs are determined by the application name, but can be modified by an administrator after deployment
- D . The FQDNs are determined by both the application name and the Anypoint Platform organization
Correct Answer: B
B
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.
B
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.
Question #35
What best describes the Fully Qualified Domain Names (FQDNs), also known as DNS entries, created when a Mule application is deployed to the CloudHub Shared Worker Cloud?
- A . A fixed number of FQDNs are created, IRRESPECTIVE of the environment and VPC design
- B . The FQDNs are determined by the application name chosen, IRRESPECTIVE of the region
- C . The FQDNs are determined by the application name, but can be modified by an administrator after deployment
- D . The FQDNs are determined by both the application name and the Anypoint Platform organization
Correct Answer: B
B
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.
B
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.
Question #37
Central IT owns and focuses on System Layer APIs
Correct Answer: C
Explanation:
Correct Answer
Explanation:
Correct Answer
Question #38
An organization wants MuleSoft-hosted runtime plane features (such as HTTP load balancing, zero
downtime, and horizontal and vertical scaling) in its Azure environment.
What runtime plane minimizes the organization’s effort to achieve these features?
- A . Anypoint Runtime Fabric
- B . Anypoint Platform for Pivotal Cloud Foundry
- C . CloudHub
- D . A hybrid combination of customer-hosted and MuleSoft-hosted Mule runtimes
Correct Answer: A
A
Explanation:
Correct Answer Anypoint Runtime Fabric
>> When a customer is already having an Azure environment, It is not at all an ideal approach to go with hybrid model having some Mule Runtimes hosted on Azure and some on MuleSoft. This is unnecessary and useless.
>> CloudHub is a Mulesoft-hosted Runtime plane and is on AWS. We cannot customize to point CloudHub to customer’s Azure environment.
>> Anypoint Platform for Pivotal Cloud Foundry is specifically for infrastructure provided by Pivotal Cloud Foundry
>> Anypoint Runtime Fabric is right answer as it is a container service that automates the deployment and orchestration of Mule applications and API gateways. Runtime Fabric runs within a customer-managed infrastructure on AWS, Azure, virtual machines (VMs), and bare-metal servers. -Some of the capabilities of Anypoint Runtime Fabric include:
-Isolation between applications by running a separate Mule runtime per application. -Ability to run multiple versions of Mule runtime on the same set of resources. -Scaling applications across multiple replicas.
-Automated application fail-over.
-Application management with Anypoint Runtime Manager.
Reference: https://docs.mulesoft.com/runtime-fabric/1.7/
A
Explanation:
Correct Answer Anypoint Runtime Fabric
>> When a customer is already having an Azure environment, It is not at all an ideal approach to go with hybrid model having some Mule Runtimes hosted on Azure and some on MuleSoft. This is unnecessary and useless.
>> CloudHub is a Mulesoft-hosted Runtime plane and is on AWS. We cannot customize to point CloudHub to customer’s Azure environment.
>> Anypoint Platform for Pivotal Cloud Foundry is specifically for infrastructure provided by Pivotal Cloud Foundry
>> Anypoint Runtime Fabric is right answer as it is a container service that automates the deployment and orchestration of Mule applications and API gateways. Runtime Fabric runs within a customer-managed infrastructure on AWS, Azure, virtual machines (VMs), and bare-metal servers. -Some of the capabilities of Anypoint Runtime Fabric include:
-Isolation between applications by running a separate Mule runtime per application. -Ability to run multiple versions of Mule runtime on the same set of resources. -Scaling applications across multiple replicas.
-Automated application fail-over.
-Application management with Anypoint Runtime Manager.
Reference: https://docs.mulesoft.com/runtime-fabric/1.7/
Question #39
A team is planning to enhance an Experience API specification, and they are following API-led connectivity design principles.
What is their motivation for enhancing the API?
- A . The primary API consumer wants certain kinds of endpoints changed from the Center for Enablement standard to the consumer system standard
- B . The underlying System API is updated to provide more detailed data for several heavily used resources
- C . An IP Allowlist policy is being added to the API instances in the Development and Staging environments
- D . A Canonical Data Model is being adopted that impacts several types of data included in the API
Correct Answer: D
D
Explanation:
In API-led design, an Experience API is enhanced to improve how data is delivered to end-user applications. One primary reason to enhance an Experience API is when new data standards, such as a Canonical Data Model, are adopted.
Here’s why:
Canonical Data Model (CDM):
Adopting a CDM standardizes data representations across the organization, making APIs more consistent and easier to consume across various services and applications.
Updating the Experience API ensures that it delivers data in this standardized format, improving
interoperability and reusability.
of Correct Answer (D):
A CDM impacts the structure and types of data the API provides, and this update would be directly relevant to an Experience API, as it is the primary point of interaction for applications. of Incorrect Options:
Option A involves adapting to consumer-specific standards, which is against API-led design principles.
Option B involves changes in System APIs, which don’t directly mandate changes to the Experience API unless data formatting adjustments are required.
Option C (IP Allowlist) relates to security rather than API design and would not motivate a functional
enhancement of the API.
Reference
For more details on the use of Canonical Data Models in API-led architecture, refer to MuleSoft’s guidelines on data standardization and Experience API best practices.
D
Explanation:
In API-led design, an Experience API is enhanced to improve how data is delivered to end-user applications. One primary reason to enhance an Experience API is when new data standards, such as a Canonical Data Model, are adopted.
Here’s why:
Canonical Data Model (CDM):
Adopting a CDM standardizes data representations across the organization, making APIs more consistent and easier to consume across various services and applications.
Updating the Experience API ensures that it delivers data in this standardized format, improving
interoperability and reusability.
of Correct Answer (D):
A CDM impacts the structure and types of data the API provides, and this update would be directly relevant to an Experience API, as it is the primary point of interaction for applications. of Incorrect Options:
Option A involves adapting to consumer-specific standards, which is against API-led design principles.
Option B involves changes in System APIs, which don’t directly mandate changes to the Experience API unless data formatting adjustments are required.
Option C (IP Allowlist) relates to security rather than API design and would not motivate a functional
enhancement of the API.
Reference
For more details on the use of Canonical Data Models in API-led architecture, refer to MuleSoft’s guidelines on data standardization and Experience API best practices.
Question #40
Once an API Implementation is ready and the API is registered on API Manager, who should request the access to the API on Anypoint Exchange?
- A . None
- B . Both
- C . API Client
- D . API Consumer
Correct Answer: D
D
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
D
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