PD1 Deployment Strategies 5 — Questions and Answers
Question 1: What is the key difference between an Unlocked Package and a Managed Package in terms of deployability?
- Unlocked Packages can only be deployed to scratch orgs
- Unlocked Package source is visible and modifiable by the subscriber org (Correct answer)
- Managed Packages support version rollback; Unlocked Packages do not
- Unlocked Packages require AppExchange approval before deployment
Correct answer: Unlocked Package source is visible and modifiable by the subscriber org
Unlike Managed Packages which protect source code, Unlocked Package components are fully visible and can be modified in the subscriber org.
Question 2: Which command creates a new version of an unlocked package and promotes it to 'released' status in one step?
- sf package version create --code-coverage --installation-key-bypass
- sf package version promote --package
- sf package create --released
- sf package version create --promote (Correct answer)
Correct answer: sf package version create --promote
The --promote flag on 'sf package version create' creates the version and immediately promotes it to released status so it can be installed in production.
Question 3: A developer needs to delete a custom field from production that was removed from the source repo. Which file must be created for this to happen via CLI deployment?
- removeComponents.xml
- destructiveChanges.xml (Correct answer)
- deleteManifest.xml
- purgeComponents.xml
Correct answer: destructiveChanges.xml
destructiveChanges.xml lists metadata components to be deleted during a deployment; it is the standard mechanism for removing components via Salesforce CLI.
Question 4: Which environment type is fully configurable via JSON, spins up in minutes, and is deleted after use — making it ideal for feature-branch testing?
- Developer Sandbox
- Partial Copy Sandbox
- Scratch Org (Correct answer)
- Developer Pro Sandbox
Correct answer: Scratch Org
Scratch Orgs are short-lived, definition-file-configured environments purpose-built for feature development and automated CI/CD testing.
Question 5: When a deployment fails mid-way through in Salesforce, what state is the target org left in?
- Partial deployment — successfully processed components remain deployed
- The org is rolled back to its pre-deployment state automatically (Correct answer)
- The org is locked until a system admin manually clears the deployment
- The failure is logged but all successful components are committed
Correct answer: The org is rolled back to its pre-deployment state automatically
Salesforce deployments are fully transactional — a failure causes a complete rollback so no partial changes are applied to the org.
Question 6: What is the role of the 'sfdx-project.json' file in a Salesforce DX project?
- Stores authentication tokens for the target org
- Defines project metadata, package directories, and API version settings (Correct answer)
- Lists all test classes to run during deployment
- Specifies which components to include in a Change Set
Correct answer: Defines project metadata, package directories, and API version settings
sfdx-project.json is the project configuration file that defines source paths, API versions, package information, and other project-level settings.
Question 7: A team wants to enforce that no Apex deployment can reduce code coverage below 75% in their CI pipeline. Which approach is most effective?
- Set the org-wide Code Coverage Warning in Setup
- Use RunLocalTests in the deployment and fail the pipeline if coverage drops below 75% (Correct answer)
- Use a pre-deployment Apex script to check coverage
- Salesforce automatically blocks deployments below 75% coverage
Correct answer: Use RunLocalTests in the deployment and fail the pipeline if coverage drops below 75%
Configuring the CI pipeline to execute RunLocalTests and fail the build when coverage falls below 75% enforces the coverage gate before any org change is committed.
What is the key difference between an Unlocked Package and a Managed Package in terms of deployability?