Free Practice Questions for the Salesforce MuleSoft Mule-Dev-301 Exam (2026 Updated)

Mutual TLS requires authentication in both directions. The Mule HTTP Listener acts as the TLS server, so it needs a keystore containing its private key and associated server certificate. This allows the listener to prove its identity to the connecting client.

For mTLS, the server must additionally authenticate the client certificate. Therefore, the TLS context also requires an appropriate truststore containing the certificate authorities or certificates that the application trusts when validating client certificates.

MuleSoft's TLS documentation provides a two-way authentication example for an HTTP Listener containing both < tls:trust-store > and < tls:key-store > inside the TLS context. MuleSoft's HTTP Listener documentation likewise states that HTTPS requires a keystore for the server and a truststore when two-way authentication is required.

Persistent connections affect HTTP connection reuse and performance, not certificate authentication. A reconnection strategy likewise does not provide the cryptographic identity material required for mTLS.

Therefore, an HTTP Listener configured for mutual TLS requires the correct keystore and truststore configuration.

Reference topics: Mule TLS Context; HTTP Listener HTTPS; keystores; truststores; mutual TLS/two-way authentication.

Official documentation: https://docs.mulesoft.com/mule-runtime/4.6/tls-configuration

Official documentation: https://docs.mulesoft.com/http-connector/latest/http-listener-ref

===============================================================

The significant attribute in the MUnit definition is expectedErrorType="APP:CUSTOM_ERROR". The referenced implementation flow deliberately invokes raise-error with exactly the same error type: APP:CUSTOM_ERROR.

MUnit supports expected-error testing specifically for negative scenarios. When expectedErrorType is configured, the test is considered successful when execution produces that expected Mule error. The raised error is therefore not treated as an unexpected test failure; it satisfies the test's declared expectation.

The apparently failing assertion—testing true against equalTo(false)—does not change the result in this scenario because normal execution does not reach the validation chain after the referenced flow raises the expected error. The expected error terminates the execution path being tested and satisfies the MUnit expectation.

If the implementation generated a different error type, option B would apply. If it generated no error when an error was expected, the test would also fail. Here, however, the flow explicitly raises the exact application-defined error specified by the test.

Reference topics: MUnit Test Structure; expectedErrorType; Error Testing; Raise Error Component.

Official documentation: https://docs.mulesoft.com/munit/3.6/munit-test-concept

===============================================================

Standard TLS authenticates the server to the client through the server's public certificate. The client validates that certificate against its configured trusted certificate authorities. Mutual TLS extends this process by requiring the client to present its own certificate so that the server can authenticate the client's identity as well.

MuleSoft describes a TLS-enabled server as exposing its public certificate while retaining its private key, and states that TLS clients validate the server certificate against their trusted certificates. For two-way TLS, both keystore and truststore material are configured so that the server can additionally validate certificates presented by clients.

Accordingly, server identity authentication is part of the TLS handshake before completion of the mutual client-authentication exchange. This makes option C the valid statement in the context of the question.

mTLS does not inherently increase the symmetric encryption strength; cipher-suite strength is independent of whether one-way or two-way authentication is used. A hardware security module can be useful for protecting keys but is not mandatory for mTLS. Finally, mTLS authenticates certificate-bearing client identities, not necessarily individual application end users or their business authorization.

Reference topics: TLS; mutual TLS; two-way authentication; keystore; truststore; client certificate authentication.

Official documentation: https://docs.mulesoft.com/mule-runtime/4.3/tls-configuration

===============================================================

Mule Gateway source policies behave as nested interceptors around the application flow. Policy order determines the sequence in which the request-side portions execute. Because Policy A has order 1 and Policy B has order 2, Policy A is entered first. Therefore, A1 executes before Mule reaches Policy A's http-policy:execute-next.

The execute-next instruction transfers control to the next policy, so Policy B begins and executes B1. Policy B's own execute-next then transfers control into the application flow, where F1 executes.

After the application flow completes, processing unwinds in reverse order. Control first returns to Policy B, causing B2 to execute. It then returns to Policy A, where A2 executes. The complete sequence is therefore A1 → B1 → F1 → B2 → A2.

MuleSoft's Custom Policy Development Reference documents this exact execution model, including an example with policies A and B using precisely the same order and execute-next arrangement. The policy with the lower order executes its inbound section first, while post-processing executes in reverse nesting order.

Reference topics: Mule Gateway Custom Policies; Source Policy Execution; http-policy:execute-next; Policy Ordering.

Official documentation: https://docs.mulesoft.com/mule-gateway/policies-custom-mule-4-reference

===============================================================

Object Store v2 is suitable for distributed key/value state that must be available across CloudHub executions and replicas, but it should not be used to hold the complete contents of files larger than its per-value limit. MuleSoft documents that an Object Store v2 value is limited to 10 MB, while the overall store does not have a fixed aggregate size limit.

The appropriate architecture is therefore to persist the binary file itself in storage designed for large objects—for example, a durable external object/blob storage service—and store only lightweight metadata in Object Store v2. That metadata can include the object's storage key, URI/location, status, or other lookup information. Subsequent flow executions can query Object Store v2 to determine whether the object exists and then retrieve the actual file from the external storage system.

An in-memory Object Store is inappropriate because application replicas do not provide a durable shared in-memory persistence model for this requirement. Storing the entire file directly in Object Store violates the 10 MB value constraint. Local file-based storage is also unsuitable as a cross-replica CloudHub persistence mechanism.

Reference topics: Object Store v2 limits; CloudHub replicas; distributed persistence; external object storage; key/location metadata.

Official documentation: https://docs.mulesoft.com/object-store/osv2-faq

===============================================================

Maven's default lifecycle defines a deterministic sequence of lifecycle phases. When a later lifecycle phase is requested, Maven executes the preceding phases in their established order. For the phases represented in the question, the correct sequence is:

validate → initialize → compile → test → package → verify → install → deploy

The validate phase checks that the project is correctly structured and required project information is available. initialize prepares build state. compile compiles project source code, and test runs tests against the compiled code. package creates the distributable artifact—in a Mule application, typically the deployable Mule application package.

The verify phase performs checks needed to validate package quality. install places the built artifact into the local Maven repository, making it available to other local projects. Finally, deploy copies the final artifact to a remote repository or participates in the configured deployment process.

This ordering matters in MuleSoft CI/CD pipelines because Mule Maven Plugin goals are integrated into Maven's lifecycle rather than replacing Maven's lifecycle semantics. Moving test, verify, or install outside their established positions would represent an invalid lifecycle sequence.

Therefore, C is the correct sequence.

Reference topics: Maven default lifecycle; Mule Maven builds; CI/CD; package, verify, install, and deploy phases.

===============================================================

The Insecure setting belongs to Mule's TLS truststore configuration. MuleSoft defines the insecure property as a Boolean that determines whether truststore validation is performed. When insecure="true", Mule stops performing certificate validation.

For an HTTP Listener operating as the TLS server, the truststore is used when validating certificates supplied by connecting clients. Therefore, disabling truststore validation means the listener does not enforce normal trust verification against the configured certificate authorities; effectively, certificates presented by HTTP clients are trusted without the standard certificate-chain validation represented by the truststore. This corresponds to option A.

Selecting Insecure does not convert HTTPS into plain HTTP, so option B is incorrect. It also does not itself enable mutual TLS. Full mutual TLS requires appropriate server key material and client-certificate authentication/trust configuration. Likewise, "Insecure" specifically concerns certificate validation; it should not be interpreted as a generic instruction to bypass every possible authentication mechanism applied to the API.

MuleSoft explicitly warns that this option creates a security vulnerability and is appropriate only for development or prototyping, not production.

Reference topics: TLS Context; Truststore; insecure; client-certificate validation; mutual TLS.

Official documentation: https://docs.mulesoft.com/mule-runtime/4.11/tls-configuration

===============================================================

Java keytool -importkeystore converts a keystore by explicitly defining both the source keystore and its format and the destination keystore and its required format. To convert JKS → PKCS12, the source must therefore be the JKS file with -srcstoretype JKS, while the destination must be the .p12 file with -deststoretype PKCS12.

MuleSoft provides the same conversion pattern in its TLS-related documentation. Its example for converting a JKS client keystore to P12 uses -srckeystore ...jks, -srcstoretype JKS, followed by -destkeystore ...p12 and -deststoretype PKCS12.

Mule supports JKS, PKCS12, and other keystore types for TLS configurations, but the configured file type must correspond correctly to the actual keystore encoding.

Option A reverses the declared store types even though the filenames suggest JKS-to-P12 conversion. Option C performs the opposite conversion, PKCS12 to JKS. Option D incorrectly identifies a .p12 source as JKS and does not correctly express the required source/destination relationship.

Thus, option B contains the correct source and destination formats.

Reference topics: TLS configuration; Java Keytool; JKS; PKCS12; keystore conversion.

Official documentation: https://docs.mulesoft.com/runtime-manager/rtm-agent-REST-connections

Official documentation: https://docs.mulesoft.com/mule-runtime/4.9/tls-configuration

===============================================================

Modules and connectors are extensions to the Mule runtime rather than ordinary Mule applications. Their tests therefore require the extension-oriented MUnit test infrastructure, represented by the MUnit Extensions Maven Plugin (munit-extensions-maven-plugin).

MuleSoft's XML SDK documentation shows that an XML SDK project includes MUnit tests under src/test/munit, and building the module runs those tests as part of the module build lifecycle. MuleSoft's connector-testing documentation explicitly references munit-extensions-maven-plugin when configuring tests for Mule extensions and modules.

The standard MUnit Maven Plugin is principally associated with executing MUnit suites for Mule applications in Maven/CI environments. XML SDK modules require testing in the extension/module context, which is why the extensions variant is the relevant plugin.

JUnit is a Java testing framework and does not by itself provide the Mule runtime and extension environment required to execute XML SDK module operations. XMLUnit, meanwhile, is designed for XML comparison and validation; it is not the Mule module-testing framework.

Therefore, the correct Maven component for unit testing XML SDK-created modules is the MUnit Extensions Maven Plugin.

Reference topics: XML SDK; MUnit; module testing; munit-extensions-maven-plugin; Mule extension build lifecycle.

Official documentation: https://docs.mulesoft.com/mule-sdk/latest/xml-sdk

Official documentation: https://docs.mulesoft.com/mule-sdk/latest/partner-connector-upgrade

===============================================================

API access requested by a client application is represented through a contract between that application and an API instance or API Group instance. When manual approval is required, the administrator must possess both the relevant contract configuration and sufficient API Manager authority.

MuleSoft's API Manager documentation identifies two prerequisites for manually approving or rejecting an access request. First, an SLA tier must be configured for the application. Second, the user performing the approval must be an Organization Administrator, an API Manager Environment Administrator, or possess the Manage Contracts permission.

The Manage Contracts permission specifically grants the ability to manage contracts and their associated tiers within the API Manager environment. Exchange Administrator permissions alone do not satisfy this API Manager contract-management requirement.

The SLA component is also significant. API Manager contracts can govern access based on an SLA tier, allowing the API owner to determine permitted consumption levels and whether approval is automatic or manual.

Option C therefore contains the complete combination required by the platform: the application's SLA tier configuration plus appropriate administrative or contract-management authority.

Reference topics: API Manager Contracts; Client Applications; SLA Tiers; Manage Contracts permission; API access approval.

Official documentation: https://docs.mulesoft.com/api-manager/latest/manage-client-apps-latest-task

Official documentation: https://docs.mulesoft.com/api-manager/latest/environment-permission-task

===============================================================

The requirement combines two architectural concerns: the downstream HTTP calls must execute concurrently, and completed remote operations must be reversible when another operation fails. Scatter-Gather is the appropriate Mule router for the concurrency requirement because it dispatches the event to multiple routes and executes those routes in parallel.

However, independent HTTP APIs cannot generally participate in a single ACID/XA transaction with Mule. Once a remote API successfully commits an operation, Mule cannot simply perform a conventional transaction rollback across that service boundary. The appropriate distributed-transaction pattern is therefore a Saga, where successful steps have defined compensating operations that semantically undo their effects when a subsequent step fails.

Scatter-Gather also provides a composite error model. If one or more routes fail, Mule collects successful route results and route failures into a MULE:COMPOSITE_ROUTING error. A centralized orchestration/error-handling flow can inspect those results and execute compensation logic in the required sequence.

Parallel For Each is designed for elements of a collection, not orchestration of several distinct API operations. VM queues and transactional-outbox patterns address different reliability concerns and do not directly implement distributed compensation.

Reference topics: Scatter-Gather Router; Composite Routing Errors; Distributed Transactions; Compensating/Saga Pattern.

Official documentation: https://docs.mulesoft.com/mule-runtime/4.3/scatter-gather-concept

===============================================================

Anypoint MQ implements publish/subscribe fan-out by publishing a message to a message exchange and binding multiple queues to that exchange. Each subscribing application consumes from its own queue. As a result, a single gate-change event published by the Flight Management System can be copied to the Baggage Handler, Inflight Catering, and Passenger Notification queues independently.

MuleSoft documents that messages sent to an exchange are delivered to its bound queues and specifically describes exchanges as the mechanism for distributing one published message to multiple applications. A consumer does not directly consume from the exchange; consumption occurs from a queue. In fact, MuleSoft states that attempts to consume from a message exchange are rejected because the destination for consumption must be a queue.

Having all systems consume from one queue would instead create competing consumers: individual messages would normally be processed by one consumer rather than independently delivered to every subscribing system.

The required architecture is therefore: publisher → exchange → multiple bound queues → independent subscribers. This supplies asynchronous fan-out while preserving subscriber isolation and independent consumption.

Reference topics: Anypoint MQ exchanges; queue bindings; publish/subscribe; asynchronous event distribution.

Official documentation: https://docs.mulesoft.com/mq/

Official documentation: https://docs.mulesoft.com/mq/mq-exchanges

===============================================================

The three validation operations are nested inside a validation:all scope. The defining behavior of this scope is that it executes every nested validation even if one or more earlier validations fail. Consequently, an invalid email does not immediately terminate validation processing. Mule continues to evaluate the appointment-date regular expression and the customer-name null check.

MuleSoft explicitly documents that all validations inside the All scope are executed even if all of them fail. If one or more nested validations fail, the All validator produces a consolidated VALIDATION:MULTIPLE error describing the failures rather than simply throwing the first or final validation error.

The flow does contain error mappings for individual validators—for example mapping VALIDATION:INVALID_EMAIL to SCHEDULE:INVALID_EMAIL_ADDRESS. However, those mappings do not change the central behavioral point being tested: the All scope evaluates the entire set rather than short-circuiting after the first failed validator.

Thus, if the email address is invalid, the remaining appointment-date and customer-name validations are still evaluated. This makes C the only option accurately describing the scope's execution behavior.

Reference topics: Validation Module; validation:all; validation aggregation; VALIDATION:MULTIPLE; error mappings.

Official documentation: https://docs.mulesoft.com/validation-connector/latest/validation-examples

===============================================================

A production health endpoint should verify the same network path and HTTP infrastructure that clients depend on. Reusing the API's existing HTTP Listener configuration and port ensures that the health check validates whether the application's actual inbound listener is operational. Mule HTTP Listener configurations define the host, port, protocol, TLS configuration, and potentially a common base path; multiple listener sources can use the same configuration while exposing different paths.

A separate listener and port could report healthy even when the primary API listener is unavailable or incorrectly configured, producing a misleading health signal. Sending health information outward to another system is telemetry rather than an endpoint-level availability test. Likewise, exercising a payment API with genuine customer payment data is inappropriate because monitoring should be non-destructive and should not create business transactions.

Therefore, a lightweight endpoint such as /health using the same listener configuration provides a representative indication that the application can receive traffic through its normal production interface without invoking payment-processing behavior.

Reference topics: Mule HTTP Listener configuration; production health checks; API availability monitoring; non-invasive operational endpoints.

Official documentation: https://docs.mulesoft.com/http-connector/latest/http-listener-ref

===============================================================

Major API versions should be distinguishable at the API's external URI rather than being encoded independently into every resource operation or into internal Mule flow names. MuleSoft recommends including the consumer-facing API version in the application URL, for example /v1/..., so clients can explicitly select the major API contract they intend to consume.

RAML supports this cleanly through the baseUri. A version variable can be included in the base URI, for example baseUri: https://api.example.com/v{version}, with the corresponding version or base URI parameter defined in the specification. This keeps the versioning concern at the API contract and endpoint-addressing level.

Changing every operation would unnecessarily duplicate version information. Modifying generated APIkit flow names affects Mule implementation internals but does not provide distinct public API addresses. Similarly, manually changing generated HTTP listeners after scaffolding makes the implementation diverge from the API specification and weakens API-led lifecycle management.

MuleSoft's versioning guidance explicitly recommends exposing the major version in the API URL and using simple major identifiers such as v1, v2, and so forth.

Reference topics: API Versioning; RAML baseUri; Base URI Parameters; Major API Versions.

Official documentation: https://docs.mulesoft.com/exchange/to-change-raml-version

===============================================================