Salesforce-MuleSoft-Platform-Architect Exam Questions With Explanations

The best unofficial Salesforce-MuleSoft-Platform-Architect exam questions with research based explanations of each question will help you Prepare & Pass the exam for FREE!

Start Practice Free
Over 15K Students have given a five star review to SalesforceKing

Why choose our Practice Test

By familiarizing yourself with the Salesforce-MuleSoft-Platform-Architect exam format and question types, you can reduce test-day anxiety and improve your overall performance.

Up-to-date Content

Ensure you're studying with the latest exam objectives and content.

Unlimited Retakes

We offer unlimited retakes, ensuring you'll prepare each questions properly.

Realistic Exam Questions

Experience exam-like questions designed to mirror the actual Salesforce-MuleSoft-Platform-Architect test.

Targeted Learning

Detailed explanations help you understand the reasoning behind correct and incorrect answers.

Increased Confidence

The more you practice, the more confident you will become in your knowledge to pass the exam.

Study whenever you want, from any place in the world.

Salesforce Salesforce-MuleSoft-Platform-Architect Exam Sample Questions 2025

Start practicing today and take the fast track to becoming Salesforce Salesforce-MuleSoft-Platform-Architect certified.

21524 already prepared
Salesforce Spring 25 Release18-Sep-2025
152 Questions
4.9/5.0

An API implementation is being designed that must invoke an Order API, which is known to repeatedly experience downtime. For this reason, a fallback API is to be called when the Order API is unavailable. What approach to designing the invocation of the fallback API provides the best resilience?

A. Search Anypoint Exchange for a suitable existing fallback API, and then implement invocations to this fallback API in addition to the Order API

B. Create a separate entry for the Order API in API Manager, and then invoke this API as a fallback API if the primary Order API is unavailable

C. Redirect client requests through an HTTP 307 Temporary Redirect status code to the fallback API whenever the Order API is unavailable

D. Set an option in the HTTP Requester component that invokes the Order API to instead invoke a fallback API whenever an HTTP 4xx or 5xx response status code is returned from the Order API

A.    Search Anypoint Exchange for a suitable existing fallback API, and then implement invocations to this fallback API in addition to the Order API

Explanation

Correct Answer: Search Anypoint exchange for a suitable existing fallback API, and then implement invocations to this fallback API in addition to the order API

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

>> It is not ideal and good approach, until unless there is a pre-approved agreement with the API clients that they will receive a HTTP 3xx temporary redirect status code and they have to implement fallback logic their side to call another API.

>> Creating separate entry of same Order API in API manager would just create an another instance of it on top of same API implementation. So, it does NO GOOD by using clone od same API as a fallback API. Fallback API should be ideally a different API implementation that is not same as primary one.

>> There is NO option currently provided by Anypoint HTTP Connector that allows us to invoke a fallback API when we receive certain HTTP status codes in response.

The only statement TRUE in the given options is to Search Anypoint exchange for a suitable existing fallback API, and then implement invocations to this fallback API in addition to the order API.

Version 3.0.1 of a REST API implementation represents time values in PST time using ISO 8601 hh:mm:ss format. The API implementation needs to be changed to instead represent time values in CEST time using ISO 8601 hh:mm:ss format. When following the semver.org semantic versioning specification, what version should be assigned to the updated API implementation?

A. 3.0.2

B. 4.0.0

C. 3.1.0

D. 3.0.1

B.   4.0.0

Explanation

Correct Answer: 4.0.0

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

As per semver.org semantic versioning specification:

Given a version number MAJOR.MINOR.PATCH, increment the:

- MAJOR version when you make incompatible API changes.

- MINOR version when you add functionality in a backwards compatible manner.

- PATCH version when you make backwards compatible bug fixes.

As per the scenario given in the question, the API implementation is completely changing its behavior. Although the format of the time is still being maintained as hh:mm:ss and there is no change in schema w.r.t format, the API will start functioning different after this change as the times are going to come completely different.

Example: Before the change, say, time is going as 09:00:00 representing the PST. Now on, after the change, the same time will go as 18:00:00 as Central European Summer Time is 9 hours ahead of Pacific Time.

>> This may lead to some uncertain behavior on API clients depending on how they are handling the times in the API response. All the API clients need to be informed that the API functionality is going to change and will return in CEST format. So, this considered as a MAJOR change and the version of API for this new change would be 4.0.0

An Order API triggers a sequence of other API calls to look up details of an order's items in a back-end inventory database. The Order API calls the OrderItems process API, which calls the Inventory system API. The Inventory system API performs database operations in the back-end inventory database.
The network connection between the Inventory system API and the database is known to be unreliable and hang at unpredictable times.
Where should a two-second timeout be configured in the API processing sequence so that the Order API never waits more than two seconds for a response from the Orderltems process API?

A. In the Orderltems process API implementation

B. In the Order API implementation

C. In the Inventory system API implementation

D. In the inventory database

B.   In the Order API implementation

Explanation:

To guarantee that the Order API never waits more than two seconds for a response from its upstream OrderItems Process API, you must configure the timeout on the HTTP Request connector in the Order API itself. Setting a 2000 ms response timeout in the Order API’s HTTP Request operation ensures that if the Process API call hangs, the HTTP operation will fail fast after two seconds and allow the Order API to handle the error accordingly. By default, Mule’s HTTP connector uses a 30 000 ms (30 s) response timeout; you can override this per-connector instance using the “Response timeout” attribute. Configuring the timeout in downstream components or at the database level does not prevent the Order API from waiting indefinitely on the HTTP call.

A code-centric API documentation environment should allow API consumers to investigate and execute API client source code that demonstrates invoking one or more APIs as part of representative scenarios. What is the most effective way to provide this type of code-centric API documentation environment using Anypoint Platform?

A. Enable mocking services for each of the relevant APIs and expose them via their Anypoint Exchange entry

B. Ensure the APIs are well documented through their Anypoint Exchange entries and API Consoles and share these pages with all API consumers

C. Create API Notebooks and include them in the relevant Anypoint Exchange entries

D. Make relevant APIs discoverable via an Anypoint Exchange entry

C.   Create API Notebooks and include them in the relevant Anypoint Exchange entries

Explanation

Correct Answer: Create API Notebooks and Include them in the relevant Anypoint exchange entries

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

API Notebooks are the one on Anypoint Platform that enable us to provide code-centric API documentation

Reference: [: https://docs.mulesoft.com/exchange/to-use-api-notebook, , Bottom of Form, Top of Form, , ]

An Anypoint Platform organization has been configured with an external identity provider (IdP) for identity management and client management. What credentials or token must be provided to Anypoint CLI to execute commands against the Anypoint Platform APIs?

A. The credentials provided by the IdP for identity management

B. The credentials provided by the IdP for client management

C. An OAuth 2.0 token generated using the credentials provided by the IdP for client management

D. An OAuth 2.0 token generated using the credentials provided by the IdP for identity management

A.   The credentials provided by the IdP for identity management

Explanation

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

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

Reference: https://docs.mulesoft.com/runtime-manager/anypoint-platformcli#authentication >> There is no support for OAuth 2.0 tokens from client/identity providers to authenticate via Anypoint CLI. Only possible tokens are "bearer tokens" that too only generated using Anypoint Organization/Environment Client Id and Secret from

https://anypoint.mulesoft.com/accounts/login.

Not the client credentials of client provider. So, OAuth 2.0 is not possible. More over, the token is mainly for API Manager purposes and not associated with a user. You can NOT use it to call most APIs (for example Cloudhub and etc) as per this Mulesoft Knowledge article.

>> The other option allowed by Anypoint CLI is to use client credentials. It is possible to use client credentials of a client provider but requires setting up Connected Apps in client management but such details are not given in the scenario explained in the question.

>> So only option left is to use user credentials from identify provider

Prep Smart, Pass Easy Your Success Starts Here!

Transform Your Test Prep with Realistic Salesforce-MuleSoft-Platform-Architect Exam Questions That Build Confidence and Drive Success!