MuleSoft Certified Developer – Level 1 (Mule 4) Practice Exam
Prepare for the MCD – Level 1 (Mule 4) exam across everything it tests — building flows in Anypoint Studio, transforming data with DataWeave 2.0, connecting to databases, files, web services, and JMS, routing events, handling errors, and deploying to CloudHub — with objective-mapped questions, Learn-mode feedback, and a full timed Exam mode.
Start 24-hour free trial →MuleSoft Certified Developer – Level 1 exam at a glance
- Vendor
- MuleSoft (a Salesforce company)
- Exam code
- MCD – Level 1
- Certification
- MuleSoft Certified Developer – Level 1 (Mule 4)
- Level
- Developer (foundational; basic Mule 4 projects with guidance)
- Blueprint
- Mule 4 runtime with DataWeave 2.0; verify the current exam guide before scheduling
- Format
- 60 multiple-choice questions
- Duration
- 120 minutes
- Passing score
- 70%
- Delivery
- Online proctored, via MuleSoft’s certification provider
- Prerequisites
- None required. Hands-on Anypoint Studio and Anypoint Platform experience strongly recommended.
- Retake policy
- Up to 5 attempts with a 24-hour wait between each; purchase options include one free retake
- Validity
- Confirm current recertification requirements with MuleSoft; the credential tracks the Mule runtime version
Sources: MuleSoft Docs — Mule Runtime · MuleSoft Docs — DataWeave. Confirm the current exam guide, format, and policies with MuleSoft before scheduling.
About the MuleSoft Certified Developer – Level 1 certification
The MuleSoft Certified Developer – Level 1 (Mule 4) credential validates that a developer can design, build, test, debug, deploy, and manage basic APIs and integrations on Anypoint Platform, moving between the platform and Anypoint Studio. It is a foundational developer certification — MuleSoft describes a Level 1 developer as able to work on basic Mule 4 projects with guidance and supervision — so it rewards hands-on fluency with the everyday building blocks rather than architecture-level design.
Two areas dominate the day-to-day work the exam tests. DataWeave 2.0 shows up across nearly every part of the platform — mapping, filtering, and reducing data — so you need to write transformations fluently, not just recognize them. And error handling is a frequent source of tricky questions: know the difference between On Error Propagate and On Error Continue, and how Try scopes interact with flow-level handlers. MuleSoft is a Salesforce company, but the exam and its documentation live on mulesoft.com, not the core Salesforce docs. For the broader integration and platform context, see the Salesforce ecosystem guide.
MuleSoft Certified Developer – Level 1 objective areas
MuleSoft organizes the exam around the tasks a Level 1 developer performs across the Mule 4 lifecycle. MuleSoft does not publish reliable public per-objective percentage weights, so the areas below are described by scope rather than an invented split — treat DataWeave and error handling as the highest-yield study targets, since they recur throughout the exam.
Creating flows in Anypoint Studio; using the HTTP Listener, transformers, Logger, and core components; accessing and modifying the Mule event (payload, attributes, variables).
map, filter, reduce, and other core functions; custom data types and coercion; DataWeave variables, functions, and modules; format conversion such as JSON to XML.
Database (including parameterized SQL), File and FTP, SOAP web services via Web Service Consumer, and JMS publish/subscribe with the relevant connectors.
Choice and other routers; On Error Propagate vs. On Error Continue and the Mule Error object; and record processing with For Each and Batch Job scopes.
Designing APIs with RAML and APIkit routing; parameterizing apps with property placeholders; deploying to CloudHub; and securing APIs with API Manager policies.
Objective areas summarize the MCD – Level 1 knowledge areas from MuleSoft’s exam datasheet. Because MuleSoft does not publish stable public weight percentages, none are stated here rather than risk false precision. Source: MuleSoft Docs — Mule Runtime. Confirm the current objectives in MuleSoft’s exam guide before scheduling.
Who this exam is for
MuleSoft positions this credential for developers building basic Mule 4 integrations, typically with some guidance. It is a foundational, hands-on developer exam:
- Integration and MuleSoft developers building flows, transformations, and API implementations on Anypoint Platform day to day.
- Backend and API developers moving into integration work who need to prove Mule 4 and DataWeave fundamentals.
- Salesforce ecosystem developers extending into MuleSoft as the integration layer between Salesforce and external systems.
- Consultants and delivery engineers who want a recognized baseline before progressing to advanced MuleSoft credentials.
Once you have Level 1, the natural next steps are the MuleSoft Certified Developer II for deeper development, or the MuleSoft Platform Architect for architecture roles; if you are new to integration entirely, the MuleSoft Integration Foundations credential is a gentler on-ramp. For the developer and integration roles this certification supports, see our Career Hub.
What this MuleSoft Developer practice exam delivers
Learn mode
Get the correct answer, the explanation, and why each other choice is wrong — immediately after each question. Best for DataWeave and error handling, where the exam’s wording is deliberately close between plausible options.
Exam mode
60 questions, 120-minute timer — the real MCD – Level 1 format. Build the pacing you need for the lengthy, scenario-style question stems.
Scenario-based questions
Case-driven items that mirror real Mule 4 build decisions — which components a flow needs, which scope handles retries, how to isolate a unit test — matching how the exam actually asks.
Score by objective area
Results break down across building apps, DataWeave, connectors, routing/errors/records, and API/deployment — so practice tells you exactly what to revisit.
Sample MuleSoft Developer practice questions
Ten free questions across the MCD – Level 1 objective areas, with full explanations and source links to MuleSoft documentation. The complete bank is available with the 24-hour trial.
A Mule application must receive HTTP requests, transform the payload from JSON to XML, and send the result to a SOAP web service. Which components should the flow use?
- A Scheduler trigger, a Database connector, and an email send operation
- An HTTP Listener source, a Transform Message component with DataWeave for the JSON-to-XML conversion, and a Web Service Consumer connector for the SOAP call
- An FTP connector, a custom Java class, and a file write operation
- An APIkit Router, a Logger, and a VM connector
Show answer & explanation
Correct: B — HTTP Listener, Transform Message, Web Service Consumer. The HTTP Listener receives the request, the Transform Message component uses DataWeave to convert JSON to XML, and the Web Service Consumer connector calls the downstream SOAP service with the transformed payload.
Why not the others: FTP and file connectors (C) are for file-based work; Database connectors and the Scheduler/email combo (A) don’t match this HTTP-to-SOAP flow; the APIkit Router (D) is for spec-driven API routing, not simple flow construction.
Source: MuleSoft Docs — Mule Runtime → Further reading: PowerKram — MuleSoft Developer II →A developer needs a DataWeave transformation that converts an array of order objects into a single summary object holding the total order count and total revenue. Which approach fits?
- Write the transformation in XML configuration instead of DataWeave
- Use the reduce function on the input array to accumulate the count and revenue sum into one output object
- Embed a Java class inside DataWeave for the calculation
- Use the map function to transform each order individually
Show answer & explanation
Correct: B — The reduce function. reduce iterates over an array and accumulates values into a single result, so it can build a summary object with totalCount and totalRevenue — the canonical DataWeave aggregation pattern.
Why not the others: XML configuration (A) cannot express transformations; a Java class (C) adds needless complexity; map (D) transforms each element individually rather than aggregating.
Source: MuleSoft Docs — DataWeave reduce → Further reading: PowerKram — Salesforce ecosystem guide →A developer is using an API-first approach and needs to define the API specification before writing any implementation code. What tool and format should they use?
- Create a Word document describing the API endpoints
- Write the implementation first and generate the specification afterward
- Use Anypoint Design Center to author the spec in RAML or OAS, publish it to Anypoint Exchange, then scaffold the Mule project from the specification
- Define the API in a spreadsheet and share it with the team
Show answer & explanation
Correct: C — Design Center with RAML/OAS, published to Exchange. API-first design authors the spec in RAML or OAS in Anypoint Design Center, publishes it to Exchange for discoverability, and scaffolds the Mule project so the API structure is pre-built.
Why not the others: code-first (B) contradicts API-first; a Word document (A) or spreadsheet (D) is not a machine-readable specification you can scaffold from.
Source: MuleSoft Docs — Design Center → Further reading: PowerKram — Integration Architect →A Mule application calls an external REST API that occasionally returns 500 errors. It should retry the call up to 3 times with increasing delays before failing. What should the developer implement?
- A Try scope that catches the error and does nothing
- No handling — let the application crash
- An Until Successful scope around the HTTP request, with a maximum of 3 retries and an exponential backoff frequency
- Custom Java code to handle retries outside of Mule
Show answer & explanation
Correct: C — An Until Successful scope. Until Successful retries the enclosed operation based on a configurable maximum-retries and frequency (with backoff), handling transient errors like 500s without custom code.
Why not the others: a Try scope that does nothing (A) suppresses the error without recovery; letting it crash (B) causes data loss; custom Java (D) bypasses Mule’s built-in retry capability.
Source: MuleSoft Docs — Until Successful scope →An application deployed to CloudHub needs database connection strings that differ across development, staging, and production. How should the developer manage these environment-specific values?
- Store all connection strings in one shared global properties file
- Create a separate Mule project per environment
- Hardcode the production database URL in the application code
- Use property placeholders that reference environment-specific properties files or CloudHub properties, set per deployment environment
Show answer & explanation
Correct: D — Property placeholders per environment. Placeholders like ${db.url} resolve from properties files or CloudHub environment properties, and each environment overrides them — the configuration-separation principle that keeps one codebase deployable everywhere.
Why not the others: a single shared file (A) can’t distinguish environments; separate projects (B) multiply maintenance; hardcoding (C) is a security and flexibility problem.
Source: MuleSoft Docs — Configuring properties →A developer must write MUnit tests for a flow that calls an external payment API. The tests must run in CI/CD without the external API being available. Which MUnit approach fits?
- Write a separate Mule application that simulates the payment API
- Mock the HTTP request connector using MUnit’s mock-when processor, returning test payloads for success, error, and timeout scenarios
- Skip testing the flow because it depends on an external service
- Test only in a staging environment with the real payment API
Show answer & explanation
Correct: B — Mock the connector with mock-when. MUnit’s mock-when processor intercepts connector calls and returns defined payloads, isolating the unit under test from external dependencies so different mocks can cover success, error, and edge cases.
Why not the others: a separate simulator app (A) adds infrastructure for a built-in capability; skipping (C) leaves code uncovered; staging-only testing (D) slows CI/CD and still needs the live API.
Source: MuleSoft Docs — MUnit → Further reading: PowerKram — DevOps certification guide →A flow processes large CSV files of about 1 million records, and processing each record involves an external API call. What pattern handles this volume efficiently?
- Reduce the file to 1,000 records and discard the rest
- Use the Batch Job scope to process records in configurable batches with parallel threads, per-record error handling, and a completion phase for summary reporting
- Split the CSV into 1 million individual messages and run them through a For Each loop
- Process all records synchronously in a single flow execution
Show answer & explanation
Correct: B — The Batch Job scope. Batch Job is built for high-volume record processing: it splits input into configurable batches, runs them across parallel threads, handles per-record errors without stopping the batch, and reports on completion.
Why not the others: For Each (C) is synchronous and slow at this scale; synchronous single-flow processing (D) could take days; discarding records (A) fails the requirement.
Source: MuleSoft Docs — Batch processing →A developer needs to route incoming API requests to different flows based on the HTTP method and resource path defined in the API specification. Which component fits best?
- Separate HTTP Listeners for each method and path combination
- A custom Java router class
- A Choice router with a condition for each HTTP method
- The APIkit Router, which routes requests to the matching flow automatically from the RAML/OAS specification’s resources and methods
Show answer & explanation
Correct: D — The APIkit Router. APIkit generates flows from the API specification and routes each request to the flow matching its resource path and HTTP method — the standard approach for spec-driven, API-first Mule apps.
Why not the others: a Choice router (C) works but requires manual per-method configuration; separate listeners (A) are redundant; a custom Java router (B) bypasses the declarative routing framework.
Source: MuleSoft Docs — APIkit →A Mule application consumes messages from a JMS queue. If processing fails, the message should go to an error queue rather than being lost. Which error-handling configuration fits?
- Let failed messages disappear from the queue permanently
- Log the error and continue without preserving the failed message
- Use an On Error Continue or On Error Propagate handler that publishes the failed message to a dead-letter (error) queue before acknowledging or rolling back the original
- Disable error handling to simplify the flow
Show answer & explanation
Correct: C — Route the failure to a dead-letter queue. An error handler captures the failure and publishes the message to an error queue so it is preserved. On Error Continue acknowledges the original (removing it from the source); On Error Propagate rolls back (returning it for retry) — either way the message isn’t lost.
Why not the others: losing messages (A) breaks data integrity; logging without preserving (B) still loses the message; disabling handling (D) masks the problem.
Source: MuleSoft Docs — Error handling →A developer is building an API proxy in Anypoint API Manager that must enforce rate limiting, client ID enforcement, and IP whitelisting. How should these be configured?
- Apply API Manager policies to the proxy: a Rate Limiting policy for throttling, Client ID Enforcement for authentication, and an IP Whitelist policy for access control
- Configure firewall rules on the server hosting the Mule application
- Use a third-party API gateway instead of API Manager
- Implement custom code in each Mule application for the security checks
Show answer & explanation
Correct: A — Declarative API Manager policies. API Manager applies policies to a proxy without changing application code: Rate Limiting controls request volume, Client ID Enforcement validates credentials, and IP Whitelist restricts access by source IP.
Why not the others: firewall rules (B) are network-level, not API-level; a third-party gateway (C) forgoes the Anypoint integration; custom code per app (D) duplicates effort across applications.
Source: MuleSoft Docs — API Manager →Keep going: Learning & Career resources
MuleSoft development sits at the center of enterprise integration — and Level 1 opens onto developer, senior-developer, and architect tracks. Two PowerKram hubs back this exam.
Deep dive: exam format, objectives, study path, and next steps
Exam format and code
The MuleSoft Certified Developer – Level 1 (Mule 4) exam — code MCD – Level 1 — is 60 multiple-choice questions in 120 minutes, with a 70% passing score. You can take it up to five times with a 24-hour wait between attempts, and purchase options typically include one free retake. Note the naming: the credential is “MuleSoft Certified Developer – Level 1 (Mule 4),” not simply “Certified MuleSoft Developer.” MuleSoft is a Salesforce company, but the exam and documentation live on mulesoft.com. MuleSoft Mule Runtime docs →
What the objectives actually cover
MuleSoft’s datasheet lists a dozen knowledge areas that group into: building Mule applications and working with the Mule event; transforming data with DataWeave 2.0; connecting to databases, files, SOAP web services, and JMS; routing events and handling errors; processing records with For Each and Batch Job; and the API/deployment lifecycle (RAML, APIkit, property placeholders, CloudHub, API Manager policies). MuleSoft does not publish stable public weight percentages, so rather than chase an exact split, weight your study toward DataWeave and error handling, which appear throughout. DataWeave documentation →
DataWeave and error handling: the two make-or-break areas
DataWeave 2.0 appears in nearly every part of the exam, so practice map, filter, and reduce until you can write them without reaching for the docs, and know how to define variables, functions, and custom types. Error handling is the other frequent trap: be precise about On Error Propagate (rolls back, message returns to source) versus On Error Continue (acknowledges, message is consumed), and how Try scopes nest inside flow-level handlers. Getting these two right covers a large share of the question bank. Error-handling documentation →
Realistic study path
This is a hands-on exam, so pair reading with building: in Anypoint Studio, wire up a flow that connects a REST API, a database, and a file system with DataWeave transformations, then deploy it to CloudHub. Complete MuleSoft’s official Development Fundamentals (Mule 4) course, write a few MUnit tests with mocked connectors, and use objective-mapped practice to find weak areas before going back into the tool for those specific tasks. MuleSoft Integration Foundations on PowerKram →
Where Level 1 leads
Level 1 is the foundation of the MuleSoft developer track. From here, MuleSoft Certified Developer II deepens your development skills, while the Platform Architect and Integration Architect credentials move toward designing API-led architectures rather than implementing individual flows. Pairing Level 1 with broader Salesforce ecosystem knowledge is valuable, since MuleSoft is frequently the integration layer between Salesforce and external systems. MuleSoft Platform Architect on PowerKram →
Frequently asked questions
What is the exam code and official name?
The official name is “MuleSoft Certified Developer – Level 1 (Mule 4),” with the exam code MCD – Level 1. It is often shortened to “MuleSoft Developer” or “Certified MuleSoft Developer,” but the exact credential is the Level 1 (Mule 4) version. Confirm the current exam guide on MuleSoft’s site before scheduling.
How many questions is the exam, and what is the passing score?
The exam is 60 multiple-choice questions in 120 minutes, with a passing score of 70%. Question stems tend to be lengthy and scenario-based, so pacing matters — practicing under a timer is worthwhile.
Is this a Salesforce or a MuleSoft certification?
Both, in effect. MuleSoft is a Salesforce company, so the credential sits within the broader Salesforce ecosystem, but it is a MuleSoft exam and its documentation lives on mulesoft.com rather than the core Salesforce Help or Trailhead docs.
What are the most important topics to master?
DataWeave 2.0 and error handling. DataWeave appears across nearly every objective area, so you should be able to write map, filter, and reduce transformations fluently. For error handling, know the difference between On Error Propagate and On Error Continue and how Try scopes interact with flow-level handlers.
How many times can I retake the exam?
You can take the exam up to five times, with a 24-hour wait between attempts. Purchase options typically include one free retake; additional retakes are discounted. Verify the current retake and pricing policy with MuleSoft before booking.
Start your free 24-hour MuleSoft Developer practice trial
Full access to the question bank, both study modes, and score-by-objective feedback. No credit card required.
Start free trial →