Salesforce Mule-Dev-301 Salesforce Certified MuleSoft Developer II Exam Practice Test

When an API specification has already been published as an asset, Import a published API is the appropriate project-creation path because Anypoint Studio can resolve the published asset and its version and then use that specification to generate the Mule implementation skeleton.

APIkit scaffolding creates the implementation backbone from the selected specification, including the HTTP Listener entry flow, APIkit Router, console-related configuration, and operation-specific implementation flows. MuleSoft currently documents that Studio can scaffold APIs by importing a published API from Exchange/Maven, importing a local specification, or obtaining one from Design Center. However, the distinguishing requirement in this question is selecting the correct published API version. A published Exchange asset has explicit artifact/version coordinates, allowing the intended version to be selected rather than merely working from an unmanaged local RAML file.

Importing a local RAML can generate flows, but it does not inherently provide Exchange-based artifact/version selection. Likewise, "Generate a local RAML" is not the mechanism shown in the new-project API implementation interface.

Reference topics: APIkit for REST; API Scaffolding; Anypoint Exchange API assets; API version selection; Studio project creation.

Official documentation: https://docs.mulesoft.com/apikit/latest/apikit-4-scaffolding-reference

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

When Mule creates a new event, it needs a correlation ID so log entries and processing activity associated with that event can be traced together. Mule first checks whether the event source already provides a correlation ID. For an HTTP Listener, headers such as X-CORRELATION-ID or MULE_CORRELATION_ID can supply that identifier.

MuleSoft explicitly states that if the source message contains a correlation ID, Mule uses it; if the source does not provide one, Mule generates a unique correlation ID. Therefore, option C accurately describes HTTP Listener behavior.

Option B is incorrect because Mule does not unconditionally replace an incoming correlation ID. Option D is also incorrect: MuleSoft specifically documents that Anypoint MQ does not automatically propagate Mule correlationId between publisher and subscriber. If an identifier must traverse Anypoint MQ, it should be included as a user property and then reapplied or used by the receiving application.

Correlation IDs are central to production observability because they let operations teams connect log records and processing stages to the same business execution.

Reference topics: Mule correlation IDs; HTTP Listener; X-CORRELATION-ID; distributed tracing; event correlation.

Official documentation: https://docs.mulesoft.com/mule-runtime/latest/correlation-id

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

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

VM Connector supports both transient and persistent asynchronous queues, and their recovery behavior differs fundamentally. MuleSoft specifies that transient queues provide better performance but are not reliable when the runtime or host fails. Persistent queues are slower because their content must be persisted, but they provide recovery across failures.

For a standalone Mule runtime, persistent VM queues serialize and store queued message data on disk. Consequently, if the Mule runtime or underlying system stops before an in-flight queued message is consumed, the message can remain available and processing can resume after the runtime becomes operational again.

A transient queue stores its queued state in volatile runtime memory. A system failure destroys that state, so an unconsumed transient message cannot be assumed to survive restart.

Therefore, neither "all messages are lost" nor "all messages are recovered" accurately describes VM behavior; durability depends specifically on the queue type.

For workloads where asynchronous events must survive process or host failure in a supported standalone runtime architecture, a persistent VM queue is therefore the appropriate choice.

Reference topics: VM Connector; persistent queues; transient queues; asynchronous messaging; durability and recovery.

Official documentation: https://docs.mulesoft.com/vm-connector/latest/vm-reference

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

Correlation IDs are part of Mule event processing and provide the primary mechanism for tracing an execution across application components. Mule first examines the source message for a correlation identifier. For an HTTP Listener request, an incoming X-CORRELATION-ID or MULE_CORRELATION_ID header can establish the Mule event's correlation ID. If the source does not provide one, Mule generates a unique correlation ID for the event.

For the synchronous HTTP Listener scenario tested by the MuleSoft Developer II curriculum, the same correlation context is associated with the request-response execution, so no special API policy, scaffolding option, or Listener "CorrelationID" checkbox is required to satisfy the stated requirement.

Options B and C describe configuration controls that are not part of the normal HTTP Listener/APIkit scaffolding model. A custom correlation policy would only introduce unnecessary complexity where Mule's runtime correlation mechanism already handles the event correlation lifecycle.

The broader operational principle is important: correlation IDs should remain stable for the execution being traced so that request handling, logs, downstream processing, and the associated synchronous interaction can be related during production diagnostics.

Reference topics: Mule Event; Correlation ID; HTTP Listener; X-CORRELATION-ID; distributed tracing and observability.

Official documentation: https://docs.mulesoft.com/mule-runtime/latest/correlation-id

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

For the Mule 4 custom-policy development model represented by this question, the policy's runtime behavior is implemented in an XML template, while the policy's configurable parameters and metadata are described in a YAML configuration file.

The XML template uses Mule's XML configuration language and policy-specific elements such as http-policy:proxy, http-policy:source, http-policy:operation, and http-policy:execute-next. In this scenario, the developer can place the header-token inspection and validation behavior in this implementation layer. The accompanying YAML file exposes configurable policy parameters to API Manager and provides the metadata needed for policy configuration.

MuleSoft's custom-policy development reference identifies an XML template and YAML file as core policy project artifacts; the complete project additionally contains its POM, Mule artifact descriptor, and any optional resources.

A ZIP file is not the source artifact pair used to define the policy. Similarly, a generic JSON properties file is not a replacement for the implementation template in this Mule 4 custom-policy model.

Thus, among the available combinations, the XML policy template together with the YAML configuration file is the required pair.

Reference topics: Mule Gateway custom policies; XML policy templates; YAML policy configuration; HTTP Policy Transform Extension.

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

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

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

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

The flow passes the incoming HTTP request payload directly to the JSON Module's Validate schema operation. The referenced schema.json defines the age property as an integer with "minimum": 0. However, the request shown in the exhibit contains:

"age": -1

This violates the schema because -1 is below the permitted minimum. MuleSoft specifies that the JSON Module's Validate schema operation compares the input content with the supplied JSON Schema and, when the document does not conform, raises JSON:SCHEMA_NOT_HONOURED.

Consequently, normal flow execution stops at the validation operation unless an error handler explicitly consumes the exception. The Logger positioned after the validation operation is not executed in this flow because validation fails first.

The schema's description text—"Age in years which must be equal to or greater than zero."—is metadata describing the property; it does not automatically become a successful HTTP response. Similarly, the request payload is not returned through a successful normal path after the schema violation.

Therefore, because the supplied age value violates minimum: 0, Mule raises JSON:SCHEMA_NOT_HONOURED.

Reference topics: JSON Module; Validate Schema operation; JSON Schema constraints; minimum; JSON:SCHEMA_NOT_HONOURED.

Official documentation: https://docs.mulesoft.com/json-module/latest/json-schema-validation

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

Resource filtering is designed primarily for textual resources in which Maven substitutes property expressions. Binary files such as PKCS#12 keystores and certificate files must not be passed through text filtering because filtering can corrupt their binary representation.

The Maven Resources Plugin provides the dedicated configuration element nonFilteredFileExtensions. Each additional extension is declared using a nested nonFilteredFileExtension. The plugin documentation specifically defines this parameter as the list of additional file extensions to which filtering must not be applied.

Option C correctly uses the documented structure:

< nonFilteredFileExtensions >

< nonFilteredFileExtension > p12 < /nonFilteredFileExtension >

< nonFilteredFileExtension > crt < /nonFilteredFileExtension >

< nonFilteredFileExtension > pem < /nonFilteredFileExtension >

< /nonFilteredFileExtensions >

This is important because the application's normal resource configuration can still use < filtering > true < /filtering > for textual files while Maven leaves the listed certificate/keystore formats untouched.

The alternative constructs visible in the other exhibits, such as excludeFileExtensions or excludeBinaryFiles, are not the Maven Resources Plugin parameter used for this purpose.

Reference topics: Maven Resources Plugin; resource filtering; binary resources; nonFilteredFileExtensions; Mule Maven builds.

Official documentation: https://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html

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

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

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

A readiness endpoint answers a more specific question than whether the Mule process is merely running: is this application ready to service business traffic successfully? For a System API whose business functionality depends on MySQL, readiness requires both the API itself and its critical downstream dependency to be usable.

A dedicated readiness endpoint is preferable to reusing an existing business resource because monitoring must not generate business-side effects or depend on arbitrary resource semantics. The endpoint should perform lightweight checks that establish application readiness and verify reachability of required underlying systems such as the database.

Returning only the API's local status could produce a false-positive readiness result when the Mule application is running but MySQL is unreachable. Checking the server alone has the same weakness: infrastructure health does not establish business-service readiness. Modern Mule deployment environments likewise distinguish availability/readiness signals from simple process existence; readiness is intended to establish whether the deployed service is available for processing traffic.

Therefore, the most operationally meaningful design is a dedicated endpoint reporting the API's status together with connectivity to its essential underlying systems.

Reference topics: Readiness versus liveness; dependency health; System API monitoring; production operational endpoints.

Official documentation: https://docs.mulesoft.com/runtime-fabric/latest/deploy-mule-app-anypoint-controller

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

The RAML trait shown in the exhibit declares client_id and client_secret as headers and applies that trait to the /customers resource. Because these headers form part of the API contract, APIkit Router validates the inbound request against the specification before routing it to the generated implementation flow.

If the required request structure is not honored, APIkit raises an APIKIT:BAD_REQUEST error. MuleSoft's APIkit error-handling reference maps APIKIT:BAD_REQUEST directly to HTTP 400, and APIkit scaffolding generates the corresponding error-handling logic with httpStatus set to 400.

A 403 response would normally represent a request that was understood but rejected because of authorization. That is not what is happening here: the request fails API contract validation before successful routing because required request information is absent. A 500 indicates an internal server failure, which is also inappropriate for malformed client input.

Therefore, when the API Console submits the request without the required header values, the APIkit-generated implementation treats it as a bad request and returns HTTP 400.

Reference topics: APIkit Router validation; RAML traits; required headers; APIKIT:BAD_REQUEST; APIkit-generated error handling.

Official documentation: https://docs.mulesoft.com/apikit/latest/apikit-error-handling-reference

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

MuleSoft provides the JSON Module specifically for operations such as JSON validation. The application should include the JSON Module as a Mule dependency and place its Validate schema operation before the connector or operation that posts the data to the target system.

The Validate schema operation receives the JSON document and evaluates it against the configured JSON Schema. When validation succeeds, processing continues to the next processor. If the payload does not conform, Mule raises JSON:SCHEMA_NOT_HONOURED, allowing the flow's error-handling strategy to reject or transform the invalid request before the target system is modified.

MuleSoft also documents that modules/connectors added manually to an application are declared in pom.xml as dependencies with the mule-plugin classifier; the JSON Module follows this standard pattern.

DataWeave conditional validation would unnecessarily reimplement schema semantics and would not automatically interpret a JSON Schema. API Manager does not provide the application-level JSON Module operation described by this requirement, and import json-module is not a valid mechanism for invoking the Mule JSON Module from DataWeave.

Reference topics: JSON Module; Validate Schema; JSON Schema; JSON:SCHEMA_NOT_HONOURED; Maven module dependency.

Official documentation: https://docs.mulesoft.com/json-module/latest/json-schema-validation

Official documentation: https://docs.mulesoft.com/json-module/latest/json-xml-maven

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

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

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

The relevant property is the HTTP semantics of PUT. PUT is designed to be idempotent: repeating the same request against the same resource should establish the same intended resource state rather than repeatedly creating additional side effects. This characteristic makes PUT appropriate when an Until Successful scope might retransmit an operation following a transient failure.

For example, the downstream system might process the initial PUT successfully but the Mule application might experience a network error before receiving the response. Until Successful could therefore invoke the same PUT again. Provided the upstream APIs correctly implement standard PUT semantics, repeating the same modification produces the intended final state rather than duplicating the operation.

Changing PUT to POST would generally make the design less suitable because POST is not inherently idempotent. Executing the operations sequentially changes concurrency but does not itself establish idempotency. Compensating transactions address distributed rollback and consistency when independent operations partially succeed; they are a different reliability concern from idempotent retry behavior.

MuleSoft documents Until Successful as retrying the contained processors until they succeed or retries are exhausted.

Therefore, under the REST/HTTP semantics assumed by the question, no additional Mule processing is required.

Reference topics: Until Successful; idempotent operations; HTTP PUT semantics; reliable retries; Scatter-Gather.

Official documentation: https://docs.mulesoft.com/mule-runtime/latest/until-successful-scope

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

Option C is directly supported by the MuleSoft XML SDK documentation. MuleSoft defines an XML SDK property as a field supplied by an end user of the component that operates at the module configuration level. Unlike an operation parameter, which applies to one operation invocation, properties configure the XML SDK component across the Mule project in which that configuration is used.

The other choices conflict with documented XML SDK behavior. XML SDK operations do not support recursive calls, so A is false. XML SDK provides outbound operations but does not provide inbound message sources such as schedulers, making B false.

Option D also requires correction. Current XML SDK versions support a visibility setting with values including PUBLIC and PRIVATE; the default is public, but operations are not universally required to remain public. MuleSoft's current XML SDK reference explicitly documents private operation visibility.

Therefore, C is the technically correct and directly documented statement. This is one question where the option selected in the supplied source should not be accepted without verification.

Reference topics: XML SDK Properties; Operations; module configuration; operation visibility; XML SDK limitations.

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

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

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

Secure property management should isolate development, test, staging, and production environments rather than allowing secrets from one environment to provide access to another. MuleSoft's Secure Configuration Properties model supports this by using environment-specific property files—for example dev.secure.yaml, sandbox.secure.yaml, and prod.secure.yaml—and resolving the appropriate file through an environment property.

Sensitive values such as passwords, API credentials, and private service configuration should therefore be environment-specific. Production credentials should not normally be reused in development or testing. The encryption key used to protect those values should likewise be independently managed rather than shared broadly across security boundaries. This limits the impact if a non-production key or properties file is exposed.

The Secure Properties Tool encrypts the sensitive values using a supplied key, while the Mule runtime receives the corresponding decryption key separately at deployment/runtime. MuleSoft also emphasizes protecting that key rather than embedding it directly in application configuration.

Accordingly, the Developer II security model represented by this question expects both different sensitive property values and different encryption keys across environments.

Reference topics: Secure Configuration Properties; environment-specific secure files; encryption keys; secret isolation; deployment security.

Official documentation: https://docs.mulesoft.com/anypoint-code-builder/int-create-secure-configs

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

This answer requires an important correction to the selection shown in the supplied material. MuleSoft's current Anypoint MQ documentation explicitly states that Anypoint MQ does not propagate Mule correlationId from publisher to subscriber in the same way that APIs propagate correlation IDs between layers. MuleSoft instructs developers to place the required identifier in an Anypoint MQ user property and consume that value in the receiving application.

Therefore, the publishing application should include the original orderId as a custom message property. When another Mule application consumes the MQ message, it extracts that property and establishes the appropriate correlation context for its processing. The Tracing Module's With CorrelationID scope can then be used within that receiving application if the event correlation ID needs to be changed to the supplied order ID. MuleSoft confirms that With CorrelationID temporarily modifies the Mule event's correlation ID for processors inside the scope.

Wrapping only the publisher in With CorrelationID does not make Anypoint MQ transport that Mule event correlation ID automatically. Option D is explicitly contradicted by MuleSoft's MQ documentation.

Reference topics: Anypoint MQ user properties; correlation propagation; Tracing Module; With CorrelationID; distributed observability.

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

Official documentation: https://docs.mulesoft.com/tracing-module/1.0/tracing-module-with-correlationid

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

A TLS cipher suite defines the cryptographic algorithms that the communicating parties use to protect the connection. During TLS negotiation, the client advertises cipher suites that it supports and the server selects a mutually supported suite according to the protocol version and its security configuration.

In TLS 1.2 and earlier, a cipher-suite name can identify several cryptographic components, including key-exchange/authentication mechanisms, the symmetric encryption algorithm, and integrity protection. TLS 1.3 expresses cipher suites differently, but the negotiated suite still determines the authenticated-encryption algorithm used to protect application traffic. MuleSoft's TLS documentation exposes cipher-suite configuration directly, including suites based on AES-GCM and ChaCha20-Poly1305.

The TLS protocol version is negotiated as part of the broader handshake but is conceptually distinct from choosing a cipher suite. Likewise, a public-key format is not what the cipher-suite exchange fundamentally selects, and "a protocol" is too general.

Among the provided choices, an encryption algorithm is therefore the technically correct description of what the cipher-suite negotiation establishes for protecting the session.

Reference topics: TLS handshake; cipher suites; symmetric encryption; AES-GCM; mTLS cryptographic negotiation.

Official documentation: https://docs.mulesoft.com/anypoint-security/cipher-suites

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