Salesforce-MuleSoft-Developer Practice Test Questions

Explanation: Attributes are replaced with new attributes from the HTTP Request response. Attributes include everything apart from Payload/body. For ex: Headers, query parameters, URI parameters. So, when outbound HTTP request is made, new attributes need to pass the outbound HTTP request and old attributes are replaced.

Explanation:

The error message clearly states that MuleSoft is unable to load the JDBC driver class:

java.sql.SQLException: Error trying to load driver: com.mysql.jdbc.Driver : Cannot load class 'com.mysql.jdbc.Driver'.
This means the JDBC driver for MySQL is either missing or misconfigured in your project. The driver class is required for MuleSoft’s Database connector to establish a connection with the MySQL database. Without it, no SQL operation can be performed, even if other configuration parameters like URL, database name, or table name are correct.

In the error trace, it says:

Class 'com.mysql.jdbc.Driver' not found in classloader for artifact 'container' This indicates that the Mule runtime is trying to find the MySQL JDBC driver in its dependency classpath and fails to locate it. This usually happens when the driver is not added to the Mule project's dependency (Maven pom.xml) or not included in the project’s lib/ folder, especially for apps deployed to CloudHub or Runtime Fabric. You must add the correct driver version (usually mysql-connector-java-x.x.x.jar) and ensure it is available at runtime.

Incorrect Options:

A. Configure the correct host URL – Irrelevant here; driver must load before host matters.
B. Configure the correct database name – Connection fails before reaching database resolution.
C. Configure the correct table name – Table access comes after connection succeeds.
Once you add the correct JDBC driver to your project and reference it in the Database connector configuration, the class com.mysql.jdbc.Driver will be loaded successfully, and the connection will be established. This fix is independent of database name, host, or table name, because the driver must be in place before any of those values can even be used in a connection.

Explanation:

The PUT method in REST is idempotent and designed to completely replace an existing resource at a specified URI. It requires the client to send the full updated representation of the resource, overwriting the original. This makes PUT the standard choice for full updates (Option C).

Why Other Options Are Wrong

A (GET): Used only to retrieve resources, not modify them.
B (PATCH): Partially updates a resource (e.g., specific fields), not a full replacement.
D (POST): Creates new resources or triggers processes, but isn’t idempotent or meant for replacements.

Explanation:

In MuleSoft's DataWeave (DW) 2.0, when you want to import a custom module (like Utility.dwl) from a path such as src/main/resources/modules, you must use fully qualified module import syntax. The correct format is:

import modules::Utility

This tells DataWeave to look under the modules folder for a file named Utility.dwl. Once imported, to use a function from that module (like pascalize), you must prefix it with the module name, as in Utility::pascalize().

Option C correctly uses both the import syntax and the function call format. It reads:

import modules::Utility

Utility::pascalize("max mule")

This aligns perfectly with how DataWeave resolves module-scoped functions. It ensures the function is recognized in the correct namespace, avoiding runtime errors like "function not defined." This is the expected best practice when calling functions from user-defined modules in MuleSoft.

Using module-qualified function calls prevents naming collisions and makes code clearer and more maintainable. It also ensures correct referencing when multiple modules might define functions with the same name. As such, Option C is the only fully correct choice among the four.

Incorrect Options:

A. Option A – Incorrect import syntax; dot notation doesn’t work for modules.
B. Option B – Correct import, but missing module prefix when calling function.
D. Option D – Wrong import syntax (.), and incorrect function call (dot syntax invalid for modules).

Explanation: Correct answer is as below. Attributes in the incoming xml payload are always accessed using @.Similarly *item is required as we have multiple items in the request %dw 2.0 output application/csv
--- payload.sale.*item map ((value, index) -> { index: index,
sale: value.@saleId, itemName: value.desc,
itemPrice: (value.quantity) * (value.price), item: value.@itemId
} )

Explanation:
Paths
The path of an HTTP listener can be static, which requires exact matches, or feature placeholders. Placeholders can be wildcards (*), which match against anything they are compared to, or parameters ({param}), which not only match against anything but also capture those values on a URI parameters map.
Take the following example paths for three listeners using a configuration that establishes api/v1 as the base path:
account/mulesoft/main-contact: only match the exact path request http://awesome- company.com/api/v1/account/mulesoft/main-contact
account/{accountId}/main-contact: matches all path requests structured similarly, such as http://awesome-company.com/api/v1/account/salesforce/main-contact, and save salesforce as the value of accountId.
account/{accountId}/*: matches all path requests different from main-contact, such as http://awesome-company.com/api/v1/account/mulesoft/users, and save mulesoft as the value of accountId.

Explanation:

In DataWeave 2.0, the keyword fun is used to define a new function. For example:

fun square(n: Number) = n * n

This is the correct syntax (Option B).

Why Other Options Are Wrong

A (function): Not a valid keyword in DataWeave.
C (func): Not recognized in DataWeave syntax.
D (map): Used for iterating over arrays, not defining functions.

Explanation: Mule event is correct answer. Mule event has two parts which are as follows
1) Message (which contains payload and attributes like headers and query/uri parameters
2) Variables

Explanation:
* When a client application is registered in Anypoint Platform, a pair of credentials consisting of a client ID and client secret is generated.
* When the client application requests access to an API, a contract is created between the application and that API.
* An API that is protected with a Client ID Enforcement policy is accessible only to applications that have an approved contract.

------------------------------------------------------------------------------------
Correct Answer: In the organization's public API portal in Anypoint Exchange, from an approved client application for the API proxy

Explanation: In this case as outbound call is made using HTTP: POST /child , all attributes will be replaced by this invocation. Hence query parameter will not be accessible at logger.