75 Salesforce Deployment & DevOps Interview Questions 2026 — Change Sets, SFDX, CI/CD
📅 DevOps
🚀 DevOps Interview Prep 2026
Top 75 Salesforce Deployment & DevOps
Interview Questions 2026
Interview Questions 2026
The most comprehensive free resource covering Change Sets, SFDX, CI/CD Pipelines, Sandboxes, Packages, DevOps Center, Deployment Tools & real Scenario-based questions. No paywall. No signup. Ever.
75
Questions
9
Sections
All
Levels
100%
Free
📋 Jump to Section
🔗 Related Salesforce Interview Prep
📦 Section 1 — Change Sets
Q1–Q10 · Beginner to Intermediate · Asked in Every Salesforce Admin/Dev Interview
Q1
What is a Change Set in Salesforce and how does it work?
✅ Direct Answer
A Change Set is a deployment container that packages metadata and sends it from one Salesforce org to another through an established deployment connection — typically from sandbox to production.
💡 Why?
Salesforce orgs are isolated environments — you cannot directly modify production. Change Sets are the simplest built-in deployment tool: create → add components → upload → receive in target → validate → deploy. No CLI or version control required.
📊 Change Set Flow
| Step | Action | Location |
|---|---|---|
| 1 | Create Outbound Change Set | Source Org (Sandbox) |
| 2 | Add components (Apex, LWC, Fields) | Source Org |
| 3 | Upload Change Set | Source Org |
| 4 | Receive Inbound Change Set | Target Org (Production) |
| 5 | Validate or Deploy | Target Org |
🔑 Key Points for Interviewer
- Outbound = created in source org to send. Inbound = received in target org to deploy
- Deployment connection must be authorized from both orgs in Setup → Deployment Settings
- Always validate before deploying — runs all Apex tests without making changes
- Cannot deploy data (records), only metadata
- No rollback — failed deployments auto-rollback, but successful ones are permanent
🎤 One-Line Answer for Interview
"A Change Set is a metadata deployment container that moves customizations between connected Salesforce orgs — the simplest built-in deployment method with no CLI or version control required."
Q2
What are the key limitations of Change Sets?
✅ Direct Answer
Change Sets cannot delete components, cannot deploy data records, require an established deployment connection between related orgs, have no version control, cannot be automated, and are limited to 10,000 files and 400MB per Change Set.
🔑 Key Limitations
- ❌ Cannot delete metadata components (use destructive changes XML instead)
- ❌ Cannot deploy data records — metadata only
- ❌ No version control or audit history
- ❌ Cannot be automated — fully manual process
- ❌ Cannot be used between unrelated orgs (no deployment connection)
- ❌ 10,000 file and 400MB limit per Change Set
- ❌ No rollback for successful deployments
🏢 XYZ Company Example
XYZ Company needed to remove an obsolete custom field from production. They discovered Change Sets cannot delete components — they had to manually delete it in production directly. This limitation is exactly why larger teams migrate to SFDX with destructive changes XML.
🎤 One-Line Answer for Interview
"Change Sets cannot delete components, have no version control, cannot be automated, and require deployment connections — making them unsuitable for teams needing CI/CD or deletion of metadata."
Q3
What is the difference between Validate and Deploy in a Change Set?
✅ Direct Answer
Validate runs all Apex tests and checks for errors WITHOUT making any changes to the org. Deploy actually applies the changes. Quick Deploy (available 10 days post-validation) re-uses cached results and deploys instantly without re-running tests.
📊 Comparison
| Action | Runs Tests? | Makes Changes? | Best For |
|---|---|---|---|
| Validate | ✅ Yes | ❌ No | Pre-deployment dry run |
| Deploy | ✅ Yes | ✅ Yes | Actual deployment |
| Quick Deploy | ❌ Cached | ✅ Yes | After successful validation |
🏢 XYZ Company Example
XYZ Company validates every Sunday night (45 mins running 500+ test classes), then uses Quick Deploy Monday morning — completing production deployment in under 2 minutes with zero test re-runs.
🎤 One-Line Answer for Interview
"Validate is a dry run — runs all tests with no changes. Deploy makes actual changes. Quick Deploy uses cached validation to deploy instantly within 10 days — always validate first in production."
Q4
What is a Deployment Connection and how do you set it up?
✅ Direct Answer
A Deployment Connection is a trust relationship between two Salesforce orgs enabling Change Sets to flow between them. It must be authorized from both the source and target org in Setup → Deployment Settings.
🔑 Key Points for Interviewer
- Production automatically connects to all its sandboxes
- Sandbox-to-sandbox connections must be manually enabled
- Cannot deploy from production to sandbox using Change Sets
- Only works between orgs in the same Salesforce environment
🎤 One-Line Answer for Interview
"A Deployment Connection is a trust relationship authorizing Change Set transfers — setup in Setup → Deployment Settings from both source and target org."
Q5
What is the difference between Change Sets and Metadata API deployment?
✅ Direct Answer
Change Sets are UI-based, manual, limited, and require deployment connections. Metadata API/SFDX deployment is programmatic, automatable, supports version control, can delete components (destructive changes), and works between any orgs — the professional standard.
📊 Full Comparison
| Feature | Change Sets | Metadata API / SFDX |
|---|---|---|
| Interface | UI only | CLI / programmatic |
| Version Control | ❌ No | ✅ Yes (Git) |
| Delete Components | ❌ No | ✅ Yes |
| Automation / CI/CD | ❌ No | ✅ Yes |
| Unrelated Orgs | ❌ No | ✅ Yes |
🎤 One-Line Answer for Interview
"Change Sets are UI-based and simple but lack version control and automation; Metadata API/SFDX is programmatic, supports Git, deletes components, and enables full CI/CD — the enterprise standard."
Q6
How do you handle Change Set deployment failures?
✅ Direct Answer
When a deployment fails, Salesforce automatically rolls back all changes — the target org is unaffected. Read the error log to identify the root cause, fix in the source org, and redeploy.
📊 Common Failures & Fixes
| Error Type | Fix |
|---|---|
| Apex test failure | Fix test class in sandbox, re-add to Change Set |
| Missing dependency | Add missing component to Change Set |
| Profile conflict | Include Profile or configure manually |
| Code coverage below 75% | Add test methods, increase coverage |
🎤 One-Line Answer for Interview
"Deployment failures auto-rollback — read the error log, fix the issue (missing dependency, test failure, permission conflict) in the source sandbox, then redeploy."
Q7
Can you include Profiles and Permission Sets in a Change Set?
✅ Direct Answer
YES — both can be included. However, Profiles fully overwrite target settings (risky) while Permission Sets are additive and safe. Best practice: use Permission Sets for new feature access, include Profiles only when absolutely necessary.
📊 Profile vs Permission Set
| Aspect | Profile | Permission Set |
|---|---|---|
| Include recommended? | ⚠️ With caution | ✅ Always safe |
| Overwrites target? | ✅ Full overwrite | ✅ Additive only |
| Risk | High — can remove access | Low |
🎤 One-Line Answer for Interview
"Both can be included — but Profiles fully overwrite target settings (risky) while Permission Sets are additive and safe. Always prefer Permission Sets for new feature access."
Q8
What is the maximum size of a Change Set?
✅ Direct Answer
A Change Set can contain a maximum of 10,000 files and 400MB total size. If your deployment exceeds this, split into multiple Change Sets and deploy in dependency order.
🔑 Other Limits
- Outbound Change Sets expire after 30 days if not deployed
- Quick Deploy window is 10 days after successful validation
- No limit on number of Change Sets you can create
🎤 One-Line Answer for Interview
"Maximum 10,000 files and 400MB per Change Set — split larger deployments into multiple Change Sets deployed in dependency order."
Q9
What is the difference between uploading and deploying a Change Set?
✅ Direct Answer
Uploading sends the Change Set from source to target org (making it available as Inbound). Deploying actually applies the changes to the target org. They are separate actions — typically developer uploads, admin deploys in production.
🎤 One-Line Answer for Interview
"Uploading transfers the Change Set to target org; deploying applies the changes — separate steps with different roles for proper separation of duties."
Q10
When should you NOT use Change Sets?
✅ Direct Answer
Avoid Change Sets when working with multiple developers, needing component deletion, requiring CI/CD automation, deploying to unrelated orgs, or deploying frequently. These scenarios require SFDX and Metadata API.
🔑 Avoid Change Sets When
- ❌ Multiple developers working on same org simultaneously
- ❌ Need to delete metadata (use destructive changes XML)
- ❌ Deploying to unrelated org (no deployment connection)
- ❌ Need automated CI/CD pipeline
- ❌ Need full audit trail and rollback history
- ❌ Deploying more than once per week (too slow manually)
🎤 One-Line Answer for Interview
"Avoid Change Sets for multi-developer teams, component deletion, automation needs, or frequent deployments — these require SFDX with Metadata API and Git-based version control."
🏖️ Section 2 — Sandboxes
Q11–Q20 · Beginner to Intermediate · Core Admin Knowledge
Q11
What are the four types of Salesforce Sandboxes?
✅ Direct Answer
Developer (200MB, no data), Developer Pro (1GB, no data), Partial Copy (5GB, sample data via template, 5-day refresh), and Full (complete production clone including all data, 29-day refresh).
📊 Sandbox Types
| Type | Data Storage | Data Copied | Refresh | Use Case |
|---|---|---|---|---|
| Developer | 200MB | None | 1 day | Individual dev |
| Developer Pro | 1GB | None | 1 day | Larger datasets |
| Partial Copy | 5GB | Sample (template) | 5 days | QA testing |
| Full | Same as prod | All data | 29 days | UAT / training |
🎤 One-Line Answer for Interview
"Four sandbox types — Developer (200MB, no data), Developer Pro (1GB), Partial Copy (5GB, sample data, 5-day refresh), Full (complete production clone, 29-day refresh)."
Q12
What is a Sandbox Refresh and what happens during it?
✅ Direct Answer
A Sandbox Refresh completely wipes and recreates the sandbox from production. All sandbox-specific changes are lost. Metadata and (for Partial/Full) data are copied fresh from production.
🔑 Key Points
- All sandbox-only customizations not in production are LOST
- User passwords reset — login at test.salesforce.com with email.sandboxname
- Integrations need reconfiguring to point to test endpoints
- Must wait minimum refresh interval before refreshing again
🎤 One-Line Answer for Interview
"Sandbox Refresh completely wipes and rebuilds from production — all sandbox-only changes are lost, passwords reset, and integrations must be reconfigured."
Q13
What is a Sandbox Template?
✅ Direct Answer
A Sandbox Template defines which objects and how many records are copied into a Partial Copy sandbox. Without a template, Salesforce randomly copies up to 10,000 records per object — templates give you control over the data subset.
🏢 XYZ Company Example
XYZ Company's template includes Accounts (500 records), Contacts (2,000), Opportunities (1,000), and all Products — enough for realistic QA testing without hitting the 5GB limit. Without a template, the random 10K per object selection would include irrelevant historical data.
🎤 One-Line Answer for Interview
"A Sandbox Template controls which objects and how many records populate a Partial Copy sandbox — without one, Salesforce randomly picks up to 10,000 records per object."
Q14
What is the difference between a Sandbox and a Scratch Org?
✅ Direct Answer
Sandboxes are persistent, copied from production, used for QA/UAT/training. Scratch Orgs are temporary (max 30 days), created from a definition file, source-driven, used for feature development with no production data.
📊 Comparison
| Feature | Sandbox | Scratch Org |
|---|---|---|
| Lifespan | Permanent | Max 30 days |
| Source | Copied from production | Definition file (JSON) |
| Data | Can copy production data | No production data |
| Version Control | Limited | Fully source-driven |
| Best For | UAT, QA, training | Feature development, CI/CD |
🎤 One-Line Answer for Interview
"Sandboxes are persistent production copies for QA/UAT — Scratch Orgs are temporary 30-day definition-based environments for source-driven development. Sandboxes for testing, Scratch Orgs for coding."
Q15
How do you activate sandbox users after a refresh?
✅ Direct Answer
After refresh, all passwords reset. Users log in at test.salesforce.com with their production email suffixed by the sandbox name (user@company.com.sandboxname) and use Forgot Password. Admins can also reset passwords manually in Setup → Users.
🎤 One-Line Answer for Interview
"After refresh, passwords reset — users log in at test.salesforce.com with email.sandboxname format and reset password via Forgot Password or admin resets in Setup."
Q16
What is Sandbox Seeding?
✅ Direct Answer
Sandbox seeding is populating a Developer sandbox with test data after creation. Since Developer sandboxes contain no production data, you seed them using Data Loader, Dataloader.io, or a Test Data Factory Apex class.
🏢 XYZ Company Example
XYZ Company maintains a TestDataFactory Apex class that creates Accounts, Contacts, Products, Pricelists, and Orders with a single method call — seeding a fresh Developer sandbox in under 5 minutes after every refresh.
🎤 One-Line Answer for Interview
"Sandbox seeding populates Developer sandboxes with test data using Data Loader, Dataloader.io, or a Test Data Factory class — since Developer sandboxes contain no production data after creation."
Q17
Can you deploy FROM production TO sandbox using Change Sets?
✅ Direct Answer
NO — Change Sets are one-directional: sandbox to production (or sandbox to sandbox). To sync a sandbox with production, refresh the sandbox. To backport a specific fix, use SFDX CLI to retrieve from production and deploy to sandbox.
🎤 One-Line Answer for Interview
"No — Change Sets cannot deploy from production to sandbox. Use sandbox refresh to sync, or SFDX CLI to retrieve specific components from production and deploy to sandbox."
Q18
What is a Dev Hub?
✅ Direct Answer
A Dev Hub is a production org enabled to create and manage Scratch Orgs. It is the central control point for all Scratch Org-based development and is required for SFDX source-driven workflows. Enable in Setup → Dev Hub.
📊 Dev Hub Key Facts
| Feature | Detail |
|---|---|
| Enable | Setup → Dev Hub → Enable |
| Active Scratch Org limit | 40 (default) |
| Daily creation limit | 80 |
| Authenticate CLI | sf org login web --set-default-dev-hub |
🎤 One-Line Answer for Interview
"A Dev Hub is a production org enabled to create and manage Scratch Orgs — required for SFDX development, enable in Setup → Dev Hub, limit 40 active Scratch Orgs by default."
Q19
What is the difference between a Full Sandbox and production?
✅ Direct Answer
Full Sandbox is an exact production clone — same data, same metadata — but with different login URL (test.salesforce.com), modified usernames, suppressed emails by default, and integrations that must be reconfigured to test endpoints.
🎤 One-Line Answer for Interview
"Full Sandbox is a complete production clone with the same data and metadata — key differences are login URL, suppressed emails, modified usernames, and integrations needing reconfiguration."
Q20
How do you handle email deliverability in a sandbox?
✅ Direct Answer
By default, sandboxes use "System email only" — only system emails (password resets) are sent. Change to "All email" only with test data. Best practice: use an Email Relay to redirect all sandbox emails to an internal mailbox to prevent accidental customer communication.
📊 Deliverability Settings
| Setting | Emails Sent | Use Case |
|---|---|---|
| No access | None | Fully isolated |
| System email only | System only | Default sandbox setting |
| All email | All (including customers!) | Use only with test data + relay |
🎤 One-Line Answer for Interview
"Sandbox email defaults to system-only. Set to All Email only with an Email Relay redirecting to internal addresses — prevents real customers from receiving test emails."
⚡ Section 3 — SFDX & Salesforce CLI
Q21–Q30 · Intermediate to Advanced · Must-Know for Developer Roles
Q21
What is Salesforce DX (SFDX) and why was it introduced?
✅ Direct Answer
Salesforce DX is a source-driven development approach using Git, Salesforce CLI, and Scratch Orgs. It was introduced to solve org-based development limitations — no version control, no parallel development, no automation.
📊 Org-Based vs Source-Driven
| Aspect | Org-Based (Old) | Source-Driven (SFDX) |
|---|---|---|
| Source of Truth | The org itself | Git repository |
| Version Control | ❌ No | ✅ Yes |
| Team Collaboration | Manual, conflict-prone | Branch-based, clean |
| CI/CD | ❌ Limited | ✅ Full |
| Environment | Shared sandbox | Individual Scratch Orgs |
🎤 One-Line Answer for Interview
"Salesforce DX is a source-driven development model using CLI, Git, and Scratch Orgs — introduced to bring version control, team collaboration, and CI/CD automation to Salesforce development."
Q22
What are the essential Salesforce CLI commands every developer must know?
✅ Direct Answer
The essential commands cover org authentication, project setup, metadata push/pull, deployment, and testing — these are the daily commands every SFDX developer uses.
📊 Essential Commands
| Command | Purpose |
|---|---|
| sf org login web | Authenticate to an org |
| sf org create scratch | Create a new Scratch Org |
| sf project deploy start | Deploy metadata to org |
| sf project retrieve start | Retrieve metadata from org |
| sf apex run test | Run Apex tests |
| sf org open | Open org in browser |
| sf org list | List all authenticated orgs |
💡 Key Commands with Code
# Authenticate to sandbox
sf org login web --alias mysandbox --instance-url https://test.salesforce.com
# Deploy all source
sf project deploy start --source-dir force-app --target-org mysandbox
# Run all tests with coverage
sf apex run test --target-org mysandbox --code-coverage --result-format human
🎤 One-Line Answer for Interview
"Essential SF CLI: sf org login web (authenticate), sf project deploy start (deploy), sf project retrieve start (retrieve), sf apex run test (run tests) — master these for daily SFDX development."
Q23
What is the structure of a Salesforce DX project?
✅ Direct Answer
An SFDX project has sfdx-project.json as the config file, force-app/ as the default source directory (organized by metadata type), and config/ for scratch org definition files. Metadata is stored in source format — more granular than metadata API format.
💡 Project Structure
my-sf-project/
├── sfdx-project.json # Project config
├── .forceignore # Ignore file
├── config/
│ └── project-scratch-def.json
├── force-app/
│ └── main/default/
│ ├── classes/ # Apex classes
│ ├── lwc/ # LWC components
│ ├── objects/ # Custom objects & fields
│ ├── flows/ # Flows
│ └── triggers/ # Apex triggers
🎤 One-Line Answer for Interview
"An SFDX project is structured around sfdx-project.json (config) and force-app/main/default/ (source by metadata type) — metadata lives in Git, not in an org."
Q24
What is the difference between sf project deploy and sf project retrieve?
✅ Direct Answer
Deploy pushes metadata FROM your local project TO the org. Retrieve pulls metadata FROM the org TO your local project. Always retrieve after declarative changes made in the org UI to keep Git as the source of truth.
🎤 One-Line Answer for Interview
"Deploy pushes local source to org; Retrieve pulls org changes to local — always retrieve after declarative org changes to keep Git as the single source of truth."
Q25
What is the .forceignore file?
✅ Direct Answer
.forceignore is the SFDX equivalent of .gitignore — it tells the Salesforce CLI which files and metadata to ignore during deploy and retrieve operations, preventing unwanted metadata from being pushed to orgs or committed to Git.
💡 Common .forceignore Entries
# Ignore managed package components
**/SBQQ__*
# Ignore standard profiles (too large)
**/profiles/Admin.profile-meta.xml
# Ignore LWC jest tests
**/__tests__/**
# Ignore org-specific settings
**/settings/OrgPreference.settings-meta.xml
🎤 One-Line Answer for Interview
".forceignore works like .gitignore for Salesforce CLI — list metadata types and file patterns to exclude from deploy and retrieve, such as managed packages, standard profiles, and org-specific settings."
Q26
What is the sfdx-project.json file?
✅ Direct Answer
sfdx-project.json is the main configuration file for an SFDX project — defines package directories (source paths), Salesforce API version, namespace, and package aliases. The CLI reads this file for every operation.
🎤 One-Line Answer for Interview
"sfdx-project.json is the SFDX project config defining source directories, API version, namespace, and package aliases — the entry point the CLI reads for every command."
Q27
How do you deploy destructive changes using SFDX?
✅ Direct Answer
Use a destructiveChanges.xml (post-deployment deletion) or destructiveChangesPre.xml (pre-deployment deletion) alongside an empty package.xml. This is the only way to programmatically delete metadata components from an org.
💡 Destructive Changes Command
# Deploy with post-destructive changes (delete AFTER deploy)
sf project deploy start \
--manifest package.xml \
--post-destructive-changes destructiveChanges.xml \
--target-org production
# destructiveChanges.xml example
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>OldApexClass</members>
<name>ApexClass</name>
</types>
</Package>
🎤 One-Line Answer for Interview
"Destructive changes use destructiveChangesPre.xml (delete before deploy) or destructiveChanges.xml (delete after deploy) with an empty package.xml — the only programmatic way to delete Salesforce metadata."
Q28
What is the difference between metadata format and source format?
✅ Direct Answer
Metadata format (traditional) stores components as single large XML files. Source format (SFDX) breaks components into smaller granular files per element — making Git diffs clean and conflict resolution easy for team development.
📊 Format Comparison
| Aspect | Metadata Format | Source Format |
|---|---|---|
| Custom Object | One large XML file | Separate files per field/layout |
| Git diff | Hard to read | Clean, granular |
| Used By | ANT, Workbench | SFDX sf CLI |
🎤 One-Line Answer for Interview
"Metadata format = single large XML per component. Source format = granular files per element — source format is better for Git diffs, code reviews, and team collaboration."
Q29
How do you run specific Apex tests using Salesforce CLI?
✅ Direct Answer
Use sf apex run test with options to run all tests, specific classes, specific methods, or synchronously. Always use --code-coverage to get coverage results required for production validation.
💡 Test Commands
# Run specific class
sf apex run test --class-names VisitReportControllerTest --target-org mysandbox
# Run specific method
sf apex run test --tests VisitReportControllerTest.testGetVisits --target-org mysandbox
# Run synchronously with coverage
sf apex run test --synchronous --code-coverage --result-format human --target-org mysandbox
🎤 One-Line Answer for Interview
"Use sf apex run test with --class-names for specific classes, --tests for specific methods, and always --code-coverage — use --synchronous to wait for results before continuing."
Q30
What changed from sfdx CLI to sf CLI?
✅ Direct Answer
Salesforce unified the sfdx CLI into the new sf CLI in 2022 with shorter, more intuitive commands. Old sfdx commands still work but are deprecated — always use sf commands in new projects.
📊 Old vs New Commands
| Action | Old sfdx | New sf |
|---|---|---|
| Authenticate | sfdx force:auth:web:login | sf org login web |
| Deploy | sfdx force:source:deploy | sf project deploy start |
| Run tests | sfdx force:apex:test:run | sf apex run test |
| Create Scratch | sfdx force:org:create | sf org create scratch |
🎤 One-Line Answer for Interview
"The old sfdx CLI (sfdx force:*) is deprecated — use the new sf CLI (sf *) with shorter, more intuitive commands in all new projects."
🔬 Section 4 — Scratch Orgs
Q31–Q38 · Intermediate · Key for SFDX Developer Interviews
Q31
What is a Scratch Org Definition File?
✅ Direct Answer
The Scratch Org Definition File (project-scratch-def.json) is a JSON blueprint that defines features, settings, and capabilities a Scratch Org should have when created. It ensures every developer gets a consistent environment.
💡 Sample Definition File
{
"orgName": "XYZ Company Dev",
"edition": "Developer",
"features": ["Communities", "ServiceCloud", "MultiCurrency"],
"settings": {
"lightningExperienceSettings": {
"enableS1DesktopEnabled": true
}
}
}
🎤 One-Line Answer for Interview
"The Scratch Org Definition File is a JSON blueprint defining features, settings, and edition for a new Scratch Org — ensuring every developer gets an identical, consistent environment."
Q32
What are the limits of Scratch Orgs?
✅ Direct Answer
Scratch Orgs max lifespan is 30 days (default 7 days), 40 active orgs per Dev Hub, 80 daily creation limit, and 200MB data storage.
📊 Scratch Org Limits
| Limit | Value |
|---|---|
| Max lifespan | 30 days |
| Default lifespan | 7 days |
| Active orgs per Dev Hub | 40 |
| Daily creation limit | 80 |
| Data + file storage | 200MB each |
🎤 One-Line Answer for Interview
"Scratch Orgs max 30 days lifespan, 40 active and 80 daily per Dev Hub, 200MB storage — always commit to Git before expiry as expired Scratch Orgs are permanently deleted."
Q33
What happens when a Scratch Org expires?
✅ Direct Answer
When a Scratch Org expires it becomes inaccessible and all data and configuration is permanently lost. Any code not committed to Git or pushed to another org is gone forever — this is why Git commits are non-negotiable in SFDX.
🔑 Before Expiry Checklist
- ✅ Commit all code changes to Git feature branch
- ✅ Retrieve any declarative changes (Flows, Layouts)
- ✅ Export any important test data
- ✅ Document any manual org settings changed
🎤 One-Line Answer for Interview
"Expired Scratch Orgs are permanently deleted — always commit all work to Git and retrieve declarative changes before expiry; there is no way to recover an expired Scratch Org."
Q34
How do you push and pull source in a Scratch Org?
✅ Direct Answer
Use sf project deploy start to push local source to a Scratch Org, and sf project retrieve start to pull org changes back. Always pull after making declarative changes in the Scratch Org UI before committing to Git.
🎤 One-Line Answer for Interview
"sf project deploy start pushes local to Scratch Org; sf project retrieve start pulls org changes to local — always retrieve after declarative UI changes before committing to Git."
Q35
What is the difference between sf org create scratch and sf org create sandbox?
✅ Direct Answer
sf org create scratch creates a temporary definition-based Scratch Org (requires Dev Hub). sf org create sandbox creates a persistent production copy (requires sandbox license). Scratch Orgs for coding, sandboxes for testing.
🎤 One-Line Answer for Interview
"create scratch = temporary definition-based org for development (needs Dev Hub). create sandbox = persistent production copy for testing (needs sandbox license)."
Q36
How do you share a Scratch Org with another developer?
✅ Direct Answer
Scratch Orgs are designed as individual environments — the correct way to collaborate is through Git branches, not org sharing. If needed, another developer can authenticate using the access token from sf org display.
🎤 One-Line Answer for Interview
"Scratch Orgs are individual environments — collaborate through Git branches. If sharing is needed, use the access token from sf org display --verbose for another developer to authenticate."
Q37
What are Scratch Org Snapshots?
✅ Direct Answer
Scratch Org Snapshots (Beta) save the current state of a Scratch Org as a reusable template. New Scratch Orgs created from a snapshot skip setup time — making developer onboarding and CI/CD much faster.
🎤 One-Line Answer for Interview
"Scratch Org Snapshots save a configured org state as a reusable template — new orgs from the snapshot skip setup time, significantly speeding up developer onboarding and CI/CD pipelines."
Q38
How do you handle org-specific settings that cannot go into version control?
✅ Direct Answer
Org-specific secrets like Named Credential URLs, API keys, and Connected App consumer secrets should never be stored in Git. Use environment variables, GitHub Secrets, and post-deployment scripts to configure them per environment.
📊 What Goes Where
| Item | In Git? | Alternative |
|---|---|---|
| Apex code | ✅ Yes | — |
| Named Credential URL | ⚠️ Template only | Environment variable |
| API keys / secrets | ❌ Never | Secrets manager |
🎤 One-Line Answer for Interview
"Org-specific secrets never go in Git — use environment variables, GitHub Secrets, and post-deployment scripts to configure Named Credentials, API keys, and endpoints per environment."
📦 Section 5 — Salesforce Packages
Q39–Q46 · Intermediate to Advanced · ISV & Enterprise Dev Knowledge
Q39
What are the three types of Salesforce Packages?
✅ Direct Answer
Unmanaged (open code, no upgrades), Managed (locked IP, upgradeable, for AppExchange ISVs), and Unlocked (open code, upgradeable, modern standard for internal modular development).
📊 Package Types
| Feature | Unmanaged | Managed | Unlocked |
|---|---|---|---|
| Code visible? | ✅ Yes | ❌ No | ✅ Yes |
| Upgradeable? | ❌ No | ✅ Yes | ✅ Yes |
| Namespace | Optional | Required | Optional |
| Best For | Templates | AppExchange ISVs | Internal modular dev |
🎤 One-Line Answer for Interview
"Three package types — Unmanaged (open, no upgrades), Managed (locked IP for AppExchange), Unlocked (open, upgradeable for internal teams) — Unlocked Packages are the modern recommended approach."
Q40
What are Unlocked Packages and why are they the future?
✅ Direct Answer
Unlocked Packages are a modern packaging model supporting modular development, versioning, and upgradeability with open source code. They are the recommended approach for internal Salesforce teams adopting DevOps practices.
🔑 Key Advantages
- ✅ Source code visible and modifiable
- ✅ Supports versioning and upgrades
- ✅ Enforces modular architecture
- ✅ Works with SFDX and CI/CD pipelines
- ✅ No namespace required
- ✅ Dependency management between packages
🎤 One-Line Answer for Interview
"Unlocked Packages are the modern Salesforce packaging standard — modular, versioned, upgradeable, open source, and fully CI/CD compatible for enterprise development."
Q41
What is a Package Version and how does versioning work?
✅ Direct Answer
A Package Version is a point-in-time snapshot using major.minor.patch.build format (e.g., 1.2.0.1). Released versions are immutable — create new versions for updates. Beta versions test-only, Released versions install in production.
🎤 One-Line Answer for Interview
"Package versions use major.minor.patch.build — create with sf package version create, promote to Released with sf package version promote before production install."
Q42
What is the difference between Beta and Released package versions?
✅ Direct Answer
Beta versions install only in Scratch Orgs and sandboxes. Released versions (promoted) are immutable and install in any org including production. Use sf package version promote to make a version Released.
🎤 One-Line Answer for Interview
"Beta = sandbox testing only. Released = promoted, immutable, installable in production. Run sf package version promote to release — released versions cannot be modified."
Q43
What is a package dependency?
✅ Direct Answer
A package dependency means one package requires another to be installed first. Declared in sfdx-project.json — if Package B depends on Package A, Package A must always be installed before Package B in any org.
🎤 One-Line Answer for Interview
"Package dependencies declare installation order in sfdx-project.json — dependent packages are always installed after their prerequisites."
Q44
What is a Managed Package and how is it different for ISVs?
✅ Direct Answer
Managed Packages protect Apex code (subscribers cannot view), require a namespace prefix (e.g., SBQQ__ for Salesforce CPQ), support push upgrades to all subscribers, and require AppExchange Security Review for distribution.
🎤 One-Line Answer for Interview
"Managed Packages protect source code with a namespace, support push upgrades to all subscribers, and require AppExchange listing and Security Review — built for ISVs selling on AppExchange."
Q45
How do you uninstall a Salesforce package?
✅ Direct Answer
Uninstall via Setup → Installed Packages → Uninstall, or CLI with sf package uninstall. Delete all package object records and remove org dependencies first — otherwise uninstall will fail.
🎤 One-Line Answer for Interview
"Uninstall via Setup → Installed Packages or sf package uninstall — delete all package object records and remove dependencies first, or the uninstall will fail."
Q46
What is the difference between 1GP and 2GP packaging?
✅ Direct Answer
1GP (First Generation Packaging) is the legacy org-based model built in a packaging org via UI. 2GP (Second Generation Packaging) is SFDX-based, CLI-driven, supports Scratch Orgs, Git integration, and CI/CD — all new packages should use 2GP.
📊 1GP vs 2GP
| Feature | 1GP | 2GP |
|---|---|---|
| Development | Org-based | Source-driven (SFDX) |
| Version Control | Limited | Full Git |
| CI/CD | Limited | ✅ Full |
| Scratch Org | ❌ No | ✅ Yes |
🎤 One-Line Answer for Interview
"1GP is legacy org-based packaging. 2GP is modern SFDX-based with Git, CI/CD, and Scratch Org support — all new packages should use 2GP."
🔄 Section 6 — CI/CD Pipelines
Q47–Q54 · Advanced · High Value for Senior Developer Interviews
Q47
What is a CI/CD pipeline in Salesforce?
✅ Direct Answer
A CI/CD pipeline automates validation, testing, and deployment of Salesforce metadata whenever a developer pushes to a Git branch. It eliminates manual deployment steps and ensures every release is automatically tested before reaching production.
📊 Typical Salesforce CI/CD Pipeline
| Stage | Action | Tool |
|---|---|---|
| Code Push | Developer pushes to feature branch | Git |
| CI — Validate | Validate metadata in sandbox | SF CLI |
| CI — Test | Run all Apex tests | SF CLI |
| Code Review | Pull Request review | GitHub |
| CD — Deploy | Deploy to staging/production | SF CLI + Pipeline |
🎤 One-Line Answer for Interview
"A Salesforce CI/CD pipeline automates validation, testing, and deployment — every PR triggers automatic validation and testing, and merges trigger automatic production deployment."
Q48
How do you authenticate Salesforce CLI non-interactively in CI/CD?
✅ Direct Answer
Use JWT-based authentication with a Connected App and private key, or SFDX Auth URL stored as an encrypted pipeline secret. Browser-based login is not possible in automated pipelines.
💡 GitHub Actions Authentication
# Store SFDX_AUTH_URL in GitHub Secrets, then:
- name: Authenticate to Salesforce
run: |
echo "${{ secrets.SFDX_AUTH_URL }}" > auth.txt
sf org login sfdx-url --sfdx-url-file auth.txt --alias production
# Or JWT (more secure):
sf org login jwt \
--username user@company.com \
--jwt-key-file server.key \
--client-id ${{ secrets.SF_CONSUMER_KEY }} \
--instance-url https://login.salesforce.com
🎤 One-Line Answer for Interview
"CI/CD pipelines authenticate non-interactively using JWT (sf org login jwt with Connected App) or SFDX Auth URL (sf org login sfdx-url) stored as encrypted pipeline secrets."
Q49
What is a GitHub Actions workflow for Salesforce?
✅ Direct Answer
A GitHub Actions workflow is a YAML file in .github/workflows/ triggered by Git events. For Salesforce, it installs SF CLI, authenticates via secrets, validates/deploys metadata, and runs Apex tests automatically on every PR.
💡 Sample Workflow
name: Salesforce CI
on:
pull_request:
branches: [main]
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Install SF CLI
run: npm install -g @salesforce/cli
- name: Authenticate
run: |
echo "$SFDX_AUTH_URL" > auth.txt
sf org login sfdx-url -f auth.txt -a sandbox
env:
SFDX_AUTH_URL: ${{ secrets.SANDBOX_AUTH_URL }}
- name: Validate
run: sf project deploy validate --manifest package.xml --target-org sandbox --test-level RunLocalTests
🎤 One-Line Answer for Interview
"A GitHub Actions workflow is a YAML file in .github/workflows/ that installs SF CLI, authenticates via secrets, validates metadata, and runs Apex tests automatically on every pull request."
Q50
What is the difference between RunLocalTests, RunAllTestsInOrg, and RunSpecifiedTests?
✅ Direct Answer
RunLocalTests runs all non-managed package tests (production standard). RunAllTestsInOrg runs every test including managed. RunSpecifiedTests runs only named classes — fastest for CI/PR validation. NoTestRun skips all tests (sandboxes only).
📊 Test Level Comparison
| Test Level | Runs | Speed | Best For |
|---|---|---|---|
| NoTestRun | None | Fastest | Sandbox, non-code changes |
| RunSpecifiedTests | Named classes only | Fast | CI/PR validations |
| RunLocalTests | All non-managed | Medium | Production deployment |
| RunAllTestsInOrg | Every test | Slowest | Full org validation |
🎤 One-Line Answer for Interview
"RunLocalTests = production standard (all non-managed). RunSpecifiedTests = fastest for CI/PR. RunAllTestsInOrg = slowest, includes managed packages. NoTestRun = sandboxes only."
Q51
What is a Salesforce branching strategy for CI/CD?
✅ Direct Answer
The standard Salesforce Gitflow maps feature branches to Scratch Orgs, develop to integration sandbox, release to UAT, and main to production — each merge triggers automated deployment to the next environment.
📊 Gitflow Mapping
| Branch | Environment | Trigger |
|---|---|---|
| feature/* | Developer Scratch Org | Manual push |
| develop | Integration Sandbox | PR merge → auto deploy |
| release/* | UAT / Full Sandbox | PR merge → auto deploy |
| main | Production | PR merge → auto deploy |
🎤 One-Line Answer for Interview
"Salesforce Gitflow: feature → Scratch Org, develop → QA sandbox, release → UAT, main → production — each merge triggers automated CI/CD deployment to the next environment."
Q52
What is Copado and how does it compare to GitHub Actions?
✅ Direct Answer
Copado is a paid native Salesforce DevOps platform with UI-based CI/CD, advanced testing, compliance, and AI features. GitHub Actions is free, YAML-based, highly flexible. Copado for enterprise/admin teams, GitHub Actions for developer-led teams.
🎤 One-Line Answer for Interview
"Copado is a paid UI-based enterprise DevOps platform. GitHub Actions is free YAML-based CI/CD — use Copado for admin-led teams wanting clicks, GitHub Actions for developer-led teams wanting flexibility."
Q53
How do you handle merge conflicts in an SFDX project?
✅ Direct Answer
SFDX merge conflicts are standard Git conflicts — resolved using your Git tool. Source format's granular files make conflicts rarer than metadata format's single large XMLs. Always pull latest before starting work and use feature branches.
🎤 One-Line Answer for Interview
"SFDX conflicts are standard Git conflicts — source format's granular files make them rarer. Always use feature branches, pull latest before starting work, and resolve in VS Code before deploying."
Q54
What is sf project deploy validate and when do you use it?
✅ Direct Answer
sf project deploy validate performs a dry-run deployment — checks for errors and runs Apex tests WITHOUT making changes. Used in CI pipelines to validate PRs and as a pre-deployment check enabling Quick Deploy afterward.
🎤 One-Line Answer for Interview
"sf project deploy validate is a dry-run that checks errors and runs tests without changes — enables Quick Deploy afterward and is the standard gate in every production deployment."
🏗️ Section 7 — DevOps Center
Q55–Q61 · Intermediate · Growing Topic in 2026 Interviews
Q55
What is Salesforce DevOps Center?
✅ Direct Answer
DevOps Center is Salesforce's native UI-based DevOps tool providing source-driven development and deployment without requiring CLI expertise. It connects to GitHub, manages work items, and supports pipeline-based releases — bridging the gap between Change Sets and full SFDX.
📊 DevOps Center vs Change Sets
| Feature | Change Sets | DevOps Center |
|---|---|---|
| Version Control | ❌ No | ✅ Yes (GitHub) |
| UI-based | ✅ Yes | ✅ Yes |
| Audit trail | Limited | Full |
| Work items | ❌ No | ✅ Yes |
| CLI required | ❌ No | ❌ No |
🎤 One-Line Answer for Interview
"DevOps Center is Salesforce's free native UI-based DevOps tool bringing Git, work items, and pipeline deployment to admins — without needing CLI knowledge."
Q56
What are Work Items in DevOps Center?
✅ Direct Answer
Work Items are the unit of work tracking a set of metadata changes (feature or bug fix) through the deployment pipeline. Each Work Item auto-creates a GitHub branch and bundles related components for promotion through environments.
🎤 One-Line Answer for Interview
"Work Items bundle related metadata changes and move through the pipeline — each auto-creates a GitHub branch and tracks promotion from development sandbox to production."
Q57
How does DevOps Center connect to GitHub?
✅ Direct Answer
DevOps Center connects via OAuth during project setup, installing a GitHub App that manages branch creation, commits, and pull requests on behalf of your team — no developer needs to know Git commands.
🎤 One-Line Answer for Interview
"DevOps Center connects to GitHub via OAuth and a GitHub App installation — it manages branch creation, commits, and PRs automatically, no Git CLI knowledge required."
Q58
What is a Pipeline in DevOps Center?
✅ Direct Answer
A Pipeline is a sequence of connected org stages (Dev → QA → UAT → Production) through which Work Items are promoted. Each stage represents a Salesforce org and defines the release path for metadata changes.
🎤 One-Line Answer for Interview
"A DevOps Center Pipeline is a sequence of org stages — Work Items are promoted stage by stage from Development through QA to Production with automatic GitHub commits at each promotion."
Q59
What is the difference between DevOps Center and Copado?
✅ Direct Answer
DevOps Center is free and native with basic pipeline functionality. Copado is a paid AppExchange solution with advanced testing, compliance tracking, AI-powered conflict resolution, and enterprise-scale release management.
🎤 One-Line Answer for Interview
"DevOps Center is free, basic, native Salesforce. Copado is paid, enterprise-grade with AI, compliance, and advanced testing — DevOps Center for SMBs, Copado for enterprise."
Q60
Can DevOps Center and SFDX CLI be used together?
✅ Direct Answer
YES — both use the same GitHub repository. Developers push via CLI, admins use DevOps Center UI for declarative changes. Both commit to the same repo and the same pipeline promotes all changes together.
🎤 One-Line Answer for Interview
"Yes — DevOps Center and SF CLI both commit to the same GitHub repo. Developers use CLI for code, admins use DevOps Center for declarative changes — perfect complements in one pipeline."
Q61
What are the limitations of DevOps Center?
✅ Direct Answer
GitHub only (no Bitbucket/GitLab), no built-in automated test execution, no data deployment, limited conflict detection, no deployment scheduling, and requires DX-format metadata.
🔑 Key Limitations
- ❌ GitHub only — no Bitbucket, GitLab, Azure DevOps
- ❌ No automated test execution built in
- ❌ No data deployment support
- ❌ Limited conflict detection
- ❌ No deployment scheduling
🎤 One-Line Answer for Interview
"DevOps Center limitations: GitHub only, no automated testing, no data deployment, limited conflict resolution — combine with GitHub Actions or use Copado for enterprise needs."
🛠️ Section 8 — Deployment Tools
Q62–Q67 · Beginner to Intermediate · Practical Knowledge
Q62
What are the main Salesforce deployment tools?
✅ Direct Answer
Main tools: Change Sets (UI, simple), Salesforce CLI/SFDX (developer standard), Workbench (web-based metadata), Ant Migration Tool (legacy/deprecated), Gearset (third-party, visual), and Copado (enterprise DevOps).
📊 Tool Comparison
| Tool | Best For | CI/CD? | Cost |
|---|---|---|---|
| Change Sets | Simple deployments | ❌ | Free |
| Salesforce CLI | Developer workflows | ✅ | Free |
| Workbench | Quick metadata ops | ❌ | Free |
| Gearset | Visual comparison, backup | ✅ | Paid |
| Copado | Enterprise DevOps | ✅ | Paid |
🎤 One-Line Answer for Interview
"Main tools: Change Sets (simple UI), SF CLI (developer standard), Workbench (quick ops), Gearset/Copado (enterprise) — SF CLI with GitHub Actions is the modern professional standard."
Q63
What is Workbench and what can you do with it?
✅ Direct Answer
Workbench (workbench.developerforce.com) is a free web-based tool for Salesforce API interaction — SOQL queries, REST API exploration, metadata deploy/retrieve via ZIP, and bulk data operations without installing any software.
🎤 One-Line Answer for Interview
"Workbench is a free web tool for SOQL queries, REST API testing, metadata deploy/retrieve, and bulk operations — no software installation required, ideal for quick developer tasks."
Q64
What is Gearset and why do teams use it?
✅ Direct Answer
Gearset is a popular third-party Salesforce DevOps tool known for intelligent metadata comparison, automated deployment, daily backup, CI/CD integration, and one-click rollback — easier to set up than custom GitHub Actions pipelines.
🎤 One-Line Answer for Interview
"Gearset provides visual org comparison, automated dependency resolution, daily backups, and one-click rollback — popular for teams wanting easier DevOps setup than custom CI/CD pipelines."
Q65
What is the Ant Migration Tool and is it still relevant?
✅ Direct Answer
The Ant Migration Tool is a legacy Java/Apache Ant-based deployment tool using Metadata API. It is officially deprecated — Salesforce recommends migrating to SF CLI which does everything Ant does and more.
🎤 One-Line Answer for Interview
"Ant Migration Tool is deprecated — it still works but Salesforce recommends SF CLI as the replacement. You may see it in legacy projects but never use it for new implementations."
Q66
How do you deploy metadata using a package.xml file?
✅ Direct Answer
package.xml is a manifest file listing all metadata components to include in a deployment or retrieval. Used with the --manifest flag in SF CLI for precise component control in production deployments.
💡 Sample package.xml
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>VisitReportController</members>
<name>ApexClass</name>
</types>
<types>
<members>visitReport</members>
<name>LightningComponentBundle</name>
</types>
<version>63.0</version>
</Package>
# Deploy using package.xml
sf project deploy start --manifest package.xml --target-org production
🎤 One-Line Answer for Interview
"package.xml is a manifest listing metadata types and members — use sf project deploy start --manifest package.xml for precise component selection in production deployments."
Q67
What is the difference between deploy and validate in SF CLI?
✅ Direct Answer
sf project deploy validate does a dry-run — runs tests, checks errors, makes no changes. sf project deploy start makes actual changes. Quick Deploy (sf project deploy quick) uses cached validation to deploy instantly within 10 days.
🎤 One-Line Answer for Interview
"Validate = dry-run with tests, no changes. Deploy = actual changes. Quick Deploy = instant deploy using cached validation — always validate first, then Quick Deploy to minimize production downtime."
🎯 Section 9 — Scenario-Based Questions
Q68–Q75 · Advanced · Most Unique Section — Hardest to Find Elsewhere
Q68
SCENARIO: Your Change Set deployment to production failed due to Apex test failures. What do you do?
✅ Direct Answer
Salesforce auto-rolls back on failure — production is safe. Read the error log, fix the failing test in the source sandbox, re-upload the Change Set with the fix, validate first to confirm, then deploy.
📊 Step-by-Step Recovery
| Step | Action |
|---|---|
| 1 | Read the exact test failure error in deployment log |
| 2 | Reproduce failure in sandbox (run same test class) |
| 3 | Fix the Apex test or code causing the failure |
| 4 | Re-upload Change Set with fixed components |
| 5 | Validate first in production |
| 6 | Quick Deploy after successful validation |
🏢 XYZ Company Example
At XYZ Company, a Change Set failed because a new trigger broke an existing test class. The developer added a Test.isRunningTest() check, fixed the test, re-uploaded, validated, and used Quick Deploy — completing the release with only 20 extra minutes of delay.
🎤 One-Line Answer for Interview
"Change Set failure auto-rolls back production — fix the issue in sandbox, re-upload corrected components, validate first to confirm, then Quick Deploy to minimize downtime."
Q69
SCENARIO: Two developers made changes to the same Apex class in different sandboxes. How do you merge?
✅ Direct Answer
With Git (SFDX): merge via Git feature branches and pull request with conflict resolution in VS Code. Without Git (Change Sets): manually compare both files, copy-paste the correct logic — the second Change Set deployment will overwrite the first.
🏢 XYZ Company Example
Before SFDX, two XYZ Company developers modified the same AccountTriggerHandler in different sandboxes — the second deployment silently overwrote the first. After adopting Git with feature branches and PRs, conflicts are visible, reviewed, and resolved before any deployment. Zero lost work.
🎤 One-Line Answer for Interview
"Without Git, the second Change Set silently overwrites the first. With SFDX + Git branches, conflicts are visible and resolved via PR review — this is the #1 reason to adopt SFDX."
Q70
SCENARIO: You need to delete a custom field referenced in a Flow, Apex class, and Report. What is your approach?
✅ Direct Answer
Staged deletion — first remove all references, then delete the field. Salesforce blocks deletion of any field with active references. Deploy the updated Flow, Apex, and Report first, then delete the field via destructive changes.
📊 Staged Plan
| Stage | Action |
|---|---|
| 1 — Audit | Setup → Where Is This Used? to find all references |
| 2 — Update Flow | Remove field reference, deploy updated Flow |
| 3 — Update Apex | Remove field from Apex, deploy updated class |
| 4 — Update Report | Remove column from Report |
| 5 — Delete Field | Setup UI or destructiveChanges.xml |
🎤 One-Line Answer for Interview
"Delete in stages — remove all dependencies (Flows, Apex, Reports) first, confirm no runtime errors, then delete the field via Setup or destructive changes. Salesforce blocks deletion of any actively referenced field."
Q71
SCENARIO: Your CI/CD pipeline takes 45 minutes due to 800 test classes. How do you optimize?
✅ Direct Answer
Use Validate + Quick Deploy (run tests once, deploy instantly), RunSpecifiedTests for PR validations, Test Suites grouped by module, and parallel test execution — can reduce 45-minute deployments to under 5 minutes.
📊 Optimization Strategies
| Strategy | Time Saved | How |
|---|---|---|
| Validate + Quick Deploy | 30–40 min | Validate off-hours, deploy instantly |
| RunSpecifiedTests (PR) | 35 min | Map components to related test classes |
| Test Suites | 20 min | Group by module, run relevant suite |
| Parallel test execution | 15 min | Enable in Setup → Apex Test Execution |
🏢 XYZ Company Example
XYZ Company: validate every Sunday night (45 min), Quick Deploy Monday morning (under 5 min). For PRs, RunSpecifiedTests with a component-to-test mapping file cuts validation from 45 to 8 minutes per PR.
🎤 One-Line Answer for Interview
"Optimize with Validate + Quick Deploy, RunSpecifiedTests for CI, Test Suites by module, and parallel execution — can reduce 45-minute deployments to under 5 minutes."
Q72
SCENARIO: You deployed a change to production that caused critical issues. How do you roll back?
✅ Direct Answer
Salesforce has no one-click rollback. Reverse by deploying the previous version from Git history, deactivating problematic Flows (activate previous version), or manually reverting Setup changes. This is why Git is non-negotiable.
📊 Rollback by Type
| Component | Rollback Method |
|---|---|
| Apex class | Deploy previous version from Git |
| Flow | Deactivate new, activate previous version |
| Configuration | Manual revert in Setup |
| With Gearset | One-click rollback from history |
🏢 XYZ Company Example
XYZ Company deployed a trigger causing Order failures for international customers. Developer git checkout HEAD~1 the previous version, deployed to production — total downtime 12 minutes. Without Git, recovery would have been manual guesswork.
🎤 One-Line Answer for Interview
"No automatic rollback in Salesforce — deploy previous version from Git history, deactivate problematic Flows, or manually revert configs. This is why Git version control is non-negotiable."
Q73
SCENARIO: You need to deploy to an org with no deployment connection. What do you do?
✅ Direct Answer
Change Sets require deployment connections. For unrelated orgs, use SF CLI (authenticate both orgs and deploy directly) or Workbench (retrieve as ZIP from source, deploy to target) — no connection needed.
💡 CLI Approach
# Authenticate both orgs
sf org login web --alias sourceorg
sf org login web --alias targetorg
# Retrieve from source
sf project retrieve start --manifest package.xml --target-org sourceorg
# Deploy to target — no connection required
sf project deploy start --manifest package.xml --target-org targetorg
🎤 One-Line Answer for Interview
"Change Sets need connections. For unrelated orgs, use SF CLI (authenticate both, retrieve then deploy) or Workbench (retrieve as ZIP, deploy to any org) — no deployment connection required."
Q74
SCENARIO: Your team of 8 developers uses Change Sets. CTO wants modern DevOps. What do you recommend?
✅ Direct Answer
Recommend SFDX with GitHub Actions. 4-8 week phased migration: setup Git + convert org to source format → branching strategy + dev training → GitHub Actions CI/CD → Dev Hub + Scratch Orgs → deprecate Change Sets.
📊 Migration Roadmap
| Week | Milestone |
|---|---|
| 1–2 | Set up GitHub repo, install SF CLI, convert org metadata |
| 3 | Branching strategy + developer Git training |
| 4–5 | GitHub Actions workflow (validate on PR, deploy on merge) |
| 6 | Enable Dev Hub, Scratch Orgs for new features |
| 7–8 | Full team on new workflow, deprecate Change Sets |
🎤 One-Line Answer for Interview
"Migrate to SFDX + GitHub Actions in phases: setup Git and convert metadata first, establish branching strategy, build CI/CD pipelines — full migration in 6–8 weeks with proper training."
Q75
SCENARIO: Tests pass locally but fail in CI/CD pipeline. How do you debug?
✅ Direct Answer
Classic "works locally, fails in CI" — most common causes: @SeeAllData reliance on sandbox data, hard-coded IDs, missing Custom Settings/Metadata in CI org, or test order dependency.
📊 Debugging Checklist
| Check | What to Look For |
|---|---|
| Hard-coded IDs | Any Id values typed directly in test class |
| @SeeAllData | Test relying on existing sandbox data? |
| Custom Settings | Is CI org missing required configuration? |
| Async Apex | Test.startTest()/stopTest() used correctly? |
| Order dependency | Test only passes after another specific test? |
🏢 XYZ Company Example
XYZ Company's CI pipeline failed 3 pricing tests. Locally passed because sandbox had Pricebook data. The CI Scratch Org had none. Fix: use Test.getStandardPricebookId() in @testSetup — tests pass everywhere consistently.
🎤 One-Line Answer for Interview
"CI test failures that pass locally = @SeeAllData reliance, hard-coded IDs, or missing config in CI org. Fix by using Test Data Factories and never relying on existing org data in test classes."
🚀 More Free Salesforce Interview Prep
Explore all topics — Apex, LWC, SOQL, Flows, Agentforce, Data Cloud & more. 21,000+ learners this month. All completely free.
👉 Visit sfinterviewpro.com