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.

Explanation:

The For Each scope iterates over a collection in the same event thread, processing one element at a time by default. There’s no built-in thread pool or parallelism — it simply blocks until each element is handled before moving to the next.

In contrast, a Batch Job harnesses Mule’s asynchronous engine. It divides incoming records into batches and farm-outs those batches across multiple worker threads (16 by default in Mule 4). Each batch block processes in parallel, dramatically speeding up large-scale data operations.

Incorrect options:

• B. Batch Job isn’t single-threaded.
• C. For Each isn’t multi-threaded by default.
• D. This inverts the actual behavior.

Explanation:

When you run a Mule application in debug mode using Anypoint Studio, the Mule runtime launches a remote debugging process that listens on a specific port for incoming debugger connections. By default, this port is 7777, which is pre-configured in the debugger settings of Anypoint Studio. This port allows Studio’s debugger to attach to the running Mule application and interactively inspect variables, payloads, and execution flow.

This default value (7777) is used unless manually changed in the Studio debugger configuration or overridden via command-line settings. It ensures that developers can set breakpoints and step through flows during development and troubleshooting without additional setup. If multiple Mule apps are debugged at the same time, you may need to modify the port to avoid conflicts.

Knowing this default port is useful when configuring firewalls, managing IDE settings, or setting up remote debugging on different environments. It ensures a smooth and responsive debugging experience during MuleSoft development workflows.

Incorrect Options:

A. 8082 – Common for other services, not Mule debugger.
B. 8080 – Default for HTTP, not debugging.
D. 6666 – Not used by default in Anypoint Studio debugging.

Explanation:

The Logger uses #[ typeOf(payload) ], which returns the Mule payload’s data type:

Given that the Select (Database) connector outputs a list of maps (each row as a map, all rows as an array), the payload entering the Logger is an Array of Objects. In DataWeave terms, that’s an Array.

So the logger prints: Array.

Explanation:

Following RESTful and RAML best practices, each purchase order is modeled as a resource under the /orders base URI, with its unique ID as a path parameter. In your RAML spec you’d declare something like /orders/{orderId}, so a client requests a specific record by substituting its ID directly in the path.

Incorrect options:

A. /orders/{P05555} is the RAML template, not the actual call.
B. /orders/order=P05555 misuses path syntax with an equals sign.
C. /orders?order=P05555 treats the ID as a query parameter instead of a path segment.