10 free Salesforce MuleSoft Developer practice questions with the correct answer and a full explanation for each, taken from the CertStash pack of 60 questions. Work through them, then open each answer to check your reasoning.
Get all 60 questions (US$39) · Download these 10 as a PDF
Question 1
Refer to the exhibits. The Mule application does NOT define any global error handlers.
The Validation component in the private flow throws an error.
What response message is returned to a web client request to the main flow's HTTP Listener?

Show answer and explanation
Correct answer: B. "Child error"
When the Validation component in the private flow throws an error, the private flow's error handler catches it via the On Error Propagate handler, which sets the payload to 'Child error' and propagates the error up to the calling flow. Since there are no global error handlers defined, the error propagates from the private flow back to the main flow. The main flow's error handler then catches this propagated error via its On Error Propagate handler, which would set the payload to 'Parent error'. However, the question asks what response is returned to the web client. The error propagates through the main flow's error handler, but the 'Child error' payload from the private flow's error handler is what gets returned to the client because error propagation passes the modified message context back up the chain. The private flow's error handler executes first, sets the payload to 'Child error', and this modified message is what propagates to the main flow's error handler and ultimately back to the HTTP Listener client.
Why the other options are wrong
- A. This is the payload set by the main flow's error handler, but it would only be returned if the error originated in the main flow or if the main flow's error handler overwrites the child error payload.
- C. This payload is set by the main flow's normal (non-error) path execution and would only be returned on successful completion without errors.
- D. The Validation Error is the message attribute, not the payload that would be returned to the client in the response body.
Question 2
A function named toUpper needs to be defined that accepts a string named userName and returns the string in uppercase.
What is the correct DataWeave code to define the toUpper function?
Show answer and explanation
Correct answer: B. fun toUpper(userName) = upper(userName)
In DataWeave, functions are defined using the `fun` keyword followed by the function name, parameters in parentheses, an equals sign, and the function body. The correct syntax is `fun toUpper(userName) = upper(userName)`, which declares a function named toUpper that accepts a userName parameter and returns the result of the upper() function applied to that parameter.
Why the other options are wrong
- A. Uses `var` keyword instead of `fun`; `var` is for variable assignment, not function definition.
- C. Uses `var` keyword with incorrect arrow syntax `->` instead of the equals sign required for function definitions.
- D. Uses the `fun` keyword correctly but employs arrow syntax `->` instead of the equals sign `=` required in DataWeave function definitions.
Question 3
Northern Trail Outfitters (NTO) has an API to manage departments, with each department identified by a unique deptId. The API was built with RAML according to MuleSoft best practices.
What is valid RAML to specify a method to update the details for a specific department?

Show answer and explanation
Correct answer: B. /departments:
/{deptId}: patch: According to RAML best practices and MuleSoft standards, path parameters that identify specific resources should be defined using curly braces in the resource path itself, not as query parameters. Option B correctly specifies the endpoint as /departments/{deptId} with the patch method, which is the proper RAML syntax for updating a specific department resource identified by its unique deptId. The curly braces denote a URI parameter that is part of the resource path, which is the standard approach for RESTful APIs when targeting a specific resource.
Why the other options are wrong
- A. Uses queryParameters for deptId, which is inappropriate for identifying a specific resource in a RESTful API; path parameters should be used instead.
- C. Uses /deptId without curly braces, which does not define it as a valid URI parameter and does not follow RAML syntax conventions.
- D. Places /deptId after the patch method instead of in the resource path hierarchy, which is structurally incorrect RAML.
Question 4
Refer to the exhibits. A Mule application polls a database table.
This error is logged when the Mule application is run.
What should be changed in the Database connector configuration to resolve this error?

Show answer and explanation
Correct answer: A. Configure the correct JDBC driver
The error log clearly indicates 'Cannot load class 'com.mysql.jdbc.Driver'' multiple times, with the root cause being that the MySQL JDBC driver class cannot be found or loaded. This is a driver classpath or configuration issue, not a connection URL, database name, or table name problem. The error occurs before any connection attempt is made, during the driver loading phase. Configuring the correct JDBC driver by ensuring the MySQL driver JAR is in the classpath and properly referenced in the connector configuration will resolve this issue.
Why the other options are wrong
- B. The host URL error would typically manifest as a connection refused or unknown host error after the driver loads successfully, which is not occurring here.
- C. An incorrect database name would cause a database selection error after connection is established, not a driver loading failure.
- D. An incorrect table name would cause a table not found error during polling, not during the initial driver loading phase.
Question 5
Refer to the exhibits. BetterBooks has defined this Book data type and Book example to be used in APIs.
What is valid RAML for an API that uses this Book data type and Book example?



Show answer and explanation
Correct answer: B. types:
Book: !include bookDataType.raml /books: post: body: application/json: type: Book examples: input: !include bookExample.raml responses: 201: body application/json: example: message: Book added Option B is the correct RAML structure for incorporating an external data type and example. It properly defines the types section with !include to reference the bookDataType.raml file, and within the POST endpoint's body, it correctly uses !include for the example input to reference bookExample.raml. This follows RAML 1.0 conventions where types must be declared in a dedicated types section at the appropriate hierarchy level, and file includes use the !include syntax. Options A, C, and D have structural or syntactic issues that violate RAML specifications.
Why the other options are wrong
- A. This option lacks the proper types section definition and uses incorrect reference paths (ABC/Examples/ prefix) instead of the correct !include syntax.
- C. This option places the Book type definition outside the types section at the root level, which violates RAML structure; the types section declaration is required.
- D. This option omits the !include directive and uses bare file names without the include keyword, and lacks the required types section declaration.
Question 6
Refer to the exhibits. The web client sends a POST request to the ACME Orders API with an XML payload.
An error is returned.
What should be changed in the request so that a success response code is returned to the web client?

Show answer and explanation
Correct answer: D. Set a request header with the name Content-Type to the value application/xml
the value application/xml The error '415 Unsupported Media Type' indicates the server cannot process the request because it doesn't recognize the media type being sent. The API specification on the left shows the endpoint accepts 'application/xml' in the request body. To resolve this error, the client must set the Content-Type request header to 'application/xml' so the server knows the incoming payload is XML and can process it accordingly. Request headers tell the server what format the client is sending; response headers describe what the server is sending back.
Why the other options are wrong
- A. application/octet-stream is for binary data, not XML, and would not resolve the unsupported media type error for an XML payload.
- B. Response headers are set by the server, not the client making the request, and cannot fix a client-side content type problem.
- C. While the value application/xml is correct, the Content-Type header must be set as a request header (by the client), not a response header (by the server).
Question 7
Refer to the exhibit.
What is the correct syntax to add a customer ID as a URI parameter in an HTTP Listener's path attribute?

Show answer and explanation
Correct answer: A. {customerID}
In Mule, URI parameters in an HTTP Listener's path attribute use curly braces syntax {parameterName}. This is the standard REST URI template format where parameters are enclosed in braces and can be referenced later in the flow using MEL expressions like #[uriParams.customerID]. The path /accounts/{customerID} would match requests like /accounts/12345, extracting 12345 as the customerID parameter value.
Why the other options are wrong
- B. The #[] syntax is for Mule Expression Language (MEL) evaluation, not for defining URI parameter placeholders in the path attribute.
- C. The $() syntax is not valid for URI parameter definition in Mule HTTP Listener configurations.
- D. Simple parentheses () are not used for URI parameter syntax in Mule; curly braces are the correct delimiter.
Question 8
Refer to the exhibits. The Set Variable transformer is set with value #[ { first: "Max", last: Mule" } ]
What is a valid DataWeave expression to set as the message attribute of the Logger to access the value "Max" from the Mule event?

Show answer and explanation
Correct answer: A. "customer.first"
In Mule 4, variables are accessed in DataWeave expressions using dot notation directly on the variable name when inside a DataWeave context like a Logger message attribute. Since the Set Variable transformer stores the object in the variable named 'customer', and the Logger's message attribute is evaluated as a DataWeave expression, the correct syntax to access the 'first' field is 'customer.first'. The 'vars' prefix is used when accessing variables from outside a DataWeave context (such as in Mule expressions using #[]), but within a DataWeave expression itself, variables are accessed directly by name.
Why the other options are wrong
- B. While vars.customer.first is valid in some contexts, the Logger message attribute processes DataWeave expressions where variables are accessed directly without the 'vars' prefix.
- C. The dot notation 'vars."customer.first"' treats the entire string as a single key name rather than nested field access.
- D. In Mule 4 DataWeave expressions, variables must be referenced to distinguish them from other identifiers, so 'customer.first' alone without proper variable qualification is incorrect syntax for accessing a stored variable.
Question 9
Refer to the exhibits. The Mule application does NOT define any global error handlers.
A web client sends a POST request to the Mule application with this input payload. The File Write operation throws a FILE:CONNECTIVITY error.
What response message is returned to the web client?

Show answer and explanation
Correct answer: B. "ORDER:NOT_CREATED"
When the File Write operation throws a FILE:CONNECTIVITY error, the error-mapping configuration in the flow explicitly maps this error type to ORDER:NOT_CREATED. The error-mapping element specifies sourceType="FILE:CONNECTIVITY" targetType="ORDER:NOT_CREATED", which transforms the FILE:CONNECTIVITY error into an ORDER:NOT_CREATED error. This mapped error is then set as the payload in the http:error-response, which is returned to the web client. Since there are no global error handlers defined, only the local flow's error handling applies, and the error mapping directly determines the response message.
Why the other options are wrong
- A. "File written" is the success payload and would only be returned if the File Write operation completed successfully without errors.
- C. FILE:CONNECTIVITY is the source error type, but it is mapped to ORDER:NOT_CREATED before being returned to the client, so the client receives the mapped error type, not the original error.
- D. "OTHER ERROR" is only used when the error matches neither FILE:CONNECTIVITY nor ORDER:NOT_CREATED conditions, but the FILE:CONNECTIVITY error is explicitly mapped in the error-mapping configuration.
Question 10
Refer to the exhibits. The main flow contains an HTTP Request operation configured to call the child flow's HTTP Listener.
A web client sends a GET request to the HTTP Listener with the qty query parameter set to 30.
After the HTTP Request operation completes, what parts of the Mule event at the main flow's Logger component are the same as the Mule event that was input to the HTTP Request operation?

Show answer and explanation
Correct answer: D. The payload and all variables
When an HTTP Request operation completes and returns to the calling flow, the Mule event's payload is replaced with the response from the child flow, but variables persist across flow boundaries because they are stored in the event context. In this scenario, the main flow sets a variable called 'quantity' using the set-variable component before making the HTTP Request. After the child flow completes and returns, this variable remains intact in the event at the main flow's Logger. However, the payload and attributes are replaced with the HTTP response from the child flow (the 'child flow finished' payload), which differs from the original input payload ('Order01') to the HTTP Request operation. Therefore, only the payload and all variables would be the same, but since the payload changes, only all variables remain the same from the input event to the HTTP Request operation. The correct answer is that variables persist while the payload and attributes are transformed by the HTTP response.
Why the other options are wrong
- A. The entire Mule event cannot be the same because the HTTP Request operation receives a response that replaces the payload and attributes.
- B. While variables do persist, this option excludes the payload, which is incomplete; the question asks what parts are 'the same,' and variables alone is not the complete answer.
- C. The payload and attributes are replaced by the HTTP response from the child flow, so they are not the same as what was input to the HTTP Request operation.
That was 10 of 60.
The full Salesforce MuleSoft Developer pack has all 60 questions, each with the answer, the explanation and why the other options are wrong, plus a questions-only copy for timed runs. US$39, paid once, with free monthly updates and a pass-or-your-money-back guarantee.
