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, ~68% 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.

Study Guide

Salesforce Dev Lifecycle & Deployment Architect Study Guide (Spring '26)

Your complete guide to passing the DLDA exam — org strategy, CI/CD pipelines, scratch orgs, packaging, release management, and team-based development.

Written and reviewed by Krishna Mohan — ADM-201, PD1, PD2, App Builder & Consultant certified. Updated for Spring '26. Methodology · Contact

Ready to sharpen your exam strategy? Prepare with our Development Lifecycle & Deployment Architect Exam Tips & Strategy Guide — high-weight topics, scenario tactics, and mock-test targets for first-attempt success.

Honest Cert Breakdown

Difficulty: Hard

4/5

One 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 Spring '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.

Exam Fees

Architect

Exam fee

$400

USD

Retake fee

$200

USD

Start Dev Lifecycle & Deployment Architect Practice Questions

Questions

110 min

Time Limit

~68%

Passing Score

$400

Exam Fee

Exam Sections & Weightings

Environment Strategy25%

Release Management25%

Team-Based Development20%

CI/CD & Automation18%

Governance & ALM12%

What Each Section Tests

25%

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.

25%

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.

20%

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.

18%

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.

12%

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

Week 1Sandbox types — compare Developer, Developer Pro, Partial Copy, and Full sandbox: storage limits, data, metadata, refresh frequency, and use cases for each.

Week 2Scratch orgs — set up a Dev Hub, create a scratch org from a definition file, deploy metadata from source control, and delete the scratch org. Understand the scratch org lifecycle.

Week 3Salesforce CLI & SFDX — install SFDX, connect to an org, retrieve and deploy metadata, run Apex tests from the command line. Compare with the Metadata API.

Week 4Change sets vs SFDX — build a change set deployment in a sandbox, then replicate the same deployment with SFDX. Understand the limitations of change sets for team environments.

Week 5Git branching strategies — study GitFlow (feature, develop, release, main branches) and trunk-based development. Understand which strategy suits Salesforce project team sizes.

Week 6CI/CD pipeline design — sketch a full CI/CD pipeline: source control trigger, static analysis, scratch org creation, metadata deploy, Apex test run, deploy to staging, deploy to production.

Week 7Packaging — understand the differences between unpackaged metadata, unlocked packages, managed 1GP, and managed 2GP. Know when each is appropriate. Practice creating an unlocked package.

Week 8Release governance — study change advisory boards (CAB), release calendars, deployment windows, and rollback strategies. Understand how to handle failed deployments.

Week 9ALM tools — understand the role of Jira, Copado, Gearset, Salesforce DevOps Center in a Salesforce project. Know what functionality each category of tool provides.

Week 10Full mock exams. Environment Strategy (25%) + Release Management (25%) = 50% of the exam. Master sandbox vs scratch org decision scenarios. Aim for 75%+ before booking.

Scenario Strategy Tips

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%.

Mock Exam Benchmark

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.

Top 10 Concepts to Review

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

Frequently Asked Questions

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, ~68% 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.

What Comes After This Certification?

After this certification, consider: Application Architect, System Architect, or Technical Architect (CTA).

Exam Section Difficulty Heatmap

Which sections are a gimme vs which ones trap confident candidates. Use this to prioritise your final-week revision.

Exam Section	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.

Ready to Practice?

Free Dev Lifecycle & Deployment Architect practice questions covering all 5 exam sections.

Start Free Practice Questions