Cisco
CompTIA
ISC
EC-Council
EXIN
Fortinet
ITIL
Juniper
Microsoft
VMware
Avaya
SAP
Google
NVIDIA
Salesforce
Amazon
Palo Alto Networks
ISC2
Splunk
ServiceNow
All Vendors
  2. Home
  3. Exams
  4. Salesforce
  5. MuleSoft-Platform-Architect-I

Salesforce MuleSoft-Platform-Architect-I Exam Questions
Salesforce Certified MuleSoft Platform Architect I (Page 3 )

Updated On: 28-Feb-2026
Page 3 of 20
PDF with 152 Questions

What is true about the technology architecture of Anypoint VPCs?

  1. The private IP address range of an Anypoint VPC is automatically chosen by CloudHub
  2. Traffic between Mule applications deployed to an Anypoint VPC and on-premises systems can stay within a private network
  3. Each CloudHub environment requires a separate Anypoint VPC
  4. VPC peering can be used to link the underlying AWS VPC to an on-premises (non AWS) private network

Answer(s): B

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.


Reference:

https://docs.mulesoft.com/runtime-manager/vpn-about
Only true statement in the given choices is that the traffic between Mule applications deployed to an Anypoint VPC and on-premises systems can stay within a private network. https://docs.mulesoft.com/runtime-manager/vpc-connectivity-methods-concept



An API implementation is deployed on a single worker on CloudHub and invoked by external API clients (outside of CloudHub). How can an alert be set up that is guaranteed to trigger AS SOON AS that API implementation stops responding to API invocations?

  1. Implement a heartbeat/health check within the API and invoke it from outside the Anypoint Platform and alert when the heartbeat does not respond
  2. Configure a "worker not responding" alert in Anypoint Runtime Manager
  3. Handle API invocation exceptions within the calling API client and raise an alert from that API client when the API Is unavailable
  4. Create an alert for when the API receives no requests within a specified time period

Answer(s): B

Explanation:

Correct Answer: Configure a “Worker not responding” alert in Anypoint Runtime Manager.
*****************************************
>> All the options eventually helps to generate the alert required when the application stops responding.
>> However, handling exceptions within calling API and then raising alert from API client is inappropriate and silly. There could be many API clients invoking the API implementation and it is not ideal to have this setup consistently in all of them. Not a realistic way to do.
>> Implementing a health check/ heartbeat with in the API and calling from outside to detmine the health sounds OK but needs extra setup for it and same time there are very good chances of generating false alarms when there are any intermittent network issues between external tool calling the health check API on API implementation. The API implementation itself may not have any issues but due to some other factors some false alarms may go out.
>> Creating an alert in API Manager when the API receives no requests within a specified time period would actually generate realistic alerts but even here some false alarms may go out when there are genuinely no requests from API clients.
The best and right way to achieve this requirement is to setup an alert on Runtime Manager with a condition "Worker not responding". This would generate an alert AS SOON AS the workers become unresponsive.



The implementation of a Process API must change.
What is a valid approach that minimizes the impact of this change on API clients?

  1. Update the RAML definition of the current Process API and notify API client developers by sending them links to the updated RAML definition
  2. Postpone changes until API consumers acknowledge they are ready to migrate to a new Process API or API version
  3. Implement required changes to the Process API implementation so that whenever possible, the Process API's RAML definition remains unchanged
  4. Implement the Process API changes in a new API implementation, and have the old API implementation return an HTTP status code 301 - Moved Permanently to inform API clients they should be calling the new API implementation

Answer(s): C

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.



Refer to the exhibit.

An organization needs to enable access to their customer data from both a mobile app and a web application, which each need access to common fields as well as certain unique fields.
The data is available partially in a database and partially in a 3rd-party CRM system. What APIs should be created to best fit these design requirements?

A) A Process API that contains the data required by both the web and mobile apps, allowing these applications to invoke it directly and access the data they need thereby providing the flexibility to add more fields in the future without needing API changes

B) One set of APIs (Experience API, Process API, and System API) for the web app, and another set for the mobile app

C) Separate Experience APIs for the mobile and web app, but a common Process API that invokes separate System APIs created for the database and CRM system

D) A common Experience API used by both the web and mobile apps, but separate Process APIs for the web and mobile apps that interact with the database and the CRM System

  1. Option A
  2. Option B
  3. Option C
  4. Option D

Answer(s): C

Explanation:

Correct Answer: Separate Experience APIs for the mobile and web app, but a common Process API that invokes separate System APIs created for the database and CRM system
***************************************** As per MuleSoft's API-led connectivity:
>> Experience APIs should be built as per each consumer needs and their experience.
>> Process APIs should contain all the orchestration logic to achieve the business functionality.
>> System APIs should be built for each backend system to unlock their data.


Reference:

https://blogs.mulesoft.com/dev/api-dev/what-is-api-led-connectivity/



Refer to the exhibit.

A developer is building a client application to invoke an API deployed to the STAGING environment that is governed by a client ID enforcement policy.
What is required to successfully invoke the API?

  1. The client ID and secret for the Anypoint Platform account owning the API in the STAGING environment
  2. The client ID and secret for the Anypoint Platform account's STAGING environment
  3. The client ID and secret obtained from Anypoint Exchange for the API instance in the STAGING environment
  4. A valid OAuth token obtained from Anypoint Platform and its associated client ID and secret

Answer(s): C

Explanation:

Correct Answer: The client ID and secret obtained from Anypoint Exchange for the API instance in the STAGING environment *****************************************
>> We CANNOT use the client ID and secret of Anypoint Platform account or any individual environments for accessing the APIs
>> As the type of policy that is enforced on the API in question is "Client ID Enforcment Policy", OAuth token based access won't work.
Right way to access the API is to use the client ID and secret obtained from Anypoint Exchange for the API instance in a particular environment we want to work on.


Reference:

Managing API instance Contracts on API Manager https://docs.mulesoft.com/api-manager/1.x/request-access-to-api-task https://docs.mulesoft.com/exchange/to-request-access
https://docs.mulesoft.com/api-manager/2.x/policy-mule3-client-id-based-policies



Viewing page 3 of 20
Viewing questions 11 - 15 out of 152 questions



Post your Comments and Discuss Salesforce MuleSoft-Platform-Architect-I exam dumps with other Community members:

MuleSoft-Platform-Architect-I Exam Discussions & Posts

AI Tutor