Salesforce-MuleSoft-Developer Practice Test Questions

D.   Account Type: #[vars.accountType]

Explanation:

In Mule 4:

Flow variables are stored in the vars scope

After using a Set Variable transformer to capture the query parameter to variable accountType, you access it using vars.accountType

The Logger message can mix static text with DataWeave expressions using #[...] syntax

Correct syntax: Account Type: #[vars.accountType]

Key Concepts Tested:
- Mule 4 variable scope (vars vs Mule 3's flowVars)
- Accessing flow variables in DataWeave expressions
- Logger message syntax with mixed static/dynamic content

Analysis of Other Options:

A. Account Type: #[flowVars.accountType]: Incorrect. flowVars was used in Mule 3, replaced by vars in Mule 4.

B. Account Type: #[message.inboundProperties.accountType]: Incorrect. inboundProperties was Mule 3 syntax for accessing headers/parameters. In Mule 4, query parameters are in attributes.queryParams.

C. Account Type: #[attributes.accountType]: Incorrect. attributes contains message metadata (headers, query params, URI params), but once captured to a flow variable, you should use vars.accountType. Also, query params would be in attributes.queryParams.accountType, not directly in attributes.

Additional Note:
To directly access the query parameter without using Set Variable, you could use #[attributes.queryParams.accountType], but the question states it was already captured to a variable, so vars.accountType is correct.

A.   Publish the API to Anypoint Exchange

Explanation:

The process of making an API specification (like a RAML or OAS definition) available for consumption, sharing, and documentation follows this sequence:

Design: API is created/edited in Design Center.

Discoverability: The next step is to Publish the API specification (the contract) to Anypoint Exchange.

Anypoint Exchange acts as the central hub or marketplace for all reusable assets, including API definitions. Once published, it becomes discoverable to other internal teams (via the organization's private Exchange) or external partners.

Implementation & Management: After publishing to Exchange, it can be implemented in Anypoint Studio and then managed in API Manager.

❌ Incorrect Answers

B. Publish the API from inside flow designer: Flow Designer is the web-based implementation tool; publishing the contract for discovery is done from the Design Center interface to Exchange.

C. Deploy the API to a Maven repository: This is a technical step for deploying the implemented Mule application code, not the step for making the API contract discoverable on the Anypoint Platform.

D. Enable autodiscovery in API Manager: Autodiscovery is done after the API implementation is built and deployed, and its purpose is to link the running Mule application instance to its corresponding API definition in API Manager for runtime management (policies, security), not for initial discovery of the contract.

📚 References
API Lifecycle (Design Phase): The MuleSoft API lifecycle dictates that following the design phase (Design Center), the contract is published to Exchange for sharing and discovery.

D.   Set the watermark column to the record id column

Explanation:

The On Table Row listener in Mule uses a watermark column to ensure that only new rows (rows with a value greater than the last processed watermark) are retrieved each time it polls the database.

Since the table has record_id as an increasing numeric column, setting:
watermarkColumn = record_id
ensures:

Only rows with record_id greater than the previously processed one are fetched.
Each row is retrieved once and only once.
This is the exact mechanism MuleSoft provides for avoiding duplicate row processing.

❌ Why the other options are wrong

A. Set the target to store the last retrieved record_id value
The target just stores output into a variable; it does not control polling behavior.

B. Set the ObjectStore to store the last retrieved record_id value
While ObjectStore is used behind the scenes to track watermarks, you should not configure it manually. Mule manages this internally when watermarkColumn is set.

C. Set the target to the record_id column
Again, the target attribute does not determine how rows are selected. It simply stores the output payload somewhere else.

✔ Final Answer: D. Set the watermark column to the record id column

D.   vars. booklSBN

Explanation:

This is essentially the same concept as Question 1: accessing a value that has been explicitly stored in the Mule Event's variable scope.

Variable Storage: The Set Variable component stores data in the Variables scope.
Accessing Variables: In Mule 4 DataWeave, the keyword vars is used to access this scope.
Access Expression: To retrieve the value of the variable named booklSBN, the expression is vars.booklSBN.

❌ Incorrect Answers

A. booklSBN: This is an invalid DataWeave expression for accessing a variable; you must specify the scope (e.g., vars.). If not scoped, DataWeave attempts to resolve it as a payload field or global function.

B. attributes.booklSBN: The attributes scope holds data from the inbound request (like the URI parameter that initially held the ISBN), but once it is stored in a flow variable, it should be accessed via the vars scope.

C. flowVars.booklSBN: This is the deprecated Mule 3 syntax for accessing flow variables.

📚 References
Mule 4 Event Structure: Mule 4 uses the vars keyword to access flow variables.

B.   Option B

Explanation:

Looking at the RAML specification:

POST /users requires:

Headers: username (string) and password (string)
Body: application/json (content type specified)

Analysis of Options:

Option A: Only sets Content-Type: application/json header, missing the required username and password headers.

Option B: Correctly sets:
Content-Type: application/json (for the JSON body)
username header with a value
password header with a value
This matches the RAML requirements exactly

Option C: Attempts to pass credentials in the URL path (/api/users/username=max&password=mule), which is incorrect. Headers should be in the Headers section, not the URL. Also only sets Content-Type header.

Option D: Similar to C, tries to put credentials in URL (/api/users?username=headers&password=headers), not in headers as required. Although it does add username and password headers, the URL approach is wrong and redundant.

Key Concepts Tested:
Understanding RAML specification requirements
Difference between headers, query parameters, and path parameters
Proper way to pass authentication credentials in headers
REST API testing best practices

Reference:
REST API Design: Headers vs. query parameters usage
RAML Specification: Header requirements in method definitions

Note:
Option B correctly places username and password in the Headers section as required by the RAML spec, while also setting the proper Content-Type for the JSON body.

A.   APP: API RESOURCE NOT FOUND

Explanation:

Let's trace through the error handling:

HTTP Request throws HTTP:NOT_FOUND error.

Error Mapping in the HTTP Request:
Has an error mapping: HTTP:NOT_FOUND → APP:API_RESOURCE_NOT_FOUND
This means the HTTP:NOT_FOUND error is re-mapped to APP:API_RESOURCE_NOT_FOUND before reaching the flow's error handler.

Flow Error Handler:
Has an On Error Propagate for HTTP:NOT_FOUND → but this won't trigger because error was already re-mapped
Has an On Error Propagate for APP:API_RESOURCE_NOT_FOUND → This WILL trigger
This error handler sets payload to "APP:API_RESOURCE_NOT_FOUND"

Key Point:
Error mappings in processors (like HTTP Request) happen before the flow's error handlers
The re-mapped error (APP:API_RESOURCE_NOT_FOUND) propagates up
The matching error handler for APP:API_RESOURCE_NOT_FOUND executes and sets the payload

Why not other options:

B. HTTP:NOT_FOUND: Would be if error mapping didn't exist or didn't work

C. other error: Would be if error didn't match any specific handlers and went to the On Error Continue with when: #[true], but APP:API_RESOURCE_NOT_FOUND has a specific handler

D. success: Clearly not, since an error occurred

Key Concepts Tested:
Error mapping in processors vs. flow error handlers
Order of error processing (mapping first, then error handlers)
Error propagation behavior

Reference:
MuleSoft Documentation: Error mappings in processors transform error types before they reach flow error handlers.

D.   In the my-app.xml file, as an attribute of a configuration element

Explanation of Correct Answer

To set a named error handler (like global-error-handler) as the default exception strategy for all flows within a Mule application, you must configure the configuration element.

Configuration Element: The configuration element is a global element in a Mule configuration XML file (like my-app.xml).

Default Error Handler Attribute: You set the defaultExceptionHandler-ref attribute of the configuration element to the name of the desired error handler.

By placing this configuration in my-app.xml (the file where the flows and error handler are defined), any flow that does not have its own local defined will automatically use the global-error-handler when an error is thrown.

❌ Incorrect Answers

A. In the mule-artifact json file, as the value of a key-value pair: The mule-artifact.json file is used for configuration related to deployment and classloading (e.g., domain artifact configuration, required Mule versions). It is not used to define the application's default error handler.

B. In the Validation folder as the value of a global element in the error-handling yaml file: Mule configuration is typically defined in XML files, not YAML files specifically for error handling. Furthermore, the location "Validation folder" is not a standard configuration location for this purpose.

C. In the pom.xml file, as the value of a global element: The pom.xml file is for Maven build management (dependencies, packaging, plugins). It is not used for defining Mule application runtime configuration like the default error handler.

📚 References
Global Default Exception Strategy: The official MuleSoft documentation explains that the defaultExceptionHandler-ref attribute on the element is used to set a global default error handler for an entire Mule application.

Mule Project Structure: Documentation confirms the distinct roles of mule-artifact.json (deployment metadata) and pom.xml (Maven build configuration).

A.   #['MuleSoft' == paytoad.company]

Explanation:

The Choice router's when expression must be a valid DataWeave expression that evaluates to a Boolean (true or false).

Accessing the Payload: The company name is stored as the key company within the current payload. To access it, the expression must use payload.company.

Comparison: The goal is to check if this value is equal to the string literal "MuleSoft". DataWeave uses the double equals sign (==) for equality comparison.

Full Expression: The entire valid DataWeave expression is:

#[’MuleSoft’==payload.company]

This expression correctly compares the string "MuleSoft" with the value of the company field in the current payload, which evaluates to true when the payload is {"company": "MuleSoft"}. (Note: Single quotes 'MuleSoft' and double quotes "MuleSoft" are typically interchangeable for string literals in DataWeave).

❌ Incorrect Answers

B. #[ company = "MuleSoft" ]: This uses the single equals sign (=), which is the DataWeave assignment operator (used to define variables or map fields), not the equality comparison operator. This expression would result in an error or unexpected behavior, as it does not evaluate to a boolean.

C. #[ if( company = "MuleSoft") ]: This incorrectly uses the DataWeave if-else construct when only a single boolean condition is required. Additionally, it uses the assignment operator (=) instead of the comparison operator (==), and it fails to specify the payload scope (payload.company).

D. #[ if( 'MuleSoff == payload.company) ]: This is incorrect. While the comparison logic (== payload.company) is correct, the if keyword is unnecessary and invalid for the when condition of a Choice router, which expects a direct boolean result. Furthermore, it contains a typographical error ('MuleSoff instead of 'MuleSoft').

📚 References
Choice Router: The MuleSoft documentation for the Choice Router requires that the when condition be a DataWeave expression that evaluates to a boolean value.

DataWeave Comparison Operators: DataWeave uses the double equals sign (==) for equality comparison, and the single equals sign (=) for assignment.

A.   Request access to the API in Anypoint Exchange

Explanation:

Why A is correct
Even after a RAML (or API specification) is published to Anypoint Exchange and client credentials (Client ID Enforcement policy) are configured, consumers in the same organization still do not automatically get runtime access to the API.

The required next step is:
The consumer (or their team) must go to Anypoint Exchange → the published API → Request Access.
The API owner (or administrator) then approves the request.
Only after approval can the consumer create a client application (contract) and receive enforceable client_id / client_secret to call the protected API.

This approval workflow is mandatory for private APIs and for any API protected by Client ID Enforcement or OAuth 2.0 policies.

Why the other options are incorrect

B. Email the owners of the API → Wrong. Informal; the platform enforces the formal request/approval flow.

C. Create a new client application → Wrong. You cannot create a contract until access is granted. The “Create Contract” button is disabled until approved.

D. No additional steps needed → Wrong. Publishing to Exchange makes the spec visible, but does not grant runtime access.

References
“Consumers must request access to the API in Anypoint Exchange before they can register an application and receive credentials.”

A.   To avoid duplicate processing of records in a database.

Explanation:

The Database On Table Row operation in MuleSoft is a polling mechanism that retrieves rows from a database table. To ensure that rows are processed only once, MuleSoft uses a Watermark column:

The Watermark column is a column whose values increase over time (commonly an auto-increment record_id or a timestamp).

Mule keeps track of the last retrieved watermark value in an ObjectStore.

On the next poll, Mule retrieves only rows with a watermark value greater than the last stored one.

This prevents duplicate processing of the same records.

❌ Why the Other Options Are Incorrect

B. To delete the most recent records retrieved from a database to enable database caching
Incorrect. The watermark does not delete records; it only tracks the last processed value.

C. To enable duplicate processing of records in a database
Opposite of the actual behavior. The watermark prevents duplicates.

D. To save the most recent records retrieved from a database to enable database caching
Misleading. The watermark saves the last processed value in an ObjectStore, but not for caching purposes.

📚 References
MuleSoft Docs: Database Connector – On Table Row
Trailhead: Process Data Using Database Connector