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

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.

Questions

Sections

All

Levels

100%

Free

Browse All Topics → 150 Advanced Questions →

📋 Jump to Section

📦 Change Sets (Q1-Q10) 🏖️ Sandboxes (Q11-Q20) ⚡ SFDX & CLI (Q21-Q30) 🔬 Scratch Orgs (Q31-Q38) 📦 Packages (Q39-Q46) 🔄 CI/CD Pipelines (Q47-Q54) 🏗️ DevOps Center (Q55-Q61) 🛠️ Deployment Tools (Q62-Q67) 🎯 Scenario Based (Q68-Q75)

🔗 Related Salesforce Interview Prep

⚙️ Apex Triggers 💻 LWC 🤖 Agentforce 🎯 100 Scenarios ☁️ Data Cloud 🏆 150 Advanced

📦 Section 1 — Change Sets

Q1–Q10 · Beginner to Intermediate · Asked in Every Salesforce Admin/Dev Interview

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

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

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

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

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

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

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

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

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