New to this track? Our Salesforce Certified System Architect exam prep is the recommended first step. See our certification path to understand where this certification fits. The Salesforce Certified Platform Development Lifecycle and Deployment Architect exam weights System Design most heavily (15%), see the full breakdown, study tips, and practice questions below.
Free practice • No sign-up required
Independent study resource
Exam objectives and policies can change. Confirm current details with the certification issuer.
Check current objectives
Use the official exam guide as the source for current objectives and section weights.
Practice for learning
Use sample questions to review concepts and identify topics for further study.
Works on Any Device
Full practice experience on phone, tablet, or desktop
Free, No Sign-Up
Start practicing immediately, no account or email required
Salesforce Certified Platform Development Lifecycle and Deployment Architect – Complete 2026 Guide
This exam tests how you plan environments, manage releases and move changes safely from development to production using sandboxes, source control, packages and the Salesforce CLI. The exam is 60 scored questions in 105 minutes, with a 65% pass mark, weighted towards System Design (15%) and Building (14%).
Recommended Prerequisites
We recommend completing this certification first to prepare you better.
| Official exam name and code | Salesforce Certified Platform Development Lifecycle and Deployment Architect (Dev Lifecycle & Deployment) |
|---|---|
| Questions | 60 |
| Time allotted | 105 min |
| Passing score | 65% |
| Exam fee | $400 |
| Retake fee | $200 |
| Prerequisite certifications | Recommended preparation: Salesforce Certified System Architect |
| Study guide release | Summer '26 |
Salesforce Certified Platform Development Lifecycle and Deployment Architect Exam Weightage by Section
1. Application Lifecycle Management (8%)
8%2. Planning (13%)
13%3. System Design (15%)
15%4. Building (14%)
14%5. Deploying (14%)
14%6. Testing (13%)
13%7. Releasing (13%)
13%8. Operating (10%)
10%Exam Topics
Last updated:
Who is the Development Lifecycle and Deployment Architect exam for?
- DevOps Engineers: You run Salesforce deployments today and want to show you can design the whole pipeline, from sandbox to production.
- Release Managers: You plan releases across several teams and need to choose the right environments, tools and test steps.
- Platform Architects: This is one of the four exams you need for System Architect, alongside Platform Developer I, Integration Architect and Identity and Access Management Architect.
Exam Fees & Registration
Exam Fee
$400
One-time registration fee
Retake Fee
$200
If you need to retake the exam
Comparing certs? View all Salesforce exam fees in one place →
Certification Validity
Maintenance and renewal requirements vary. Check the issuer’s current credential page for requirements that apply to you.
How to Register
Check current Salesforce Certified Platform Development Lifecycle and Deployment Architect credential and registration details with the issuer.
View official credential detailsOfficial references: Use the issuer’s current materials to confirm exam objectives, format, and fees before booking.
Official sources: Salesforce exam pricing·Independent exam-prep resource; details may change.
Exam Tips
- 1CI/CD and Version Control is 30%. Know Git workflows, CI/CD pipelines, and deployment strategies.
- 2Understand release management: sandboxes, change sets, unlocked packages, source tracking.
- 3Know environments and metadata: what goes where, and governance.
- 4Be ready for "how would you deploy X?" and "what is the best approach?" questions.
Prerequisites
- •Application Architect
- •System Architect
- •DevOps and deployment experience
Focus Areas
- •Release Management
- •Environments and Metadata
- •CI/CD and Version Control
- •Governance
Study Strategy
Set up a CI/CD pipeline.
Practice deploying with different methods.
Understand governance and best practices for enterprise deployments.
Exam Format and First-Attempt Readiness
The Salesforce Certified Platform Development Lifecycle and Deployment Architect exam has 60 questions in 105 min, passing score 65%. Most Salesforce exams test scenario-based decisions. Focus on when to use each feature, not just terms.
- Study System Design and Building first, together they carry 29% of the exam.
- Do timed question sets. Build pacing and confidence.
- Review why wrong answers are wrong. It improves scenario reasoning.
- Book the exam once your mock scores are steady at 75%+.
Is the Development Lifecycle and Deployment Architect Exam Hard?
Is the Development Lifecycle and Deployment Architect Exam Hard?
It is a practical exam. You need to know the sandbox types and their refresh limits, what each deployment tool can and can't do, and how to recover when a production deployment goes wrong.
- 60 multiple-choice questions in 105 minutes.
- 65% to pass, which is 39 correct answers. Many questions turn on small differences between change sets, the Salesforce CLI and unlocked packages.
- Real-world problems. Expect questions on deleting metadata, deployment order and what to do when there is no built-in rollback.
- Pipeline design. You need to know how source control, scratch orgs and automated tests fit together in CI/CD.
Pass Rate Guidance
People who have run releases for a team do best. Before you book. Aim for 75% or more on practice tests and make sure you can draw an environment plan for a project with several teams.
Development Lifecycle and Deployment Architect Exam Format Explained
Development Lifecycle and Deployment Architect Exam Format Explained
You can take the exam online with a proctor or at a test centre. Here is what to expect:
Total Questions
60 scored questions
Time Limit
105 min
Passing Score
65%
Question Type
Multiple-choice & multiple-select
How Many Questions Are Scenario-Based?
Most questions are short scenarios about a team, a project or a failed release. You choose the right sandbox, tool or order of steps.
Best Way to Pass on Your First Attempt
- Learn the sandbox table: Developer, Developer Pro, Partial Copy and Full. Know how much data each holds and how often it can be refreshed.
- Know the limits of change sets: They can't delete metadata, only work between connected orgs, and leave no history in source control.
- Understand source-driven development: Version control is the source of truth, and orgs are built from it.
- Know the test rules: Production deployments with Apex need 75% overall code coverage, and you choose which tests run.
Development Lifecycle and Deployment Architect: Key Concepts
Org Strategy: Sandboxes and Scratch Orgs
Each sandbox type has a job. Developer sandboxes copy metadata only, hold 200 MB of data and can be refreshed every day. They suit one developer. Developer Pro is the same with 1 GB of data, which helps for bigger test data sets. Partial Copy includes metadata plus a sample of data chosen by a sandbox template, holds 5 GB and can be refreshed every 5 days. It suits QA and training. Full copies all data and metadata and can be refreshed every 29 days. It is the only safe place for performance testing and final user testing. Scratch orgs are short-lived orgs built from source and a definition file. They last up to 30 days and are used for package development and automated tests.
Version Control and Source-Driven Development
In source-driven development, the code in Git is the truth, not any one org. Developers pull from Git, work in a sandbox or scratch org, and push their changes back with the Salesforce CLI. A common branching model has a main branch that matches production, a branch per release or environment, and a short-lived branch per feature. Merges go through pull requests, so someone reviews every change. This gives you a history of who changed what and a way to rebuild any environment. It also fixes the biggest problem with change sets: nothing is lost when a sandbox is refreshed.
CI/CD Pipelines: Salesforce CLI and Packages
A pipeline runs the same steps every time code is merged: check out the code, deploy to a test org, run Apex tests, and report the result. The Salesforce CLI does the deploying. You can validate a deployment against production ahead of time and then quick deploy it later without running the tests again, as long as it is within 10 days. Unlocked packages group related metadata into a versioned unit you can install and upgrade, which makes large orgs easier to split up. DevOps Center gives admins a point-and-click way to work with Git-based pipelines. Change sets are still fine for small teams but don't scale.
Testing in the Deployment Pipeline
Apex code needs at least 75% overall test coverage to deploy to production, and every trigger needs some coverage. You choose the test level: RunLocalTests (the default for production when Apex is in the deployment), RunSpecifiedTests (faster, but each class in the deployment then needs 75% coverage from the tests you pick), or RunAllTestsInOrg. Beyond unit tests. Plan for integration testing in a Partial Copy sandbox, user acceptance testing in a Full sandbox, and regression testing before each release. Tests should create their own data and not depend on data in the org.
Release Management and Deployment Order
Some things must be deployed in order: objects and fields before the layouts and code that use them, and permission sets after the fields they grant. Some changes can't be deployed with metadata at all, such as certain org settings, and need a written manual step. Destructive changes (deleting metadata) need a destructiveChanges.xml file and can't be done with change sets. Salesforce has no one-click rollback, so the plan is to keep the last good version in Git and redeploy it, and to use feature flags such as custom metadata to switch new features off. Schedule big releases around the three Salesforce seasonal releases and test in a preview sandbox first.
Feature branches merge into a release branch, which is validated in a full/partial-copy sandbox, then promoted to production. Each merge triggers automated tests before advancing.
How to Pass the Salesforce Development Lifecycle and Deployment Architect Exam
Most questions ask for the right environment, tool or order of steps for a given team. Look for clues about team size, how much data is needed and how often changes ship.
Sandbox Strategy
Developers get Developer sandboxes. QA uses Partial Copy. Performance and final user testing use Full. If a question mentions realistic data volumes, the answer is a Full sandbox.
Change Set Limitations
Change sets can't delete metadata, can't move between unrelated orgs and don't keep history. When a scenario needs any of those, look for the CLI or packages.
Source-Driven Development
If the team keeps losing work when sandboxes are refreshed, or can't tell who changed what, the answer is version control with source-driven development.
Package Development (2GP)
Unlocked packages split a large org into versioned modules. Managed packages are for ISVs selling on AppExchange. Both are built with scratch orgs and a Dev Hub.
CI/CD Pipeline Design
Every merge should trigger a deploy and test run. Validate against production early, then quick deploy in the release window.
Is the Salesforce Certified Platform Development Lifecycle and Deployment Architect Exam Hard?
DifficultyChallenging; plan about 8-16 weeks of focused prep.
Book When ReadyScore 75%+ on three timed mocks before scheduling.
Use Practice, Not DumpsOriginal practice questions build skill without risking your credential.
Exam format: 60 questions, 105 min, 65% passing score.
Salesforce Certified Platform Development Lifecycle and Deployment Architect Practice Questions (With Explanations)
Test your knowledge with these 15 sample questions.
Question 1: A team needs to run performance tests with the same data volume as production before a big release. Which environment should they use?
Key takeaway: Only a Full sandbox has a complete copy of production data, so it is the only place where performance results mean something.
Show correct answer and explanation
Correct answer: A. Full sandbox
Only a Full sandbox has a complete copy of production data, so it is the only place where performance results mean something.
- A Partial Copy sandbox has only a sample of data, so load times won't match production.
- Scratch orgs start empty and are meant for development, not load testing.
- A Developer sandbox has no production data and only 200 MB of storage.
Question 2: An admin needs to delete three unused custom fields from production as part of a release. The team uses change sets today. What should they do?
Key takeaway: Change sets can't delete metadata.
Show correct answer and explanation
Correct answer: B. Use a destructiveChanges.xml file with the Salesforce CLI
Change sets can't delete metadata. A destructive changes manifest deployed with the CLI or Metadata API can.
- You can't refresh production from a sandbox.
- There is no deletion option in change sets.
- Removing fields from layouts hides them but doesn't delete them.
Question 3: A deployment was validated against production on Monday and passed all tests. The release window is Thursday. How can they deploy quickly on Thursday?
Key takeaway: A validated deployment can be quick deployed within 10 days without running the tests again, which keeps the release window short.
Show correct answer and explanation
Correct answer: D. Quick deploy the validated deployment
A validated deployment can be quick deployed within 10 days without running the tests again, which keeps the release window short.
- Running validation again repeats the slow test run you already did.
- A new change set would need its own tests in production.
- Running all tests would be even slower.
Question 4: Developers keep losing their work when the shared Developer Pro sandbox is refreshed. They also can't tell who changed what. What is the best fix?
Key takeaway: With Git as the source of truth, a sandbox refresh loses nothing, and every change has a history with an author.
Show correct answer and explanation
Correct answer: B. Adopt version control and source-driven development
With Git as the source of truth, a sandbox refresh loses nothing, and every change has a history with an author.
- A Full sandbox can be refreshed too; and still has no change history.
- A spreadsheet is manual, unreliable and not a real record of changes.
- Refreshing less often only delays the problem.
Question 5: A deployment uses RunSpecifiedTests. What coverage rule applies?
Key takeaway: With RunSpecifiedTests, every class and trigger in the package must reach 75% coverage from the tests you chose.
Show correct answer and explanation
Correct answer: C. Each class and trigger needs 75% coverage
With RunSpecifiedTests, every class and trigger in the package must reach 75% coverage from the tests you chose.
- Classes need coverage too; not only triggers.
- 90% is not a Salesforce requirement.
- Coverage rules still apply. They just apply per class instead of org-wide.
Question 6: A large org has five teams changing the same metadata. Releases often break each other's work. What should the architect recommend to split the org into independent parts?
Key takeaway: Unlocked packages let each team own a versioned set of metadata with clear dependencies, so they can release on their own schedule.
Show correct answer and explanation
Correct answer: C. Unlocked packages for each team's area
Unlocked packages let each team own a versioned set of metadata with clear dependencies, so they can release on their own schedule.
- Managed packages are for selling apps to other companies, not for internal teams.
- Sharing one sandbox increases collisions instead of reducing them.
- More change sets make the problem worse, since nobody can see what overlaps.
Question 7: Which statement about scratch orgs is correct?
Key takeaway: Scratch orgs are empty orgs created from a definition file.
Show correct answer and explanation
Correct answer: B. Built from source and a definition file
Scratch orgs are empty orgs created from a definition file. You push source to them and throw them away after use, within 30 days at most.
- Scratch orgs start with no production data.
- You need a Dev Hub to create scratch orgs.
- 29 days is the refresh interval for Full sandboxes.
Question 8: A release went live and broke a key process. Salesforce has no rollback button. What is the best plan for next time?
Key takeaway: With the last good version in Git you can redeploy it quickly.
Show correct answer and explanation
Correct answer: A. Keep the old version in source control, use feature flags
With the last good version in Git you can redeploy it quickly. Feature flags, such as a custom metadata setting, let you turn a feature off without a deployment.
- Skipping tests increases the chance of breaking production.
- Deploying on a certain day doesn't make rollback possible.
- Avoiding Apex isn't realistic and doesn't address rollback.
Question 9: The QA team needs a test environment with realistic sample data from several objects, refreshed about once a week. Which sandbox fits best?
Key takeaway: A Partial Copy sandbox copies a sample of production data using a template and can be refreshed every 5 days.
Show correct answer and explanation
Correct answer: C. Partial Copy sandbox
A Partial Copy sandbox copies a sample of production data using a template and can be refreshed every 5 days.
- Scratch orgs start empty and need data loaded by script.
- Developer sandboxes have no production data.
- Developer Pro also copies metadata only, with no production data.
Question 10: A deployment fails because a page layout refers to a field that doesn't exist in production yet. What is the right fix?
Key takeaway: Metadata that is referenced must exist before or alongside the metadata that uses it.
Show correct answer and explanation
Correct answer: A. Include the field, or deploy it first
Metadata that is referenced must exist before or alongside the metadata that uses it. Deploy the field with the layout or before it.
- Deleting the layout loses work and isn't needed.
- Tests don't fix a missing dependency.
- Deploying the layout first is what caused the failure.
Question 11: An admin team with little Git experience wants to move away from change sets and start using source control, using clicks rather than the command line. What should they look at?
Key takeaway: DevOps Center gives a point-and-click interface on top of Git and pipelines, designed for admins and low-code teams.
Show correct answer and explanation
Correct answer: D. DevOps Center
DevOps Center gives a point-and-click interface on top of Git and pipelines, designed for admins and low-code teams.
- Workbench is a utility for queries and simple deploys, not a pipeline tool.
- Data Loader moves data, not metadata.
- The Ant Migration Tool is command-line and is being retired.
Question 12: What is the minimum overall Apex code coverage needed to deploy to production?
Key takeaway: Salesforce requires at least 75% overall coverage, and every trigger must have some coverage.
Show correct answer and explanation
Correct answer: A. 75%
Salesforce requires at least 75% overall coverage, and every trigger must have some coverage.
- 50% is below the requirement.
- 65% is below the requirement.
- 100% is a good goal but not the rule.
Question 13: Salesforce's next seasonal release is in six weeks. The team wants to test their custom code against it before production is upgraded. What should they do?
Key takeaway: Sandboxes on a preview instance get the new release a few weeks before production.
Show correct answer and explanation
Correct answer: B. Refresh a sandbox onto preview before the cutoff
Sandboxes on a preview instance get the new release a few weeks before production. Refreshing in time puts a sandbox on preview so you can test early.
- A Developer Edition org doesn't have your org's code or setup.
- Salesforce doesn't delay releases for single customers.
- Testing after the upgrade means any problems hit users first.
Question 14: A team wants every pull request to be tested automatically before it is merged. What is the core of the pipeline?
Key takeaway: Continuous integration runs the same deploy and test steps on every change, so problems are found before the merge.
Show correct answer and explanation
Correct answer: C. A CI job that deploys to a test org and runs tests
Continuous integration runs the same deploy and test steps on every change, so problems are found before the merge.
- Email isn't a pipeline and adds no testing.
- Change sets can't be automated from a pull request.
- A weekly manual deploy finds problems late.
Question 15: Tests pass in the sandbox but fail in production because they rely on records that exist only in the sandbox. What should be changed?
Key takeaway: Tests should build the data they need, using test setup methods or factories.
Show correct answer and explanation
Correct answer: D. Make the tests create their own test data
Tests should build the data they need, using test setup methods or factories. Then they behave the same in every org.
- SeeAllData makes tests depend on org data, which is the cause of the problem.
- Lowering coverage doesn't fix failing tests, and 75% is fixed.
- Copying test records into production pollutes real data.
Get the Full Question Bank
Most candidates book the exam after scoring 75%+ on full mocks.
If you’re planning to test this quarter, aim to complete full mocks at least 10–14 days before your exam date.
Contact us for more information on our full 60-question mock exams and a personalized study plan. Use the contact form.
Request Mock Exams & Study PlanSalesforce Certified Platform Development Lifecycle and Deployment Architect Exam FAQs
- What is covered on the Salesforce Certified Platform Development Lifecycle and Deployment Architect exam?
- The Salesforce Certified Platform Development Lifecycle and Deployment Architect exam (formerly Salesforce Certified Dev Lifecycle and Deployment Architect) covers section-wise weightage as shown above. Use the exam topics and practice questions on this page to align your study with the official outline.
- What is Development Lifecycle and Deployment Architect?
- Dev Lifecycle and Deployment Architect designs deployment strategies, CI/CD pipelines, release management, and ensures proper governance for Salesforce deployments.
- Do I need Application Architect before Dev Lifecycle Architect?
- Yes, Application Architect and System Architect are typically required. Dev Lifecycle Architect requires deep understanding of DevOps, CI/CD, and deployment.
- Are there free practice questions for the Salesforce Certified Platform Development Lifecycle and Deployment Architect exam?
- Yes. This page includes free sample practice questions with explanations. Use them alongside the current official documentation.
- How do I prepare for the Salesforce Certified Platform Development Lifecycle and Deployment Architect certification?
- Use the exam tips, prerequisites, and study strategy on this Salesforce Certified Platform Development Lifecycle and Deployment Architect study guide (formerly Salesforce Certified Dev Lifecycle and Deployment Architect). Focus first on the highest-weighted sections, then take the sample practice questions. Schedule the exam when you consistently score well on practice tests.
Next Architect Certifications
After this exam, most people complete the other System Architect exams and then aim for CTA:
Honest Cert Breakdown
Difficulty: Hard
4/5One of the four CTA domain exams. Covers DevOps, source control, sandbox strategy, and release management at enterprise scale.
Salary Range
$120,000–$158,000 / year
US average for certified professionals • Updated Summer '26 • Source: Salesforce Talent Ecosystem
Is it worth it?
Essential for technical architects managing multi-team deployments. Required on CTA path. Also directly applicable to DevOps-focused roles.
How the Exam Is Weighted
Inside Each Exam Section
Environment Strategy
Sandbox types (Developer, Developer Pro, Partial, Full), when to use each. Scratch orgs: definition-driven, short-lived, source-driven. Hub org and scratch org lifecycle. Org strategy for ISV partners (packaging orgs, subscriber orgs) vs enterprise customers. Sandbox refresh strategy and data masking.
Release Management
Release management approaches: change sets (UI-based, declarative), Metadata API (XML-based, scriptable), Salesforce CLI/SFDX (source-driven). Comparing change sets vs SFDX for team-based development. Release branching strategies: GitFlow, trunk-based development. Deployment order and dependency management.
Team-Based Development
Source control with Git: branching, pull requests, merge strategies. Developer isolation using scratch orgs. Merging metadata: conflict resolution, metadata types that conflict (profiles, permission sets, custom labels). Code review practices and pull request workflows in Salesforce projects. Package development model vs org development model.
CI/CD & Automation
CI/CD pipeline stages: build, test, deploy. Tools: Salesforce CLI, Gearset, Copado, GitHub Actions, Jenkins, CircleCI for Salesforce. Running Apex tests in CI: minimum 75% coverage requirement, test selection strategies. Static code analysis: PMD, Salesforce Code Analyzer. Automated deployment validation.
Governance & ALM
Application Lifecycle Management (ALM) tooling: Jira, ADO, ServiceNow for work item tracking. Change advisory boards (CAB) and release governance. Managing unpackaged vs packaged metadata. 1st-Generation Packaging (1GP) vs 2nd-Generation Packaging (2GP): differences, use cases, namespace management. ISV partner program requirements.
10-Week Study Plan
Exam Question Strategy
- 1.Sandbox vs scratch org decision: Use scratch orgs for short-lived, isolated developer work and CI/CD pipelines. Use sandboxes for persistent integration testing, UAT, and environments that need production-matching data or configuration.
- 2.SFDX over change sets for teams: Any scenario with multiple developers, version control requirements, or CI/CD should recommend SFDX/Salesforce CLI over change sets. Change sets are appropriate only for simple admin-driven deployments without version control.
- 3.2GP for new ISV development: Any new AppExchange product or managed package should use 2nd-Generation Packaging. 1GP is legacy, the exam tests when 2GP is the correct recommendation and what limitations still apply (e.g., namespace requirements for managed 2GP).
- 4.75% Apex test coverage is a minimum: The exam will reference the Salesforce requirement that at least 75% of Apex code must be covered by tests for production deployment. In CI/CD, run tests on every commit and fail the pipeline if coverage drops below 75%.
Know You’re Ready
Aim for 75%+ on practice exams before scheduling. DLDA is conceptual and scenario-driven, questions describe a team’s development situation and ask for the best environment strategy, deployment tool, or CI/CD design. Hands-on experience with Salesforce CLI and Git significantly improves performance.
Key Concepts Checklist
- Sandbox types: storage, data, metadata, refresh frequency, use cases
- Scratch orgs: Dev Hub, definition file, lifecycle, vs sandboxes
- Change sets vs Metadata API vs Salesforce CLI, trade-offs for each
- GitFlow vs trunk-based development for Salesforce teams
- CI/CD pipeline stages and Salesforce-specific considerations
- Apex test coverage: 75% minimum, test selection in CI
- Static code analysis tools: PMD, Salesforce Code Analyzer
- Unlocked packages vs managed 1GP vs managed 2GP
- 2GP: namespace options, project-level vs package-level namespace
- DevOps Center, Gearset, Copado, roles in Salesforce ALM
FAQs From Candidates
- What is the Salesforce Dev Lifecycle & Deployment Architect certification?
- The Dev Lifecycle & Deployment Architect (DLDA) certification validates expertise in designing and implementing Salesforce development processes, including org strategy, environment management, CI/CD pipelines, release management, and team-based development practices. The exam has 60 questions, ~110-minute time limit, 65% passing score, and a $400 fee. It is part of the System Architect credential path.
- What is the difference between change sets and Salesforce CLI/SFDX?
- Change sets are a UI-based deployment tool built into Salesforce Setup, easy to use but limited: no version control integration, no automation, no rollback, and limited metadata type support. Salesforce CLI (SFDX) is a source-driven command-line tool that works with Git, supports scratch orgs, enables CI/CD pipelines, and covers all metadata types. For enterprise projects and ISV development, SFDX is the recommended approach. Change sets are still acceptable for simple admin-driven deployments.
- What are scratch orgs and when should I use them?
- Scratch orgs are temporary, disposable Salesforce environments created from a configuration file (project-scratch-def.json) using Salesforce CLI. They are short-lived (up to 30 days), source-driven, and ideal for developer isolation in CI/CD pipelines. Each developer or CI build gets a fresh org, eliminating merge conflicts from shared sandbox environments. Use scratch orgs for: ISV/AppExchange development, CI/CD pipelines, developer isolation in team projects. Use sandboxes when you need persistent data, production-matching configurations, or integration testing.
- What is the difference between 1GP and 2GP packaging?
- First-Generation Packaging (1GP) is the original ISV packaging model; metadata is locked to a namespace org, packages are managed, and releases are uploaded manually. Second-Generation Packaging (2GP) is the modern model; packages are created from source control using Salesforce CLI, support multiple packages in one namespace, enable unlocked packages (no namespace requirement), and integrate natively with CI/CD. For new ISV projects, 2GP is strongly recommended. The exam tests when each is appropriate and how they differ in namespace handling.
- What CI/CD tools work with Salesforce?
- Salesforce supports multiple CI/CD approaches: Salesforce CLI scripts in any CI platform (GitHub Actions, CircleCI, Jenkins, Azure DevOps, Bitbucket Pipelines); native Salesforce tools like Salesforce DevOps Center (built into Setup); and third-party platforms like Gearset (most popular in enterprise), Copado (enterprise ALM + DevOps), and AutoRABIT. The exam tests conceptual CI/CD pipeline design and the role of each stage; it does not require tool-specific configuration knowledge.
Your Next Certification Step
After this certification, consider: Application Architect, System Architect, or Technical Architect (CTA).
Topic Difficulty Heatmap
Which topics are a gimme vs which ones trap confident candidates. Use this to prioritise your final-week revision. These are our own topic groupings for study planning, not the official exam sections, those and their weightings are in the credential's exam guide.
| Topic | Difficulty | Study Tip |
|---|---|---|
| Release Management | Moderate | Release strategy and branching. Know the trade-offs. |
| Environments and Metadata | Trap ⚠ | What can be deployed via change set vs Metadata API, frequently tested. |
| CI/CD and Version Control | Hard | Pipeline design and Salesforce DX, scratch org and source of truth. |
| Governance | Moderate | Governance and quality gates, standard DevOps. |
Difficulty based on analysis of common candidate errors across each exam section.
Test Yourself
Free Dev Lifecycle & Deployment Architect practice questions covering all 5 exam sections.
Start Free Practice QuestionsTL;DR: What Dev Lifecycle & Deployment Architect Tests
- Environment strategy: Sandbox type selection (Developer, Developer Pro, Partial Copy, Full), environment hierarchy design for parallel development streams, and scratch org vs. sandbox decisions.
- Release management: Source-driven development with SFDX, unlocked packages vs. change sets, CI/CD pipeline design, and branching strategy for Salesforce teams.
- Deployment strategy: When to use change sets vs. SFDX CLI vs. package-based deployment, metadata dependency management, and rollback strategy.
Which Sections Carry the Most Weight
Environment Strategy + Release Management + Deployment = 75%. Sandbox hierarchy and SFDX are your core study topics.
Scenario Strategy: How to Approach Dev Lifecycle Questions
Dev Lifecycle questions describe an organisation’s development setup and ask which environment strategy, deployment method, or release process is correct. The key is identifying the scale of the team and the frequency of releases.
- For sandbox selection: Developer = individual dev work, no data needed; Partial Copy = testing with a subset of production data; Full = UAT/performance testing with production-scale data. Cost increases significantly from Developer → Full.
- Change sets are simple but create deployment dependencies that are hard to manage at scale. Recommend SFDX + source control when the scenario involves multiple parallel development streams or CI/CD requirements.
- Unlocked packages enable modular deployment and versioning, recommend them when the scenario requires packaging components for reuse across multiple orgs or precise version rollback.
- For CI/CD questions: scratch orgs are disposable and ideal for automated testing pipelines. Sandboxes are persistent and better for long-running integration testing. Know the lifecycle differences.
Booking Readiness Benchmark
75%+ on 3 timed full mocks before booking
Dev Lifecycle & Deployment Architect questions are heavily scenario-based and require real release management experience. Candidates who have managed Salesforce deployments across multiple environments and implemented CI/CD pipelines are significantly better prepared than those who only study theory.
3 Concepts That Fail Most Dev Lifecycle & Deployment Architect Candidates
These are not the hardest topics; they are the ones where candidates are most confidently wrong. Learn the distinction early.
1. Unlocked Packages vs Change Sets vs Metadata API: Choosing the Right Deployment Tool
Change Sets are UI-based; work only between related orgs, and have no version control. Metadata API is scriptable but stateless (no package versioning). Unlocked Packages are modular, versioned, and installable across unrelated orgs; they are the modern recommended approach for complex org development. Candidates recommend Change Sets for all deployments, the exam expects Unlocked Packages for independent module deployment and CI/CD pipelines.
2. Scratch Orgs vs Sandboxes: Source-Driven vs Org-Driven Development
Scratch Orgs are temporary, configuration-driven development environments spun up from source code, they enforce source-driven development. Sandboxes are copies of production (or another sandbox) and are better for QA and UAT. Candidates use sandboxes for development, the exam expects scratch orgs for feature development in a DX-based CI/CD pipeline.
3. CI/CD Pipeline Stages: What Runs in Each Environment
A typical Salesforce CI/CD pipeline: develop in scratch orgs → run unit tests in CI org → deploy to SIT sandbox → UAT sandbox → staging sandbox → production. Candidates skip stages or run unit tests only in production deployment, the exam expects unit tests to run at every stage, with integration tests in SIT and user acceptance in UAT.
Questions Candidates Ask
- What is the Dev Lifecycle & Deployment Architect exam format?
- The Salesforce Dev Lifecycle & Deployment Architect exam has 60 multiple-choice questions, a 105-minute time limit, a 65% passing score, and a $200 fee. It is a component exam for the System Architect role-based credential and tests release management, DevOps strategy, and environment architecture.
- What are the highest-weight Dev Lifecycle & Deployment Architect exam sections?
- Environment Strategy (30%) is the single highest-weight section, followed by Release Management (25%) and Deployment Strategy (20%). Together these three sections account for 75% of the exam. Sandbox hierarchy design and source-driven development are the most heavily tested topics.
- What is tested in the Dev Lifecycle & Deployment Architect exam?
- The exam tests: sandbox environment strategies (when to use Developer vs. Full vs. Partial Copy sandboxes), release management frameworks (Salesforce DevOps Center, Gearset, Copado, SFDX), version control strategy, metadata deployment (change sets vs. SFDX vs. package-based development), and CI/CD pipeline design for Salesforce.
- What makes the Dev Lifecycle & Deployment Architect exam hard?
- The exam requires architectural thinking about DevOps, not just knowledge of tools. Candidates must recommend sandbox strategies for organisations with multiple parallel development streams, design CI/CD pipelines, and understand the trade-offs between scratch orgs vs. sandboxes vs. packaging models. Real release management experience is essential.
- What concepts do most Dev Lifecycle & Deployment Architect candidates get wrong?
- The most commonly misunderstood topics for the Dev Lifecycle & Deployment Architect exam are: (1) Unlocked Packages vs Change Sets vs Metadata API: Choosing the Right Deployment Tool; (2) Scratch Orgs vs Sandboxes: Source-Driven vs Org-Driven Development; (3) CI/CD Pipeline Stages: What Runs in Each Environment. Candidates are most confidently wrong on these. Learn the distinctions early to avoid losing marks on questions you expect to get right.
- Why do most Dev Lifecycle Deployment Architect candidates fail questions about Unlocked Packages vs Change Sets vs Metadata API?
- Change Sets are UI-based; work only between related orgs, and have no version control. Metadata API is scriptable but stateless (no package versioning). Unlocked Packages are modular, versioned, and installable across unrelated orgs; they are the modern recommended approach for complex org development. Candidates recommend Change Sets for all deployments, the exam expects Unlocked Packages fo...
- Why do most Dev Lifecycle Deployment Architect candidates fail questions about Scratch Orgs vs Sandboxes?
- Scratch Orgs are temporary, configuration-driven development environments spun up from source code, they enforce source-driven development. Sandboxes are copies of production (or another sandbox) and are better for QA and UAT. Candidates use sandboxes for development, the exam expects scratch orgs for feature development in a DX-based CI/CD pipeline.
- Why do most Dev Lifecycle Deployment Architect candidates fail questions about CI/CD Pipeline Stages?
- A typical Salesforce CI/CD pipeline: develop in scratch orgs → run unit tests in CI org → deploy to SIT sandbox → UAT sandbox → staging sandbox → production. Candidates skip stages or run unit tests only in production deployment, the exam expects unit tests to run at every stage, with integration tests in SIT and user acceptance in UAT.
Related Study Resources
Start Dev Lifecycle & Deployment Prep
After this exam, consider Application Architect or System Architect next.
Share or cite this study guide
Free to link from a forum post, study repo or article. Copy the Markdown and paste it anywhere.