MuleSoft Certified Developer (MCD) - Level 2 Exam Questions 2026
MuleSoft Certified Developer (MCD) - Level 2 Exam Questions 2026
Visit Official SkillCertPro Website :-
For a full set of 57 questions. Go to
https://skillcertpro.com/product/mulesoft-certified-developer-mcd-level-2-exam-questions/
SkillCertPro offers detailed explanations to each question which helps to understand the concepts better.
It is recommended to score above 85% in SkillCertPro exams before attempting a real exam.
SkillCertPro updates exam questions every 2 weeks.
You will get life time access and life time free updates
SkillCertPro assures 100% pass guarantee in first attempt.
Question 1:
Mule API uses Until Successful scope with an external REST-based API invocations to retry failed API calls. Try scope is used inside Until Successful to distinguish transient HTTP error types from permanent ones – and NOT to retry the latter.
Which HTTP error type are considered permanent and as such it should NOT be automatically retried?
A. 502 Bad Gateway
B. 408 Request Timeout
C. 403 Forbidden
D. 429 Too Many Requests
Answer: C
Explanation:
502 Bad Gateway
Definition:
The 502 (Bad Gateway) status code indicates that the server, while acting as a gateway or proxy, received an invalid response from a downstream server it accessed while attempting to fulfill the request.
Common Causes:
Temporary downtime of the downstream server
Network failure
Upstream service issues
Retry Behavior:
It’s OK to retry the request with the same parameters after some time.
Conclusion:
HTTP 502 is not permanent → the original answer is incorrect.
General Comment
HTTP response codes in the 5xx range should always be expected to signify a transient failure.
408 Request Timeout
Definition:
The 408 (Request Timeout) status code indicates that the server did not receive a complete request message within the time it was prepared to wait.
Retry Behavior:
Usually temporary. The client may repeat the request.
Conclusion:
HTTP 408 is not permanent → the original answer is incorrect.
429 Too Many Requests
Definition:
The 429 (Too Many Requests) status code indicates the user has sent too many requests in a given amount of time (rate limiting).
Retry Behavior:
It’s OK to retry the request with the same parameters after some time, as limits may reset.
Conclusion:
HTTP 429 is not permanent → the original answer is incorrect.
403 Forbidden
Definition:
The 403 (Forbidden) status code indicates that the server understands the request but refuses to authorize it. If authentication credentials were provided, the server considers them insufficient to grant access.
Retry Behavior:
The client should not automatically repeat the request with the same credentials.
Conclusion:
HTTP 403 is considered permanent → the original answer is correct.
References
Error codes (RFC 9110):
https://www.rfc-editor.org/rfc/rfc9110.html#name-status-codes
HTTP 429 documentation (MDN):
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429
Question 2:
Mule API is configured with and protected by OAuth 2.0 Access Token Enforcement policy in API Manager. API administrator wants to configure the policy for token generation.
Which of the following statements is true?
A.Open the policy config panel. Locate “Generate Token(s)“ checkbox and ensure it‘s selected
B. It‘s not possible because OAuth 2.0 Access Token Enforcement policy does not generate tokens. It only validates them.
C. Token generation feature is available for the Platinum license ONLY and is enabled by default - no action needed. For other licenses it‘s not available.
D. Open the policy config panel. Locate “Access Token validation endpoint url“ parameter and add “&generateToken=true“ to the URL.
Answer: B
Explanation:
The idea of OAuth 2.0 Access Token Enforcement policy is to restrict access to a protected resource to only those HTTP(S) requests that provide a valid OAuth 2 token. The policy cannot generate tokens. It only validates them.
Adding “&generateToken=true“ to validation endpoint URL is pointless. “Generate Token(s)“ checkbox doesn‘t exists. Platinum license doesn‘t change anything with regard to token generation – it‘s still not available.
The only correct answer is “OAuth 2.0 Access Token Enforcement policy does not generate tokens. It only validates them“
Reference: https://docs.mulesoft.com/policies/policies-included-oauth-access-token-enforcement
Question 3:
A technical design requires two different Mule applications to exchange VM messages (inter-app communication) in clustered environment. VM connector is expected to distribute load across a cluster.
What conditions need to be met to make the communication working? Choose TWO answers.
A. Shared VM queues have to be TRANSIENT
B. Shared VM queues have to be PERSISTENT
C. Each application can define its own VM queues but the queue names MUST be the same
D. Both applications have to be in the same domain
Answer: B and D
Explanation:
Sharing VM Queues Across Mule Applications (Mule 4)
Both Applications Must Be in the Same Domain
Explanation:
To share VM configuration, both applications must belong to the same domain project.
The shared VM configuration must be defined in the domain’s mule-domain-config.xml.
Reference Topics:
Shared Resources Configuration
VM Connector – Send Messages Across Different Apps (Mule 4)
Conclusion:
✅ This answer is correct.
Each Application Defines Its Own VM Queue (Same Name)
Explanation:
This is incorrect.
Simply using the same queue name in different application configs is not enough.
Correct Approach:
Define one shared VM configuration in the domain project (mule-domain-config.xml)
Associate both applications with the same domain
Conclusion:
❌ This answer is incorrect.
Shared VM Queues Must Be PERSISTENT
Explanation:
To exchange messages between Mule runtimes in a clustered environment, VM queues must be persistent.
Persistence is backed by an in-memory grid.
When a new message is sent to the VM queue:
The cluster selects which node receives it
This enables load balancing across nodes
Conclusion:
✅ This answer is correct.
Shared VM Queues Must Be TRANSIENT
Explanation:
Transient queues are not designed for clustered environments and cannot be used to reliably exchange messages across runtimes.
Conclusion:
❌ This answer is incorrect.
References
VM Connector – Publish Across Apps:
https://docs.mulesoft.com/vm-connector/2.0/vm-publish-across-apps
Define Shared Resources:
https://docs.mulesoft.com/mule-runtime/4.4/shared-resources#define-shared-resources
HA Clusters – Queues:
https://docs.mulesoft.com/mule-runtime/4.4/mule-high-availability-ha-clusters#queues
Question 4:
Order Experience API can notify its clients about order cancellations by performing a HTTP POST request to callback endpoint exposed by the API client. API client has to be notified about an order cancellation right after it happens. POST body is as follows (example):
123456
CLIENT_CANCEL
How is such a callback endpoint called?
A. Event streaming
B. Webhook
C. Polling
D. Back-pressure
Answer: B
Explanation:
Integration Patterns – Definitions & Correct Answer
Webhook
Definition:
A webhook is a unique URL exposed by the API client to receive information from an API provider (server) without polling.
The server automatically calls this URL (usually with a payload) when a specified event occurs
(e.g., order cancellation).
Polling
Definition:
Polling involves periodically making requests to a system to check for new events or data.
If new data is found or an event occurs, the response contains the new data in its payload.
Event Streaming
Definition:
Event streaming means a constant flow of data, where each message contains information about an event or a change of state.
Back Pressure
Definition:
Back pressure is a technique MuleSoft uses to handle high load when the Mule runtime doesn’t have enough resources to process incoming events.
Reference:
https://docs.mulesoft.com/mule-runtime/4.2/execution-engine#backpressure
Final Conclusion
The scenario described above clearly uses webhooks.
✅ Correct answer: Webhook
❌ Incorrect answers: Back Pressure, Event Streaming, Polling
Question 5:
An operation in XML SDK module can consist of:
A. Parameters, Body, Output, Exceptions
B. Parameters, Body, Output, Errors
C. Input, Body, Output, Errors
D. Properties, Body, Output, Errors
Answer: B
Explanation:
XML SDK Module – Operation Structure
An XML SDK module’s operation consists of the following sections:
1. Parameters
Declaration of types to be entered when the operation is called.
Parameters can have attributes such as:
name
defaultValue
type
role
etc.
2. Body
Similar to a Mule flow.
Contains a chain of components to be executed.
3. Output
Declaration of the module’s output type.
This defines the payload type after the body’s processing is finished.
4. Errors
Explicitly declares which errors the module can raise.
Notes
The list of operation sections ends here.
Properties are global configuration elements and apply to the entire module — not to a single operation.
Exceptions and Input are fictitious in this context.
Final Answer
✅ Correct answer:
Parameters, Body, Output, Errors
❌ Incorrect answers:
The other 3 options are incorrect.
Reference
XML SDK Basics:
https://docs.mulesoft.com/mule-sdk/1.1/xml-sdk#xml-sdk-basics
For a full set of 57 questions. Go to
https://skillcertpro.com/product/mulesoft-certified-developer-mcd-level-2-exam-questions/
SkillCertPro offers detailed explanations to each question which helps to understand the concepts better.
It is recommended to score above 85% in SkillCertPro exams before attempting a real exam.
SkillCertPro updates exam questions every 2 weeks.
You will get life time access and life time free updates
SkillCertPro assures 100% pass guarantee in first attempt.
Question 6:
What is possible when using Object Store v2 REST API?
Choose THREE valid answers
A. Remove object store
B. Store a Key-Value of any size
C. One app deployed to CloudHub can access the object store of another CloudHub app
D. Retrieve statistics on object store usage
Answer: A, C and D
Explanation:
Object Store v2 – Capabilities & Limitations
Remove Object Store
Description:
Object Store v2 REST API allows both key–value removal and entire store removal.
Example REST call:
DELETE https://{{HOST}}/api/v1/organizations/{organizationId}/environments/{environmentId}/stores/{storeId}
Reference:
See the Exchange portal (link in the References section below).
Conclusion:
✅ This answer is correct.
Retrieve Statistics on Object Store Usage
Description:
Object Store v2 Stats API enables retrieval of comprehensive statistics on Object Store usage.
These statistics can be useful for billing purposes.
Reference:
See the Object Store v2 REST APIs section (link in the References below).
Conclusion:
✅ This answer is correct.
Access Another CloudHub App’s Object Store
Description:
It is possible to configure Object Store access from one CloudHub app to another CloudHub app via REST API.
Best Practice Note:
For app-to-app communication, MuleSoft recommends using Anypoint MQ instead of Object Store v2, which was not designed for this purpose.
Conclusion:
Although not recommended, this option is possible to configure →
✅ The answer is correct.
Store a Key–Value of Any Size
Description:
Object Store v2 REST API allows storing key–value pairs, but not of any size.
Each value has a hard limit of 10 MB, which applies to both:
Object Store Connector
REST API
Conclusion:
❌ This answer is incorrect.
References
Object Store v2 APIs:
https://docs.mulesoft.com/object-store/osv2-apis
CloudHub app access to another app’s Object Store:
https://docs.mulesoft.com/object-store/osv2-faq#can-an-app-deployed-to-cloudhub-access-the-object-store-of-another-cloudhub-app
Object Store size limits:
https://docs.mulesoft.com/object-store/osv2-faq#what-are-the-limits-on-an-object-store
Exchange portal (Object Store v2):
https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/object-store-v2/
Question 7:
Which options are TRUE with regard to Object Stores?
Choose TWO answers
A. Object Store can be configured to support transactions (all-or-nothing)
B. Mule Runtime 4x supports both Object Store V1 and V2 - depending on configuration
C. By default all Mule apps can access Object Store which is persistent and can be used without specifying an objectStore attribute
D. Both GLOBAL Object Store and PRIVATE Object Store are supported
Answer: C and D
Explanation:
Mule Object Store – Key Concepts & Validations
Global and Private Object Stores Are Supported
An Object Store can be defined once as part of the global configuration and shared across multiple components.
Such a global Object Store can be referenced using the objectStore parameter.
Example (conceptual):
Global Object Store → reusable by multiple components
Private Object Store → created locally for a single component
Private Object Store Notes:
A private Object Store does not have a referable name, so it cannot be manipulated by other components.
Conclusion:
✅ This answer is correct.
Object Store Supports Transactions (All-or-Nothing)
Explanation:
Object Store does not support transactional access.
This is one of its known limitations.
Conclusion:
❌ This answer is incorrect.
Default Persistent Object Store Is Available to All Mule Apps
Explanation:
By default, each Mule app has an Object Store predefined.
It is:
Persistent
Available without any explicit configuration
Usable by operations such as store, retrieve, etc., without specifying the objectStore attribute
Local Persistence Location:
/.mule/<app-name>/objectstore/
Conclusion:
✅ This answer is correct.
Mule Runtime 4.x Supports Both Object Store V1 and V2
Explanation:
Object Store V1 is deprecated and should not be used for new projects.
Mule Runtime 4.x does not support Object Store V1 — only Object Store V2 is supported.
Conclusion:
❌ This answer is incorrect.
References
Object Store Connector:
https://docs.mulesoft.com/object-store-connector/1.2/
Defining a New Object Store:
https://docs.mulesoft.com/object-store-connector/1.2/object-store-to-define-a-new-os
Types of Object Stores Explained:
https://help.mulesoft.com/s/article/The-Different-Types-of-Object-Stores-Explained
Question 8:
MuleSoft-based API connects to a downstream system via HTTPS using self-signed certificate. Support team has been notified that the self-signed certificate of MuleSoft-based API will be no longer accepted by the downstream system. Only CA-signed certificates will be accepted. The team is asked to take appropriate action to ensure business continuity. What actions should be performed?
A. Locate keystore file used in TLS configuration. Send the keystore to CA for signing. Once the keystore is sent back - update TLS configuration
B. Ensure that “Insecure“ option is selected for the keystore. It will force the downstream system to accept the self-signed certificate
C. Export certificate to CSR file. Send the file to CA for signing. Import singed certificate to keystore.
D. Convert keystore file to PKCS12 as this format is always considered as trusted.
Answer: C
Explanation:
TLS / Keystore Configuration – Correct vs Incorrect Approaches
Ensure that “Insecure” Option Is Selected
Explanation:
This is incorrect.
The “Insecure” option applies to truststores, not keystores.
If enabled, the client accepts all server certificates (including self-signed ones) without validation, which is insecure and not what you want for proper TLS configuration.
Conclusion:
❌ This answer is incorrect.
Convert Keystore File to PKCS12 So It’s Always Trusted
Explanation:
Converting a keystore from one format to another does not solve trust issues.
If the certificate is not CA-signed, it still won’t be accepted by the downstream system.
Example conversion command (for reference):
keytool -importkeystore \
-srckeystore KEYSTORE.jks \
-destkeystore KEYSTORE.p12 \
-srcstoretype JKS \
-deststoretype PKCS12 \
-deststorepass PASSWORD_PKCS12
Conclusion:
❌ This answer is incorrect.
Send the Keystore to a CA for Signing
Explanation:
This is incorrect and unsafe.
Keystore files contain private keys, which must never leave the server.
Conclusion:
❌ This answer is incorrect.
Export Certificate to CSR, Send to CA, Import Signed Certificate Back
Explanation:
This is the standard and correct procedure for obtaining a CA-signed certificate:
1. Export a CSR (Certificate Signing Request) from the keystore
2. Send the CSR to the Certification Authority (CA)
3. Receive the signed certificate
4. Import the signed certificate back into the keystore
Conclusion:
✅ This answer is correct.
Reference
TLS Keystore Generation (Mule 4.4):
https://docs.mulesoft.com/mule-runtime/4.4/tls-configuration#keystore-generation
Question 9:
What are possible ways to change the Correlation ID of a Mule event?
Choose TWO correct answers:
A. Custom API policy with HTTP Policy Transform Extension
B. Tracing Module
C. Header Injection Policy
D. Correlation ID Generator
Answer: B and D
Explanation:
Ways to Modify the Mule Event Correlation ID
Tracing Module – “With CorrelationID” Scope
Explanation:
The “With CorrelationID” scope of the Tracing module enables modifying the correlation ID of the Mule event during the execution of that scope.
Conclusion:
✅ This answer is correct.
Correlation ID Generator
Explanation:
MuleSoft generates a new correlation ID (a random uuid() by default) when a new Mule event is created.
You can override this behavior and provide your own correlation ID value by configuring a Correlation ID Generator.
To do this:
Add the Correlation ID Generator component to your application
Set the correlationIdGeneratorExpression accordingly
Conclusion:
✅ This answer is correct.
Header Injection Policy
Explanation:
This policy allows adding new HTTP headers, but it does not change the Mule event’s correlation ID.
You can set a new X-CORRELATION-ID header to any value you want, but you will still see standard UUIDs as the Mule event correlation ID.
Why?
Because the Mule event is generated before the Header Injection Policy is applied.
Conclusion:
❌ This answer is incorrect.
Custom API Policy with HTTP Policy Transform Extension
Explanation:
Using a custom policy with the HTTP Policy Transform Extension, you can add:
HTTP request headers
HTTP response headers
However, this only affects HTTP headers, not the Mule event correlation ID itself.
This is the same limitation as the Header Injection Policy.
Conclusion:
❌ This answer is incorrect.
References
Modify the Correlation ID Generator:
https://docs.mulesoft.com/mule-runtime/4.4/correlation-id#modify-the-correlation-id-generator
Tracing Module – With CorrelationID:
https://docs.mulesoft.com/tracing-module/1.0/tracing-module-with-correlationid
Custom HTTP Transform Policies:
https://docs.mulesoft.com/gateway/1.1/policies-custom-http-transform
Correlation ID Enforcement Policy (GitHub):
https://github.com/mulesoft-catalyst/correlation-id-enforcement-policy
Header Injection Policy Not Setting Mule Correlation ID:
https://help.mulesoft.com/s/article/Header-Injection-policy-not-setting-Mule-corellationId-when-setting-x-correlation-id
Question 10:
Mule application has been deployed and now it operates on CloudHub 2.0. The app is configured via properties. One of the properties containing secret password to external Oracle database has been encrypted during deployment time.
The project manager asks the support team to retrieve the password value (in clear text) from the encrypted property because all other copies of this secret password have been accidentally lost. How can the support team retrieve the original value of this password property?
A. Go to Runtime Manager > Applications > Settings > Properties. Locate the protected property. Use “Restore Value“ option from the context menu to retrieve the original value.
B. It‘s not possible to retrieve the value of a property that has been protected in CH 2.0. Once protected it can‘t be viewed nor retrieved by any user
C. Go to Runtime Manager > Applications > Settings. Click the application name link to download JAR file. Original values of all properties including the protected ones can be found inside the JAR file.
D. Original values of protected properties can be retrieved using CloudHub 2.0 API and its endpoint:
E.GET /cloudhub/api/v2/applications/{applicationId}/properties
Answer: B
Explanation:
CloudHub 2.0 – Protected Application Properties
Restore a Protected Property Value via Runtime Manager
Claim:
Go to Runtime Manager → Applications → Settings → Properties, locate the protected property, and use the “Restore Value” option.
Reality:
There is no “Restore Value” context menu option for protected properties.
Protected values can only be:
Replaced using “Replace protected value…”, or
Deleted using “Delete property”.
Conclusion:
❌ This answer is incorrect.
Download the App JAR to Retrieve Protected Values
Claim:
Go to Runtime Manager → Applications → Settings, click the application name link to download the JAR file.
Reality:
Downloading the app JAR is possible, but the archive does not contain protected property values.
Conclusion:
❌ This answer is incorrect.
Retrieve Protected Values Using CloudHub 2.0 API
Claim:
Original values of protected properties can be retrieved using the CloudHub 2.0 API.
Reality:
The CloudHub 2.0 API does not provide any endpoint to retrieve properties of deployed apps.
Therefore, protected property values cannot be retrieved via API.
Conclusion:
❌ This answer is incorrect.
Protected Property Values Cannot Be Retrieved in CloudHub 2.0
Reality:
Once a property is marked as protected in CloudHub 2.0, its value:
❌ Cannot be viewed
❌ Cannot be retrieved by any user
✅ Can be replaced with another value
✅ Can be deleted
Conclusion:
✅ This is the only correct answer.
References
Protect App Properties (CloudHub 2.0):
https://docs.mulesoft.com/cloudhub-2/ch2-protect-app-props
CloudHub 2.0 API:
https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-20-api/
For a full set of 57 questions. Go to
https://skillcertpro.com/product/mulesoft-certified-developer-mcd-level-2-exam-questions/
SkillCertPro offers detailed explanations to each question which helps to understand the concepts better.
It is recommended to score above 85% in SkillCertPro exams before attempting a real exam.
SkillCertPro updates exam questions every 2 weeks.
You will get life time access and life time free updates
SkillCertPro assures 100% pass guarantee in first attempt.