Mule-Dev-301 Salesforce Certified MuleSoft Developer II Questions and Answers

API Functional Monitoring permits a monitor to contain tests against one or more endpoints, including endpoints belonging to multiple public APIs. A schedule determines where and how frequently the monitor executes. Consequently, there is no technical requirement to create ten independent schedules simply because ten APIs have individual health endpoints.

Because all ten APIs are public and accessible from the internet, a public location is sufficient. A private location is primarily useful when the monitored endpoints are accessible only through a private network or when specific private-network connectivity requirements exist. Creating a private location would introduce unnecessary deployment and operational overhead in this scenario.

The most efficient design is therefore to place the ten health checks in a single monitor/test suite and associate that monitor with one schedule running from one public location. MuleSoft documentation explicitly shows that a single monitor can test endpoints belonging to multiple public APIs, while a single schedule is associated with a location and execution interval. This reduces schedule consumption and management complexity.

Reference topics: API Functional Monitoring; Public Locations; Monitor Tests and Schedules; Monitoring Public APIs.

Official documentation: https://docs.mulesoft.com/api-functional-monitoring/afm-monitoring-public-apis

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

The HTTP Request connector is operating as a TLS client when it connects to the target HTTPS API. During the TLS handshake, the server presents its certificate chain. The client must be able to establish a chain of trust from that certificate to a trusted certificate authority.

When no custom Mule truststore is configured, Mule relies on the default Java/JRE truststore. MuleSoft explicitly states that if a tls:trust-store is not specified, Mule uses Java's default truststore, which normally contains certificates for major public certificate authorities.

Therefore, the target API connection succeeds when the issuing CA can be validated through that JRE truststore, assuming the remainder of the TLS negotiation is valid. A keystore serves a different purpose: it normally contains a private key and certificate used to establish the local party's own identity. It is not the default repository used to establish trust in remote HTTPS servers.

The connection also does not automatically trust every CA. Certificate validation still occurs unless validation is explicitly disabled.

Therefore, B correctly describes Mule's behavior when the HTTP Request configuration has no custom TLS truststore configured.

Reference topics: HTTP Request Connector; TLS client validation; Java default truststore; CA certificate chains; keystore versus truststore.

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

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

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/

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

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

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

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

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

Policy ordering is critical when HTTP Caching is combined with security policies. Here, HTTP Caching is placed before OAuth. When a matching cached entry exists, the caching policy can satisfy the request immediately rather than allowing that request to continue toward the API implementation.

MuleSoft explicitly documents that policies positioned after the HTTP Caching policy are not applied to responses served from the cache. On a cache hit, HTTP Caching finds the stored response and prevents the request from progressing through the remaining downstream policy chain toward the backend.

Because OAuth is configured after caching in this scenario, OAuth is consequently bypassed for a cache hit. This ordering has a significant security implication: authentication or authorization policies that must apply even to cached responses should be placed before the caching policy.

On a cache miss, by contrast, the request proceeds through the remaining policies, including OAuth, reaches the implementation, and the successful response can subsequently be cached.

Therefore, with the exact order stated in the question, a cache hit causes the HTTP Caching policy to return the cached response without executing the OAuth policy.

Reference topics: HTTP Caching Policy; API policy ordering; cache hit versus cache miss; security-policy placement.

Official documentation: https://docs.mulesoft.com/mule-gateway/policies-included-http-caching

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

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

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

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

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

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

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

PGP uses asymmetric cryptography for establishing confidentiality between a sender and a recipient. When the Mule application sends encrypted information to the backend service, it encrypts the content using the recipient's public key. Only the corresponding private key, retained by the backend recipient, can subsequently be used to decrypt that content.

MuleSoft's Cryptography Module documentation explicitly identifies the two principal PGP scenarios: outgoing encryption uses another party's public key, while incoming decryption uses the receiver's own private key. In a Mule application, the backend's public key is normally imported into a PGP public keyring, and the Cryptography Module's PGP Encrypt operation references the appropriate key or fingerprint.

The sender does not need the backend's private key. In fact, distributing the recipient's private key would defeat the fundamental security model of public-key cryptography. Both keys would be relevant for certain combined operations such as encryption plus signing, but ordinary encryption for confidentiality requires the recipient's public key. HTTPS/TLS may additionally protect transport, but it is separate from PGP payload encryption.

Reference topics: Cryptography Module; PGP Encryption; Public and Private Keyrings; PGP Encrypt Operation.

Official documentation: https://docs.mulesoft.com/cryptography-module/latest/cryptography-module-pgp

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

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

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

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

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

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

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

Mule's Cache scope is backed by a caching strategy, commonly using an Object Store. The caching strategy can directly configure expiration characteristics, including entry time to live (TTL). Once the TTL expires and the corresponding expiration processing occurs, cached entries are removed according to the configured Object Store policy without requiring application-specific invalidation logic.

MuleSoft's cache strategy documentation shows that the Object Store used by a caching strategy can define values such as entryTtl, expirationInterval, and maximum entries. A Cache component can then reference that strategy and automatically use those expiration settings.

Write-through and write-behind describe cache/database synchronization strategies in which cache updates are coordinated with writes to an underlying persistent data source. Mule's standard Cache scope does not automatically implement those patterns as an invalidation mode. Notification-based invalidation would similarly require external notification logic or explicit Mule processing to identify and invalidate affected keys.

TTL requires no such custom invalidation workflow. The developer establishes the lifetime when configuring the caching Object Store, after which Mule manages expiration automatically.

Therefore, Time to live is the cache invalidation mechanism directly available through standard Cache scope configuration.

Reference topics: Cache Scope; Object Store Caching Strategy; entryTtl; expirationInterval; automatic cache expiration.

Official documentation: https://docs.mulesoft.com/mule-runtime/latest/cache-scope-strategy

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

Object Store Connector provides Mule operations for interacting with object stores associated with the application in which the connector executes. It is not the mechanism for one independently deployed CloudHub application to directly operate on another application's Object Store v2 data.

For cross-application administration and access, MuleSoft provides the Object Store v2 REST APIs. These APIs support listing object stores and keys, storing and retrieving key-value pairs, and explicitly deleting keys and their values. Calls are authenticated with an Anypoint Platform bearer token and address the required organization, environment, store, partition, and key. MuleSoft's documented DELETE operation removes a specified key-value pair from the targeted Object Store v2 partition.

The CloudHub REST API manages CloudHub resources and deployments rather than application Object Store entries. The CloudHub Connector likewise does not provide the direct cross-application Object Store v2 deletion capability described here.

Therefore, application B can invoke the Object Store v2 REST API, subject to appropriate authorization and identification of application A's relevant Object Store resources, to remove values from that store.

Reference topics: Object Store v2; Object Store v2 REST APIs; partitions and keys; DELETE operations; CloudHub persistence.

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

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