Free MULE-DEV-201 Practice Test Questions and Answers (2026) Practice Questions

SLA (Service Level Agreement) tiers are created and managed within the API Manager component of the Anypoint Platform. API Manager is used to govern and secure APIs that are deployed and running. It allows administrators to apply policies, such as rate limiting or throttling, by defining different SLA tiers (e.g., Gold, Silver, Bronze). These tiers can then be requested by and granted to client applications, enforcing consumption limits at runtime.

A. Exchange is a repository for discovering, sharing, and reusing API specifications and other assets, not for managing runtime policies like SLAs.

C. Anypoint Studio is the IDE for designing and developing Mule applications. Runtime governance and policy management are performed in API Manager.

D. RAML is a specification language used to design an API's contract. It does not define or enforce runtime operational policies like SLA tiers.

MuleSoft Documentation, "API Manager". Describes its function: "Use API Manager to manage, govern, and secure your APIs... Apply predefined or custom policies to your APIs to control access and traffic." (docs.mulesoft.com/api-manager/2.x/)

MuleSoft Documentation, "SLA-Based Policies". Explains, "You can apply the Rate Limiting and Throttling policies to specific API methods and resources, and you can also configure the policies to enforce different service-level agreements (SLAs) for each of the API’s clients." This configuration is done in API Manager. (docs.mulesoft.com/api-manager/2.x/sla-based-policies)

The DataWeave lookup function is used to invoke another flow and pass data to it. The function's second argument is an object that defines the input for the target flow. To set the payload for the target flow (addItem), the data must be provided as the value for the key payload. The addItem flow's Set Payload transformer expects to access payload.item and payload.price. Option C correctly structures the second argument as { payload: { ... } }, which sets the payload in the addItem flow to the nested object, allowing the expressions to resolve correctly.

A. This syntax would set price, item, and itemType as variables in the target flow, not as the payload. The addItem flow would fail as payload.item would be undefined.

B. addItem(...) is the syntax for calling a DataWeave function, not for looking up and invoking a Mule flow. This would result in a compilation error.

D. addItem(...) is the syntax for calling a DataWeave function, not for looking up and invoking a Mule flow. This would result in a compilation error.

1. MuleSoft Documentation, "DataWeave lookup Function". The documentation states, "The second argument is an object that provides the payload, variables, and attributes to the flow. The keys of the object can be payload, attributes, or the names of variables." The examples show the use of the payload key to set the target flow's payload.

:

The DataWeave expression must transform an array of XML user elements into a CSV format. The expression payload.users.user uses the multi-value selector (user) to correctly select all elements under and treat them as an array. The map function then iterates over this array. For each user element, it creates a new object with name and lastName keys, mapping the corresponding values from the XML. When the output is application/csv, DataWeave automatically converts this array of objects into a CSV string with a header row derived from the object keys.

B. Option B: This uses the single-value selector (payload.users.user), which would only process the first element, resulting in an incomplete CSV file with only one data row.

C. Option C: This script is functionally identical to option A and also correct. However, in a single-choice context, both are valid, but option A uses explicit naming for clarity.

D. Option D: This attempts to map over payload.users, which is the parent object, not the array of user records. This would not iterate over the individual users correctly.

- MuleSoft Documentation, "DataWeave Selectors". (Documents the use of the multi-value selector to select all instances of a repeating element in XML).

- MuleSoft Documentation, "Map Operator". (Explains how to use map to iterate over an array and transform each item).

- MuleSoft Documentation, "CSV Format". (Describes how DataWeave transforms an array of objects into CSV format).

In DataWeave 2.x a user-defined function is declared with the fun keyword, typed parameters enclosed in parentheses, and the = operator before the body. Option B follows that exact grammar and concatenates the literal "PC-", the productCategory string and the itemID converted to String with ++. The return type is inferred automatically, so no explicit type annotation is required.

A. Uses { } and the -> arrow; this is not valid DataWeave function syntax.

C. Uses keyword function, which DataWeave 2.x does not recognise for declarations (must be fun).

D. Declares a var (variable), not a function, and employs ->, so it cannot be invoked as a function.

1. MuleSoft Documentation – DataWeave Reference “Defining Functions”, Example: fun add(a: Number, b: Number) = a + b (v.4.6, docs.mulesoft.com).

2. MuleSoft “DataWeave Language Guide”, Functions section, p.8 (PDF download from Anypoint docs site).

The flow execution begins in the Try scope. The File Write operation fails, throwing a FILE:CONNECTIVITY error. This error is caught by the On Error Propagate handler. Inside the handler, the Choice router evaluates the error type. The condition error.errorType.identifier == 'FILE:CONNECTIVITY' evaluates to true. Consequently, the payload is set to the string "ORDER:NOTCREATED". Because the error handler is an On Error Propagate, it sends an error response to the HTTP Listener, which then returns the current payload ("ORDER:NOTCREATED") with a 500-level status code to the web client.

A. This is the error type's identifier, not the message configured in the flow to be returned to the client upon this specific error.

C. This message is in the default block of the error handler's Choice router and would only be returned for errors other than FILE:CONNECTIVITY.

D. This message is set only upon the successful completion of the Try scope. The File Write operation failed, so this part of the flow is never reached.

1. MuleSoft Documentation, "Mule Error Handlers". This document explains the behavior of On Error Propagate, which catches an error, executes its components, and then re-throws the error.

2. MuleSoft Documentation, "Error Object". This page details the structure of the error object, including error.errorType.identifier, which is used to identify the specific type of error.

The basePath attribute in an HTTP Listener configuration element defines a common path prefix for all HTTP Listener operations that use that configuration. The individual listener's path is appended to this basePath. For the endpoints /apis/orders and /apis/customers, the shared prefix is /apis/. By setting basePath="/apis/", the two listeners can then be configured with path="orders" and path="customers" respectively, achieving the desired routing.

A. /apis/?: The question mark (?) is not a valid character for a base path; it is used to denote the beginning of a query string in a URI.

C. /apis/orders|customers: The pipe character (|) is not a standard syntax for defining a base path; it represents a logical OR and is not used for path matching here.

D. /apis/: Wildcards like are used in the path attribute of an individual HTTP Listener operation to match URI segments, not in the shared basePath of the configuration.

1. MuleSoft Documentation, "HTTP Listener Connector". Section: "HTTP Listener Config". The documentation for the basePath parameter states: "The base path for all listeners that reference this configuration. This value is prepended to all paths defined in the listeners."

2. MuleSoft Documentation, "Configure an HTTP Listener". This guide shows examples where a literal string like /api is used as the basePath, and specific resource paths like /products are set on the listener operation.

To dynamically construct a string in a Mule 4 component, you can use a DataWeave expression. The expression must be wrapped in #[...]. Inside the expression, the payload keyword accesses the current message payload. The ++ operator is used in DataWeave for string concatenation. The expression #[ "The year is " ++ payload.year ] correctly concatenates the literal string "The year is " with the value of the year field from the payload object, producing the desired output.

A. '#[The year is $(payload.year)]': The outer single quotes make this a literal string. The #[] and $() syntax for interpolation would not be evaluated.

B. The year is #[payload.year]: While this expression template syntax works, option D is a more explicit and complete DataWeave expression, demonstrating knowledge of the canonical string concatenation operator (++).

C. '#[The year is " + payload.year]': The outer single quotes make this a literal string. Also, + is primarily for numeric addition in DataWeave, not string concatenation.

1. MuleSoft Documentation, "DataWeave Language Guide 2.4". Section: "Operators - Infix Operators". The documentation lists ++ as the operator for concatenating two strings.

2. MuleSoft Documentation, "Expressions". Section: "Using Expressions". This page explains how to embed DataWeave expressions in component attributes using the #[...] syntax.

3. MuleSoft Documentation, "Logger Component". Examples for the message attribute show the use of #[] to embed expressions that can access the payload and other event data.

The batch‐aggregator groups records into a list of three.

Input ["A","B","C","D","E"] → “B” is removed by the filter, so the aggregator emits two result lists:

1) ["A","C","D"] (size 3 reached)

2) ["E"] (remainder on completion).

The batch scope returns the aggregated payload, therefore the last Logger prints [[ "A", "C", "D" ], ["E"]].

A Shows the first aggregated list only; missing second list.

B Outputs single string, not both aggregated groups.

C Flat list; the aggregator produces nested lists, not a single array.

1. MuleSoft Documentation, “Batch Aggregator,” Mule 4 User Guide, step-results section (https://docs.mulesoft.com/mule-runtime/4.4/batch-processing#batch-aggregator).

2. MuleSoft Documentation, “What a logger after a batch scope receives,” Mule 4 User Guide, “Batch Processing” > “Result Structure”.

3. MuleSoft Anypoint Studio 7 Tutorials, “Filtering records inside a batch step,” p.6-7.

The Scatter-Gather flow control component processes its routes concurrently, not sequentially. The overall execution time for the Scatter-Gather component is determined by the time it takes for the longest-running route to complete. In this scenario, with one route taking 10 seconds and the other taking 40 seconds, the Scatter-Gather will wait for both to finish. Therefore, the total time will be dictated by the slower route, which is 40 seconds.

A. 10: This is the execution time of the fastest route. The Scatter-Gather must wait for all routes to complete.

B. 50: This would be the total time if the routes were executed sequentially, but Scatter-Gather executes them in parallel.

D. 20: This value is arbitrary and does not correspond to the execution logic of the Scatter-Gather component.

1. MuleSoft Documentation, "Scatter-Gather". In the "Behavior" section, it states: "The Scatter-Gather component executes each route in parallel... After all routes execute, the Scatter-Gather component creates a new Mule event that combines the Mule events returned by each route." This parallel execution model implies the total time is governed by the longest route.

2. MuleSoft Documentation, "Flow Control". This document describes Scatter-Gather as a component that "sends the same message to multiple targets concurrently." The term "concurrently" is key to understanding that the total processing time is not cumulative.

The default TCP port for the Mule debugger in Anypoint Studio is 6666. When you start a Mule application in debug mode, the embedded Mule runtime listens on this port for a connection from the Anypoint Studio debugger client. While this port can be changed in the debug configuration settings, 6666 is the pre-configured default value used by the platform.

A. 8082 is not the default debugger port. It is sometimes used as an alternative HTTP listener port if 8081 is taken.

B. 8080 is a common default port for web servers, but it is not the default port for the Mule debugger.

C. 7777 is not the default debugger port. It is the default port for the Mule agent to communicate with Anypoint Runtime Manager.

1. MuleSoft Documentation, "Debug a Mule Application". "By default, the debugger is configured to listen for TCP connections on port 6666 of the localhost."

2. MuleSoft Documentation, "Create a Debug Configuration". Under the "General" tab of the Debug Configurations window, the default value for the "Port" field is shown as 6666.

The Choice router evaluates its conditional routes sequentially from top to bottom. It executes the block of components corresponding to the first condition that evaluates to true. Once a matching route is found and executed, the Choice router's execution completes, and it does not evaluate any subsequent conditions. Since the question states all three conditions are true, the router will evaluate the first condition, find it true, execute the "Route1" Logger, and then exit, ignoring the other routes.

B. Route2: This would only be logged if the first condition were false and the second were true. The Choice router stops after the first true condition.

C. Route1,Route2: This is incorrect because the Choice router executes only one path, not multiple paths, based on the first successful evaluation.

D. Route1,Route2,Default: The default route is only executed if none of the preceding conditions evaluate to true.

- MuleSoft Documentation, "Choice Router". The documentation explicitly states: "The Choice router...routes messages through a flow...The first expression that evaluates to true triggers that route’s execution." (Document ID: choice-router)

- MuleSoft Documentation, "Control Flow Scopes". This section describes the fundamental "first-match" logic of the Choice router in contrast to other routers like Scatter-Gather. (Document ID: control-flow-scopes)

The HTTP Listener path attribute supports URI templates, including wildcards. The asterisk () wildcard is used to match a single segment in the URL path. In this case, the path /status will correctly match both /order/status and /customer/status because the will match either order or customer as a single path segment. This allows a single HTTP Listener to handle requests for both endpoints, routing them to the same flow for processing.

A. [order,customer]/status is not a valid URI template syntax for the HTTP Listener path. It resembles a regular expression, which is not the matching mechanism used here.

B. ?[order,customer]/status is invalid syntax. The ? character is used to denote the beginning of query parameters, not for path segment matching.

D. status is incorrect because the wildcard matches a whole path segment. This pattern would match URLs like /somethingstatus but not /order/status.

1. MuleSoft Documentation, "HTTP Listener Connector". In the "Path" attribute description, it states: "The path can contain URI template parameters, which allow you to bind parts of the URI to variables in the flow." Wildcards are a form of this.

2. MuleSoft Documentation, "Create an HTTP Listener Source". Under the "General" tab configuration for the path, it explains the use of path parameters and wildcards. For example, /users/{userId}. The single segment wildcard functions similarly to a named parameter like {userId} but without capturing the value to a variable.

When sharing a Mule project for another developer to import into their Anypoint Studio, the goal is to provide the source code and project structure. The "Attach Project Sources" option packages all necessary source files, including pom.xml. The receiving developer's Anypoint Studio will use Maven and the pom.xml to automatically resolve and download all required dependencies, such as ActiveMQ JMS. Not including the dependencies creates the smallest possible archive file and is the standard practice for sharing projects between developers.

B. Including dependencies makes the archive file unnecessarily large and is redundant, as Maven will manage dependencies in the new workspace.

C. Including only dependencies without the project source code is not useful, as the developer cannot view, modify, or run the application logic.

D. Exporting without sources or dependencies would create an unusable project archive. The project source code is essential for it to be imported.

1. MuleSoft Documentation, "Anypoint Studio - Exporting and Importing Projects". The section on exporting projects explains the different options. The standard method for sharing source code is to export an "Anypoint Studio Project to Mule Deployable Archive (includes Studio metadata)", ensuring "Attach Project Sources" is checked. (docs.mulesoft.com/studio/7.15/export-import-project-task)

2. MuleSoft Documentation, "Building a Mule Application with Maven". This document explains that the pom.xml file, which is part of the project sources, defines the project's dependencies, which are then managed by Maven. (docs.mulesoft.com/mule-runtime/4.4/building-with-maven)

The DataWeave Core (dw::Core) module contains the most frequently used functions and operators for data transformation. To streamline development, all functions and modules within dw::Core are automatically imported and available for use in any DataWeave script. This eliminates the need for an explicit import statement for fundamental operations on strings, numbers, arrays, and objects, making scripts more concise.

B. dw::System provides access to system properties and environment variables and must be explicitly imported before use.

C. dw::Runtime provides information about the Mule runtime environment and requires an explicit import to be used.

D. dw::Crypto contains cryptographic functions and must be explicitly imported to ensure clarity and security in the script.

1. MuleSoft Documentation, "DataWeave Core Functions (dw::Core)". States: "All the functions and modules in the Core (dw::Core) module are imported automatically into your DataWeave scripts."

2. MuleSoft Documentation, "DataWeave Modules". This page lists various modules, implicitly showing that modules other than Core require an import statement. For example, the dw::Crypto section shows the required import syntax.

According to RESTful API design principles, a URL path identifies a resource. The path /api/patients refers to the collection of all patient resources. Query parameters, which appear after the ? in a URL, are used to filter, sort, or paginate the collection. Therefore, the query parameter ?year=2021 acts as a filter on the patients collection. The standard and expected behavior for this endpoint is to return a list of all patients that match the criteria of being from the year 2021.

A. Patient with id 2021: Retrieving a single resource by its unique identifier is conventionally done using a path parameter, for example: /api/patients/2021.

C. No patients: While this is a possible outcome if no patients match the filter, it is not the intended function of the query parameter itself.

D. All patients: This would be the expected response for a request to the base collection URI /api/patients without any filtering query parameters.

1. MuleSoft Documentation, "Designing APIs". This guide covers RESTful principles, including the use of resource paths for collections and query parameters for filtering those collections. (docs.mulesoft.com/api-manager/2.x/designing-your-api)

2. RAML 1.0 Specification, "Resource". The specification, which MuleSoft heavily utilizes, details how query parameters are defined and used to "filter the collection of resources". (github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md#query-parameters)

The RAML specification defines /accounts as the resource path. The get method for this resource specifies accounttype and industry as queryParameters. According to REST API and HTTP standards, query parameters are appended to the resource path following a question mark (?). Multiple query parameters are separated by an ampersand (&). The correct format is key=value. Therefore, to filter by accounttype=retail and industry=finance, the correct URI is /accounts?accounttype=retail&industry=finance.

A. /accounts/retail/finance: This syntax is for URI parameters, where retail and finance would be values for path segments, not query parameters as defined in the RAML.

C. /accounts/accounttype=retail/industry=finance: This incorrectly mixes the syntax for URI parameters (using slashes) with key-value pairs, which is not a valid URI structure.

D. /accounts?accounttype:retail&industry:finance: This incorrectly uses a colon (:) to separate the parameter name and its value. The correct separator is an equals sign (=).

1. MuleSoft Documentation, "Design an API". Section: "Define resources and methods". The documentation illustrates that query parameters are defined under the queryParameters node and are used in URIs with the ? and & syntax.

2. RAML 1.0 Specification, "Resource". Section: "Query Parameters". The specification states: "Query parameters are passed from the client to the server as part of the query string of a URI".

3. MuleSoft Documentation, "HTTP Listener". Section: "Sources". Examples show how requests with query parameters (e.g., /users?id=123) are handled.

The Mule debugger pauses execution before the component with the breakpoint is executed. The breakpoint is on the Set Payload component, which has not yet run. The preceding Logger component does not modify the Mule event's payload. Therefore, the payload remains in the state it was in before the Logger. Assuming the flow was initiated with or had its payload set to "Begin" prior to the components shown, the payload at this breakpoint would be "Begin".

A. "Processing" is the value that will be set by the component with the breakpoint. Since the debugger stops before execution, this change has not yet occurred.

C. "Finished" is a message from a Logger component that is located further down the flow and has not been reached by the execution.

1. MuleSoft Documentation, "Debug a Mule Application". This document states, "When a flow execution stops at a breakpoint, the execution is paused before the processor with the breakpoint is executed." This confirms the payload has not yet been changed to "Processing".

2. MuleSoft Documentation, "Mule Event". This document explains the structure of a Mule event, distinguishing between the payload and other components. It clarifies that a Logger component, by default, does not modify the payload, whereas a Set Payload component does.

The question requires a valid config.yaml file to set hierarchical properties used in the HTTP Listener configuration (${http.host}, ${http.port}). YAML (YAML Ain't Markup Language) uses indentation to represent structure. Option B correctly defines a top-level http key with nested host and port keys. This structure allows Mule to resolve the properties http.host and http.port correctly. The other options use incorrect syntax for a YAML file.

A. This option uses = which is typical for .properties files, not the colon (:) and indentation required by YAML syntax.

C. This option uses the key = value format of a standard Java .properties file, which is not the correct syntax for a .yaml file.

D. This option uses JSON syntax. While YAML is a superset of JSON, this is not the idiomatic or expected format for a file named config.yaml.

MuleSoft Documentation, "Configure Properties". This document illustrates how to use YAML configuration files, showing the hierarchical structure with indentation. See the section on "YAML Configuration File". (docs.mulesoft.com/mule-runtime/4.4/configuring-properties#yamlconfigurationfile)

MuleSoft Documentation, "Properties in Connectors". This page shows examples of using property placeholders like ${http.port} in connector configurations, which are then resolved from configuration files. (docs.mulesoft.com/mule-runtime/4.4/configuring-properties#properties-in-connectors)

YAML Specification (yaml.org), Version 1.2.2, Section 2.1 "Collections". The official specification defines the use of indentation and key-value pairs separated by a colon.

When an API specification is published to Anypoint Exchange and secured (e.g., using a Client ID Enforcement policy), consumers cannot use it directly. The standard, platform-driven process to gain access is to find the API asset in Exchange and use the "Request access" button. This initiates a workflow where the consumer associates the request with a client application, and the API owner can then approve or reject the request. Once approved, the client application receives the necessary credentials to invoke the API.

B. Emailing owners is an out-of-band, informal process and not the standard, auditable procedure within Anypoint Platform for gaining API access.

C. Creating a client application is part of the access request process, but the primary action taken on the API's Exchange page is "Request access".

D. This is incorrect because the API requires client credentials, meaning access is restricted and requires explicit approval before it can be used.

1. MuleSoft Documentation, "Request Access to an API in Exchange". This guide explicitly states, "You can request access to an API version from its API portal in Anypoint Exchange." It details the process starting with the "Request access" button. (Anypoint Platform > Exchange > Consume Assets > Request Access to an API in Exchange).

2. MuleSoft Documentation, "Client Management". This document explains that "To call a protected API, you must first register your app... When you register your app, you get a client ID and client secret, which you must pass with every call to the API." This registration happens via the access request process. (Anypoint Platform > API Manager > Client Management).