SFDX Interview Questions: 70 Essential Salesforce Deployment

SFDX Interview Questions

If you are preparing for a Salesforce developer interview in 2025, Salesforce SFDX and Deployment interview questions are one of the most critical topics you cannot afford to skip. Whether you are a fresher stepping into your first Salesforce role or an experienced developer moving to a senior position, modern Salesforce hiring managers expect you to know source-driven development, CI/CD pipelines, deployment tools, and environment management inside out.

This complete question bank covers all 70 SFDX and Deployment interview questions across fundamentals, CLI commands, deployment methods, CI/CD, sandboxes, testing, and troubleshooting — structured for both beginners and experienced professionals.

Bookmark this page, share it with your team, and use the table of contents to jump directly to your topic.

🔗 For official documentation visit Salesforce Developer Documentation

Table of Contents

Section 1: SFDX Fundamentals

Q1. What is Salesforce DX (SFDX) and how does it differ from classic Salesforce development?

Salesforce DX (SFDX) is a modern development framework introduced by Salesforce to support source-driven development, version control, team collaboration, and automated testing and deployment. It represents a fundamental shift from the traditional org-centric development model.

	Classic Development	Salesforce DX
Source of Truth	The org itself	Version control (Git)
Environment	Persistent sandbox	Disposable Scratch Orgs
Deployment	Change Sets	Salesforce CLI
Collaboration	Manual, error-prone	Automated CI/CD pipelines
Packaging	Unmanaged packages	Second-Generation Packages (2GP)

Classic development required developers to make changes directly in sandboxes and manually track what was deployed. SFDX moves the source of truth to Git, enabling teams to work collaboratively like traditional software engineers.

🔗 Reference: What is Salesforce DX – Salesforce Ben

Descriptive alt text for image 2 - This image shows important visual content that enhances the user experience and provides context for the surrounding text.

Q2. What is Salesforce CLI and what is its role in SFDX?

Salesforce CLI (previously called SFDX CLI) is a command-line interface tool that allows developers to interact with Salesforce orgs directly from the terminal. It is the backbone of all SFDX workflows.

Key roles of Salesforce CLI:

Create and manage Scratch Orgs
Push and pull metadata between local project and org
Deploy and retrieve metadata from sandboxes and production
Run Apex tests from the command line
Automate tasks inside CI/CD pipelines
Convert metadata between formats

🔗 Reference: Salesforce CLI Setup Guide

Q3. What is source-driven development and why is it important?

Source-driven development means that your Git repository is the single source of truth for all Salesforce metadata — not the org. All changes are made locally, committed to version control, and then pushed to orgs rather than being made directly inside the org.

Why it matters:

Enables full change history and auditability
Supports team collaboration without overwriting each other’s work
Makes rollbacks simple — just revert in Git
Enables automated testing and deployment via CI/CD
Reduces human error in deployments

Q4. What is the difference between Source Format and Metadata Format in SFDX?

	Metadata Format	Source Format
Used In	Change Sets, Metadata API, Ant Tool	SFDX, Salesforce CLI
File Structure	Flat, single XML per component	Decomposed into smaller files per component
Version Control	Difficult to track changes	Easy to track granular changes in Git
Readability	Harder to read	More readable and maintainable

Source Format breaks down large metadata files (like profiles) into smaller, individual files making it much easier to track and review changes in a pull request.

Q5. What is a `sfdx-project.json` file and what does it contain?

sfdx-project.json is the configuration file at the root of every SFDX project. It defines the structure and settings of your Salesforce DX project.

Key contents:

packageDirectories – defines the path(s) to source files
namespace – your org or package namespace if applicable
sourceApiVersion – the Salesforce API version used
sfdcLoginUrl – the default login URL for the org

Every SFDX project must have this file. Without it, Salesforce CLI cannot recognize the directory as a valid SFDX project.

Q6. What is a `.forceignore` file and when do you use it?

.forceignore works exactly like .gitignore but for Salesforce metadata. It tells the Salesforce CLI to ignore specific files or folders when pushing, pulling, deploying, or retrieving metadata.

Common use cases:

Ignoring profiles that differ between environments
Excluding managed package metadata you do not own
Skipping auto-generated files that cause conflicts
Ignoring metadata types not supported in Scratch Orgs

Q7. What is Dev Hub and how do you enable it?

Dev Hub is a Salesforce org that is used to create and manage Scratch Orgs. It is the central control point for all SFDX-based development in your organization.

To enable Dev Hub:

Go to Setup in your production or trial org
Search for Dev Hub in the Quick Find box
Toggle Enable Dev Hub to ON
Optionally enable Second-Generation Packaging

Without Dev Hub enabled, you cannot create Scratch Orgs or use Second-Generation Packaging.

Q8. What is a Scratch Org and how is it different from a Sandbox?

	Scratch Org	Sandbox
Purpose	Temporary development environment	Testing and staging environment
Lifespan	1 to 30 days (disposable)	Persistent (until refreshed)
Data	Starts empty	Can copy production data
Creation	Seconds via CLI	Hours to days
Cost	Included with Dev Hub	Counted against sandbox licenses
Source of Truth	Local SFDX project	The sandbox org itself

Scratch Orgs are designed to be spun up quickly, used for a feature, and then discarded. They encourage clean, repeatable development environments.

Q9. What is the maximum lifespan of a Scratch Org?

The maximum lifespan of a Scratch Org is 30 days. The default lifespan when creating a Scratch Org is 7 days unless you specify a duration using the --duration-days flag in the CLI command.

After expiration, the Scratch Org is automatically deleted along with all its data. This is why SFDX emphasizes that all source code must always be committed to version control before the Scratch Org expires.

Q10. How do you create and delete a Scratch Org using CLI?

Create a Scratch Org:

sf org create scratch --definition-file config/project-scratch-def.json --alias MyScratchOrg --duration-days 7

Delete a Scratch Org:

sf org delete scratch --target-org MyScratchOrg

The project-scratch-def.json file defines the features and settings of the Scratch Org such as which Salesforce features to enable (e.g., Communities, Einstein, etc.).

Section 2: SFDX CLI Commands

Q11. How do you authorize an org using SFDX CLI?

There are two main ways to authorize an org:

Web-based login (interactive):

sf org login web --alias MyOrg

JWT-based login (for CI/CD pipelines):

sf org login jwt --client-id <consumerKey> --jwt-key-file server.key --username user@example.com --alias MyOrg

JWT login is used in automated pipelines because it does not require a browser and works with a connected app and certificate-based authentication.

Q12. What is the difference between `force:auth:web:login` and `force:auth:jwt:grant`?

	`auth:web:login`	`auth:jwt:grant`
Method	Browser-based OAuth	Certificate-based JWT
Use Case	Local development	CI/CD pipelines
Requires Browser	Yes	No
Requires Connected App	No	Yes
Interactive	Yes	No (fully automated)

For automated deployments in Jenkins, GitHub Actions, or any CI/CD tool, JWT grant is always the preferred method.

Q13. What is the difference between `force:source:push` and `force:source:deploy`?

	`source:push`	`source:deploy`
Works With	Scratch Orgs only	Any org (sandbox, production)
Tracks Changes	Yes — tracks delta changes	No — deploys what you specify
Use Case	Active Scratch Org development	Sandbox to production deployments

source:push is used during day-to-day development with Scratch Orgs. source:deploy is used for formal deployments to non-scratch environments.

Q14. What is the difference between `force:source:pull` and `force:source:retrieve`?

	`source:pull`	`source:retrieve`
Works With	Scratch Orgs only	Any org
Behavior	Pulls only tracked changes	Retrieves what you explicitly specify
Use Case	Syncing Scratch Org changes locally	Retrieving metadata from sandbox/production

Q15. How do you run Apex tests using SFDX CLI?

Run all tests:

sf apex run test --target-org MyOrg --result-format human

Run specific test classes:

sf apex run test --target-org MyOrg --tests MyTestClass --result-format human

Run tests synchronously and wait for results:

sf apex run test --target-org MyOrg --synchronous

Running tests via CLI is essential for integrating automated test execution into CI/CD pipelines.

Q16. How do you convert metadata format to SFDX source format?

sf project convert mdapi --root-dir mdapi_output_dir --output-dir force-app

This converts your existing metadata API format project into SFDX source format. This is commonly done when migrating a legacy Salesforce project to an SFDX-based development workflow.

Q17. What is the `sf org list` command used for?

sf org list

This command displays a list of all orgs you have authorized with the Salesforce CLI on your local machine, including Scratch Orgs, sandboxes, and production orgs. It shows alias, username, org ID, and expiry date for Scratch Orgs.

Q18. How do you open an org directly from CLI?

sf org open --target-org MyOrg

This opens the specified org directly in your default browser without requiring you to enter your username and password. It is extremely useful during development for quickly switching between multiple orgs.

Q19. What is the `force:data:tree:export` command used for?

sf data export tree --query "SELECT Id, Name FROM Account" --output-dir ./data

This command exports records from a Salesforce org into JSON files that can be imported into another org. It is commonly used to seed Scratch Orgs or test environments with sample data during development.

Q20. How do you deploy only specific metadata components using CLI?

sf project deploy start --metadata ApexClass:MyClass --target-org MyOrg

You can specify individual components using the --metadata flag followed by the metadata type and API name. This is useful when you only want to deploy a single class, trigger, or flow without deploying everything in your project.

Section 3: Deployment Methods & Tools

Q21. What are the different ways to deploy metadata in Salesforce?

Salesforce supports multiple deployment methods depending on team size, complexity, and tooling maturity:

Change Sets – UI-based, org-to-org, no version control
Salesforce CLI (SFDX) – Command-line, source-driven, CI/CD friendly
Metadata API – Programmatic deployment via API calls
Ant Migration Tool – XML-based, legacy CI scripts
Second-Generation Packages (2GP) – Version-controlled, unlocked or managed packages
Third-Party Tools – Copado, Gearset, Flosum, AutoRABIT

Each method has its own use case. Modern teams increasingly use SFDX with CI/CD pipelines as the preferred approach.

Q22. What are Change Sets and what are their limitations?

Change Sets are Salesforce’s native UI-based deployment tool for moving metadata between orgs that are connected to the same production environment.

Limitations of Change Sets:

No version control integration
Cannot deploy destructive changes (deletions)
Manual and error-prone at scale
Only works between orgs in the same Salesforce environment
No rollback capability
Slow for large deployments
No support for automated testing before deployment

⚠️ Change Sets are still used widely but are being replaced by SFDX-based workflows in modern teams.

Q23. What is the Metadata API and when do you use it?

Metadata API is a Salesforce API that allows programmatic retrieval and deployment of metadata. It is the underlying API that powers Change Sets, SFDX, and third-party tools like Gearset.

Direct use cases:

Custom deployment scripts
Automated metadata backups
Integration with legacy CI tools
When more control than Change Sets is needed but full SFDX is not yet adopted

Q24. What is the Ant Migration Tool and is it still relevant in 2025?

The Ant Migration Tool is a legacy command-line tool based on Apache Ant that uses build.xml and package.xml files to deploy and retrieve Salesforce metadata.

In 2025 it is largely considered legacy. Salesforce officially recommends using Salesforce CLI (SFDX) instead. However, you may still encounter it in older CI pipelines and legacy projects, so knowing it exists and how it works is still valuable in interviews.

Q25. What is the difference between Change Sets, Metadata API, and SFDX for deployments?

	Change Sets	Metadata API	SFDX
Version Control	No	Possible	Yes (Git)
Automation	No	Yes	Yes
CI/CD Support	No	Partial	Full
Destructive Changes	No	Yes	Yes
Rollback	No	Manual	Via Git
Recommended For	Small teams	Custom scripts	Modern teams

Q26. What is Salesforce DevOps Center and how does it differ from Change Sets?

Salesforce DevOps Center is Salesforce’s native UI-based DevOps tool that connects to Git version control and provides a guided pipeline for deploying changes across environments.

	Change Sets	DevOps Center
Version Control	No	Yes (Git)
Change Tracking	Manual	Automatic
Pipeline Stages	Not supported	Supported
Rollback	Not supported	Via Git
Suitable For	Small teams	Teams adopting Git

DevOps Center is positioned as the upgrade path from Change Sets for teams not yet ready for full CLI-based SFDX workflows.

Q27. What are third-party deployment tools like Copado, Gearset, and Flosum?

These are enterprise-grade DevOps platforms built specifically for Salesforce that extend SFDX capabilities with additional features:

Copado – Full DevOps platform with built-in testing, compliance, and AI features
Gearset – Popular for easy delta deployments, comparison, and rollback
Flosum – Native Salesforce AppExchange DevOps tool
AutoRABIT – Focused on release management, data deployment, and compliance

These tools are widely used in large enterprises where native SFDX pipelines need additional governance, approvals, or audit trails.

Q28. What is an Unmanaged Package and when would you use it for deployment?

An Unmanaged Package is a collection of Salesforce components bundled together for deployment or distribution. Once installed, the components can be modified by the receiving org.

Use cases:

One-time deployments between unrelated orgs
Distributing open-source Salesforce solutions
Deploying a set of components to a client org
Quick sharing of templates or utilities

Unlike Managed Packages, Unmanaged Packages cannot be upgraded post-installation.

Q29. What is a Managed Package and how does it differ from an Unmanaged Package?

	Unmanaged Package	Managed Package
Code Visibility	Fully visible	Can be hidden (protected)
Upgradeable	No	Yes
Namespace	No	Required
Use Case	One-time deployment	AppExchange ISV distribution
Post-install Editing	Allowed	Restricted

Managed Packages are used by Independent Software Vendors (ISVs) to distribute and maintain commercial Salesforce applications on AppExchange.

Q30. What is a Second-Generation Package (2GP) in SFDX?

Second-Generation Packages (2GP) are the modern, source-driven packaging format in Salesforce DX. Unlike First-Generation Packages (1GP), 2GPs are:

Created and managed entirely via Salesforce CLI
Stored in version control as source code
Versionable with proper semantic versioning
Faster to create and iterate on
Available as Unlocked Packages (for internal use) or Managed 2GP (for AppExchange)

Unlocked Packages in particular are gaining popularity as a modular deployment strategy for large enterprise Salesforce orgs.

Section 4: CI/CD & Version Control

Q31. What is CI/CD in the context of Salesforce development?

CI/CD stands for Continuous Integration and Continuous Deployment. In Salesforce development it means:

CI (Continuous Integration) – Every time a developer pushes code to Git, automated tests run to validate the changes immediately
CD (Continuous Deployment) – After tests pass, code is automatically deployed to the next environment (sandbox → UAT → production)

Benefits:

Reduces manual deployment errors
Speeds up release cycles
Ensures consistent code quality across all environments
Provides instant feedback to developers on broken code

Q32. How do you set up a CI/CD pipeline for Salesforce using GitHub Actions?

A basic GitHub Actions pipeline for Salesforce includes:

Trigger – On pull request or push to main branch
Authenticate – Use JWT to log into the target org
Validate – Run sf project deploy validate to check for errors
Test – Execute Apex test classes automatically
Deploy – On merge to main, deploy to the target org
Notify – Send success/failure notifications to the team

# Example step in GitHub Actions
- name: Deploy to Salesforce
  run: sf project deploy start --target-org production --test-level RunLocalTests

🔗 Reference: Salesforce CI/CD with GitHub Actions

Q33. How do you integrate SFDX with Jenkins for automated deployments?

Jenkins integration with SFDX follows these steps:

Install Salesforce CLI on the Jenkins server
Set up a Connected App in Salesforce for JWT authentication
Store the JWT private key as a Jenkins secret credential
Create a Jenkins pipeline (Jenkinsfile) with stages for authenticate, validate, test, and deploy
Trigger the pipeline on Git commits or pull requests

Jenkins is commonly used in enterprise environments where GitHub Actions or GitLab CI may not be the primary CI tool.

Q34. What is the role of Git in a Salesforce DX workflow?

Git is the single source of truth in an SFDX workflow. Its role includes:

Storing all Salesforce metadata as source files
Tracking every change made by every developer with full history
Enabling branching strategies (feature branches, release branches)
Facilitating code reviews via pull requests
Enabling rollbacks by reverting commits
Triggering CI/CD pipelines on push or merge events

Without Git, SFDX loses most of its collaborative and automation benefits.

Q35. What is a single source of truth in SFDX and why does it matter?

In SFDX, the single source of truth means that your Git repository contains the definitive, authoritative version of all Salesforce metadata. No change is valid unless it exists in Git first.

Why it matters:

Prevents the “works in my sandbox” problem
Ensures all environments are deployed from the same codebase
Makes auditing and compliance straightforward
Eliminates configuration drift between environments
Enables any team member to recreate any environment from scratch

Q36. How do you handle merge conflicts in a Salesforce Git repository?

Merge conflicts in Salesforce Git repos are most common in large metadata files like Profiles, Permission Sets, and Custom Objects. Best practices:

Use Source Format (SFDX) which decomposes large files into smaller ones reducing conflict frequency
Establish clear branching strategies (e.g., GitFlow)
Use .forceignore to exclude frequently conflicting files like profiles
Resolve conflicts using VS Code with Salesforce Extensions which highlights changes clearly
Communicate actively with team members about overlapping work areas

Q37. What is a validation deployment and why should you always run it before deploying?

A validation deployment runs all the checks of a real deployment (compiles code, runs tests, checks metadata) without actually committing any changes to the org.

sf project deploy validate --source-dir force-app --target-org production --test-level RunLocalTests

Why you should always validate first:

Catches compilation errors before they affect production
Confirms test coverage meets the 75% threshold
Enables Quick Deploy (deploy instantly within 10 minutes of a successful validation)
Reduces risk of failed deployments in production

Q38. How do you handle destructive changes in SFDX deployments?

Destructive changes (deleting metadata components) require a destructiveChanges.xml or destructiveChangesPre.xml file alongside an empty package.xml.

sf project deploy start --target-org MyOrg --pre-destructive-changes destructiveChangesPre.xml

Pre-destructive changes – Delete components before deploying new ones
Post-destructive changes – Delete components after deploying new ones

⚠️ Always test destructive changes in a sandbox first. Deleting metadata in production can break existing functionality.

Q39. What is the difference between a full deployment and a delta deployment?

	Full Deployment	Delta Deployment
What Deploys	All metadata in the project	Only changed components since last deployment
Speed	Slower	Faster
Risk	Higher (touches more components)	Lower
Use Case	Initial setup or major releases	Regular sprint deployments

Delta deployments are preferred for frequent releases as they reduce deployment time and risk. Tools like Gearset and Copado specialize in smart delta deployments.

Q40. How do you manage environment-specific configurations across sandboxes and production?

Environment-specific settings should never be hardcoded. Best practices:

Custom Metadata Types – Store environment-specific values that deploy with your code
Custom Settings – Store config data per org (though less deployment-friendly)
Named Credentials – Store endpoint URLs and authentication settings per environment
Environment Variables – In CI/CD pipelines, use pipeline variables for secrets
.forceignore – Exclude org-specific metadata that should not be overwritten during deployment

Section 5: Sandboxes & Environments

Q41. What are the different types of Sandboxes in Salesforce?

Sandbox Type	Storage	Data Copy	Refresh Interval	Use Case
Developer	200MB	No	1 day	Individual development
Developer Pro	1GB	No	1 day	Larger development projects
Partial Copy	5GB	Sample (up to 10K records)	5 days	Testing with realistic data
Full	Same as production	Full copy	29 days	UAT and performance testing

Q42. What is the difference between a Developer Sandbox and a Full Sandbox?

	Developer Sandbox	Full Sandbox
Data	No production data	Full copy of production data
Storage	200MB	Same as production
Refresh	Daily	Every 29 days
Use Case	Development and unit testing	UAT, performance, regression testing
Cost	Included in most licenses	Additional license cost

Q43. When would you use a Partial Copy Sandbox vs a Full Sandbox?

Use a Partial Copy Sandbox when you need realistic data for testing but do not need the full volume of production data. It copies up to 10,000 records per object using a sandbox template.

Use a Full Sandbox when you need complete production data parity — typically for User Acceptance Testing (UAT), performance testing, or final pre-release validation where data volume and relationships matter.

Q44. What is Sandbox refresh and what happens to data after a refresh?

A Sandbox refresh resets the sandbox back to a copy of its source org (usually production) at the time of refresh. After a refresh:

All metadata is replaced with the current production metadata
All data is either cleared (Developer/Developer Pro) or refreshed from production (Partial/Full)
All customizations made in the sandbox since the last refresh are lost
The sandbox org ID remains the same but all user passwords are reset
Any external connections or integrations pointing to the sandbox may need reconfiguration

Q45. What is the difference between a Scratch Org and a Developer Sandbox?

	Scratch Org	Developer Sandbox
Source of Truth	Local SFDX project	The org itself
Lifespan	Up to 30 days	Persistent
Creation Time	Seconds	Minutes to hours
Data	Seeded via CLI	No production data
Cost	Requires Dev Hub license	Standard sandbox license
Best For	Feature development, CI/CD	Testing, integration work

Q46. How do you manage org-specific settings across multiple environments?

The best approach is using Custom Metadata Types for deployable settings and Named Credentials for endpoint management. Additionally:

Never hardcode org-specific values like IDs, URLs, or usernames in code
Use Custom Metadata records that can be environment-specific and deploy alongside code
Use Salesforce CLI environment variables for secrets in automated pipelines
Document environment-specific configuration in a runbook so any team member can configure a new environment

Q47. What is the purpose of Custom Metadata Types in environment management?

Custom Metadata Types store configuration data that can be packaged and deployed alongside your code — unlike Custom Settings which are data and do not deploy automatically.

Use cases in environment management:

Storing API endpoint URLs per environment
Feature flags to enable or disable functionality per org
Threshold values and business rules that differ between environments
Integration credentials references (not the credentials themselves)

Q48. What is the purpose of Named Credentials in deployments?

Named Credentials store the URL and authentication settings for external service callouts. They are metadata components that can be deployed via SFDX.

Benefits in deployment:

The same Apex code works across all environments — only the Named Credential value changes
Authentication details are stored securely by Salesforce
Eliminates hardcoded endpoint URLs in Apex code
Supports OAuth, Basic Auth, JWT, and more

Q49. How do you handle Profiles and Permission Sets during deployment?

Profiles are one of the most challenging metadata types to deploy because they contain org-specific references (field visibility, object permissions, app assignments) that differ between environments.

Best practices:

Use Permission Sets instead of Profiles wherever possible — they are more modular and deployment-friendly
Use .forceignore to exclude Profile sections that cause conflicts
Deploy only the specific Profile attributes you have intentionally changed
Use third-party tools like Gearset which handle Profile comparison and selective deployment intelligently

Q50. How do you deploy Record Types and Page Layouts without errors?

Record Types and Page Layouts are tightly coupled with Profiles, which makes deployment tricky. Best practices:

Always deploy the Record Type, Page Layout, and associated Profile changes together
Ensure the Record Type exists in the target org before deploying Page Layout assignments
Use a package.xml that explicitly includes all related components
Validate in a staging sandbox before deploying to production
Check for org-specific picklist values that may not exist in the target org

Section 6: Testing & Code Coverage

Q51. What is the minimum code coverage required to deploy to production?

Salesforce requires a minimum of 75% code coverage across all Apex classes and triggers to deploy to production. Additionally, every individual trigger must have at least 1% coverage.

⚠️ The 75% is calculated across ALL Apex code in the org, not just the code you are deploying. A large org with existing code can be impacted if new untested code lowers the overall percentage.

Q52. What is the recommended best practice code coverage percentage?

While 75% is the minimum required by Salesforce, the industry best practice is to aim for 85% to 90% or higher. Higher coverage means:

More confidence that code works as expected
Fewer production bugs
Easier refactoring in the future
Better protection when new releases update the platform

Never write tests just to hit 75%. Write meaningful tests that cover real business scenarios.

Q53. What happens if code coverage drops below 75% during deployment?

If the overall code coverage in the target org drops below 75% during deployment, Salesforce will block the deployment entirely with an error message indicating insufficient coverage.

Common causes:

New Apex code deployed without corresponding test classes
Test classes that were deleted or are failing
Existing test classes that no longer cover the code adequately

Resolution: Write or update test classes to cover the new code before attempting deployment again.

Q54. What is the difference between `@isTest` and `@testSetup`?

	`@isTest`	`@testSetup`
Purpose	Marks a class or method as a test	Creates test data once for all test methods in the class
Scope	Class or method level	Method level only (within a test class)
Data	Created per test method	Created once and shared across all test methods
Performance	Slower if each method creates data	Faster — data setup runs only once

@testSetup is a performance optimization. Use it when multiple test methods in the same class need the same baseline data.

Q55. When do you use `System.runAs()` in a test class?

System.runAs() is used in test classes to execute code in the context of a specific user. This is important for testing:

Record sharing and visibility rules
Profile and Permission Set-based restrictions
Field Level Security enforcement
User-specific automation behavior

User testUser = [SELECT Id FROM User WHERE Username = 'test@example.com'];
System.runAs(testUser) {
    // Code executes as testUser
}

Without System.runAs(), all test code runs as the system administrator which bypasses sharing rules and security settings.

Q56. How do you seed Custom Metadata Types in a test class?

Custom Metadata Type records cannot be inserted via DML in test classes — they are read-only at runtime. The recommended approach is:

Deploy the Custom Metadata records alongside your code so they exist in the org during testing
Use a mock/stub pattern where your Apex class calls a service layer that can be overridden in tests
Use a custom interface that your test can implement to return mock values instead of querying Custom Metadata

This is a common interview question that tests your understanding of testability and clean code architecture.

Q57. How do you run only specific test classes during a deployment?

sf project deploy start --target-org production --test-level RunSpecifiedTests --tests MyTestClass1 MyTestClass2

Using RunSpecifiedTests lets you define exactly which test classes to execute. This is useful for faster deployments when you know exactly which tests cover the code you are deploying. However, you must still meet the overall 75% coverage threshold.

Q58. What is the difference between running local tests and all tests during deployment?

Test Level	What Runs	When to Use
`NoTestRun`	No tests	Sandbox only, never production
`RunLocalTests`	All tests not from managed packages	Standard production deployments
`RunAllTestsInOrg`	Every test including managed packages	Full regression testing
`RunSpecifiedTests`	Only named test classes	Targeted deployments

RunLocalTests is the most commonly used option for production deployments as it excludes managed package tests (which you do not control) while still validating your custom code.

Q59. How do you handle test data isolation in Salesforce test classes?

Test data isolation ensures that test data does not interfere with real org data or other tests. Best practices:

Always use @isTest annotation to isolate test context
Use @testSetup to create reusable test data within the class
Never rely on existing org data in tests — always create your own test records
Use Test.startTest() and Test.stopTest() to isolate governor limit consumption
Avoid using SeeAllData=true unless absolutely necessary as it creates dependency on real org data

Q60. What are the best practices for writing test classes in Salesforce?

Cover both positive (expected behavior) and negative (error handling) scenarios
Test bulk scenarios — always test with 200 records to verify bulkification
Never use SeeAllData=true — create your own test data
Use meaningful assertions — do not just test that no exception was thrown
Aim for 85%+ coverage not just the minimum 75%
Use @testSetup for shared test data across multiple methods
Test as different users using System.runAs() for sharing and security scenarios
Keep test classes organized and readable — future developers will thank you

Section 7: Troubleshooting Deployments

Q61. What are the most common reasons a Salesforce deployment fails?

Insufficient code coverage – Overall org coverage drops below 75%
Compilation errors – Apex code references fields, objects, or classes that do not exist in target org
Missing dependencies – A component being deployed references another component not included in the deployment
Failing test classes – One or more test methods fail in the target org
Validation rule conflicts – Existing validation rules block test data creation
Locked components – Components in use by active flows or processes cannot be deleted
Profile/Permission Set conflicts – Referenced fields or objects do not exist in target org

Q62. How do you troubleshoot a failed deployment in SFDX?

Step-by-step approach:

Read the error message carefully – SFDX CLI provides component-level error details
Check the deployment status using sf project deploy resume or check Setup > Deployment Status
Run a validation first to identify errors before a live deployment
Reproduce in sandbox – If it fails in production, replicate the exact deployment in a staging sandbox
Check dependencies – Ensure all referenced components are included in the deployment package
Review test failures – Run failing tests manually in the target org to understand the root cause
Check org-specific data – Some tests fail because required test data or config does not exist in the target org

Q63. What is a deployment error related to missing dependencies and how do you fix it?

A missing dependency error occurs when a metadata component you are deploying references another component that does not exist in the target org.

Example: Deploying an Apex class that references a Custom Object that has not yet been deployed.

Fix:

Always deploy dependencies first or include them in the same deployment package
Use sf project deploy validate to identify missing dependencies before the actual deploy
Use a tool like Gearset which automatically detects and includes missing dependencies

Q64. How do you handle a situation where a component already exists in the target org?

When deploying a component that already exists in the target org, Salesforce will overwrite the existing component with the version you are deploying.

Important considerations:

If the existing component has been manually modified in the target org after your last retrieval, your deployment will overwrite those changes
Always retrieve the latest version from the target org before deploying to avoid losing manual changes
Use a comparison tool (Gearset, VS Code SFDX extension) to review differences before deploying
This is why Git as a single source of truth is so important — all changes should go through version control

Q65. What causes a code coverage failure during deployment and how do you resolve it?

Code coverage failures during deployment are caused by:

New code deployed without test classes
Existing test classes that are now failing due to logic changes
Test classes that relied on org data that no longer exists
Managed package updates that changed behavior affecting your tests

Resolution steps:

Run all tests in the sandbox to identify which tests are failing
Fix the failing test classes
If coverage is genuinely low, write additional test classes
Run RunLocalTests in sandbox to confirm coverage is above 75% before deploying to production

Q66. How do you deploy changes when a Validation Rule or Trigger is blocking test data creation?

This is a very common real-world problem. Solutions:

Deactivate the Validation Rule temporarily in the target org before deployment (requires org access)
Update the test class to create data that satisfies the validation rule
Use Test.isRunningTest() in the Validation Rule formula to bypass it during test execution:

OR(ISNEW(), $Setup.MyCustomSetting__c.BypassValidation__c = true, Test.isRunningTest())

Use a bypass flag in Custom Metadata or Custom Settings to disable validation rules during testing

Q67. What is the Quick Deploy feature and when can you use it?

Quick Deploy allows you to skip re-running all tests during a production deployment if you have already successfully validated the deployment within the last 10 minutes (for the new API) or 4 days (for older API versions).

Requirements for Quick Deploy:

The validation must have passed with RunLocalTests or RunAllTestsInOrg
The validation must still be within the eligible time window
No changes have been made to the components since validation

Quick Deploy is a major time-saver for large orgs where running all tests can take 30 minutes or more.

Q68. How do you roll back a failed deployment in Salesforce?

Salesforce does not have a native one-click rollback. Options for rollback:

Revert in Git – Check out the previous version and redeploy
Retrieve before deploy – Always retrieve and store the current state before deploying so you can re-deploy the old version
Gearset/Copado rollback – Third-party tools offer built-in rollback functionality
Sandbox comparison – Compare the current production state against a pre-deployment snapshot and deploy the differences back

This is why maintaining Git history and pre-deployment backups is considered essential best practice.

Q69. How do you check deployment status using SFDX CLI?

Check status of the most recent deployment:

sf project deploy report --target-org MyOrg

Resume and check a specific deployment by job ID:

sf project deploy resume --job-id 0AfXXXXXXXXXXXXX

You can also check deployment status in Salesforce Setup by navigating to Setup > Environments > Deploy > Deployment Status.

Q70. What is the difference between deploy errors and test errors in a failed deployment?

	Deploy Errors	Test Errors
Cause	Compilation failures, missing components, metadata conflicts	Failing Apex test methods
When They Occur	During metadata processing phase	During test execution phase
Fix	Correct the metadata or include missing dependencies	Fix or update the failing test classes
Impact	Blocks deployment entirely	Blocks deployment if coverage drops or assertions fail

Understanding which type of error you are dealing with determines where to focus your troubleshooting effort. Deploy errors are always fixed before test errors since there is no point running tests if the code does not compile.

Section 8: Rizex Labs Salesforce Training

Q71. Does Rizex Labs offer Salesforce SFDX and Deployment training?

Yes, Rizex Labs offers comprehensive Salesforce developer training that covers Salesforce DX, SFDX CLI, source-driven development, CI/CD pipeline setup, deployment strategies, sandbox management, and troubleshooting. The training is designed for both freshers entering the Salesforce ecosystem and experienced developers looking to modernize their deployment practices.

Q72. Who is the Salesforce SFDX training at Rizex Labs suitable for?

The SFDX and Deployment training at Rizex Labs is suitable for Salesforce developers, release managers, DevOps engineers, Salesforce administrators moving into development, and IT professionals who want to build hands-on expertise in modern Salesforce development and deployment workflows.

Q73. Does Rizex Labs cover CI/CD pipeline setup as part of the training?

Yes, Rizex Labs training includes hands-on CI/CD pipeline setup covering GitHub Actions, Jenkins integration with SFDX, automated test execution, validation deployments, and production deployment workflows. Students learn to build real pipelines they can apply immediately in their workplace or projects.

Q74. How can I enroll in Salesforce SFDX training at Rizex Labs?

You can enroll in Salesforce SFDX and Deployment training at Rizex Labs by visiting rizexlabs.com and exploring the available developer training programs. The Rizex Labs team will guide you to the right learning path based on your current experience level and career goals.

🎯 Final Interview Tips for Salesforce SFDX and Deployment

Always explain the why behind your tool choices — interviewers love hearing reasoning not just answers
Be ready to walk through a complete deployment pipeline from local development to production
Know the difference between all sandbox types — this comes up in almost every interview
Understand code coverage deeply — not just the 75% rule but how to write meaningful tests
Be honest about tools like Copado or Gearset — if you have used them mention it as it shows real-world experience
Practice actual CLI commands — even if you cannot remember exact syntax, knowing the structure of commands impresses interviewers

🔗 Deepen your knowledge at Salesforce Trailhead – Developer Experience

📌 Summary

This guide covered 70 essential Salesforce SFDX and Deployment interview questions across fundamentals, CLI commands, deployment tools, CI/CD pipelines, sandbox management, testing, code coverage, and troubleshooting — for both freshers and experienced Salesforce developers.

Bookmark this Salesforce SFDX and Deployment question bank, revisit it regularly, and check rizexlabs.com for more Salesforce training guides, interview preparation resources, and hands-on courses.

Tags: Salesforce SFDX, Salesforce Deployment Interview Questions, Salesforce CLI, CI/CD Salesforce, Scratch Org, Change Sets, Salesforce DevOps, SFDX Interview Questions 2025, Salesforce Developer Interview, Rizex Labs