Testing, Debugging, and Deployment20% of the exam
Sandboxes, change sets and deploying code
Pick the right sandbox by data and refresh interval, choose between change sets, the Metadata API through the CLI and packages, and meet production test levels, coverage, validation, Quick Deploy and deletion rules.
Describe the environments, requirements, and process for deploying code and associated configurations.
~8 min read · 13 practice questions ·
What the exam expects
- Choose a sandbox type (Developer, Developer Pro, Partial Copy, Full) or a scratch org from what is copied, storage and refresh interval.
- Decide between change sets, the Metadata API through the Salesforce CLI, and unlocked or managed packages given which orgs are involved and whether components must be deleted.
- State what a production deployment of Apex requires: test level, 75% coverage, passing tests and trigger coverage.
- Plan a release with a validation-only deployment and Quick Deploy, and remove metadata with a destructive changes manifest.
- Explain source tracking and CI basics.
Key terms: sandbox (an isolated copy of production); deployment connection (the link change sets need); test level (which Apex tests a deployment runs); Quick Deploy (committing a validated deployment without rerunning tests); source tracking (the CLI's record of local versus org changes).
Key facts
Refresh intervals
- Detail
- Developer and Developer Pro 1 day, Partial Copy 5 days, Full 29 days
Performance and load testing
- Detail
- Only Full sandboxes support it
Change set reach
- Detail
- Only orgs affiliated with the same production org, over a deployment connection
Change set deletions
- Detail
- Not possible; renames aren't either
Production Apex rule
- Detail
- 75% coverage, all tests pass, every trigger has some coverage
NoTestRun
- Detail
- Development environments only; their default
RunSpecifiedTests coverage
- Detail
- 75% per class and trigger in the package; test classes only
Validation job ID
- Detail
- Valid for 10 days for Quick Deploy
Delete-only deployment
- Detail
- destructiveChanges.xml plus an empty package.xml with the API version
Source tracking in sandboxes
- Detail
- Developer and Developer Pro once enabled; not Partial Copy, Full or Developer Edition
Sources for this section (10)
- Sandbox Licenses and Storage Limits by Typehelp.salesforce.com (opens in a new tab)
- Sandbox Types and Templateshelp.salesforce.com (opens in a new tab)
- Change Setshelp.salesforce.com (opens in a new tab)
- Change Sets Best Practiceshelp.salesforce.com (opens in a new tab)
- Testing Best Practicesdeveloper.salesforce.com (opens in a new tab)
- deploy()developer.salesforce.com (opens in a new tab)
- Running a Subset of Tests in a Deploymentdeveloper.salesforce.com (opens in a new tab)
- project deploy quickdeveloper.salesforce.com (opens in a new tab)
- Deleting Components from an Organizationdeveloper.salesforce.com (opens in a new tab)
- Enable Source Tracking in Sandboxesdeveloper.salesforce.com (opens in a new tab)
- Why can't a Full sandbox serve as each developer's daily environment?
- When does a production deployment with no test level set run no tests?
- Why use the CLI rather than change sets between two unrelated orgs?
- Which package type suits an internal app installed and upgraded across several orgs?
The questions are free to read. Answers with their sources and self-grading are included with the pack.
Keep reading with the Platform Developer pack
- Core concepts
- Exam traps
- Worked scenario
The pack includes:
- All 21 lessons of the Platform Developer guide, with reading progress
- Interactive decision walks and step-by-step sequence steppers
- Inline practice questions and one-click topic practice (13 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Unlimited timed practice exams