Salesforce DevOps and Deployment Interview Questions

Deployment questions start the moment your resume mentions a release, a sandbox refresh or a tool like Copado. The interviewer wants to know whether you have actually moved metadata between orgs or only watched someone else do it. The 24 questions below cover change sets and source driven development, packaging and scratch orgs, version control and CI/CD, and the security side of both deployments and the platform. Each answer gives the definition first, then the part candidates get caught on: the exact gate, the thing the tool cannot do, and what you check when a deployment fails.

Change sets and source driven development

What is a Change Set?

A Change Set moves metadata between two related Salesforce orgs through the Setup UI. You build an Outbound Change Set, use View/Add Dependencies to pull in what the components reference, and upload it. The target org receives it as an Inbound Change Set, validates, then deploys it.

A change set travels only between orgs in the same lineage, a production org and its own sandboxes, and only after a Deployment Connection authorises inbound change sets on the receiving side.

What a Change Set cannot carry:

• Records. Custom Setting values and reference data stay behind. Custom Metadata Type records are the exception, because those are metadata and do deploy.
• Deletions. Removing a field in UAT is a manual step or a Metadata API deployment with destructiveChanges.xml.
• Unsupported metadata types. The component picker covers less ground than the Metadata API.
• Secrets. Named Credential passwords and protected custom setting values arrive blank.
• Automation. There is no API for change sets, so they cannot be scripted, scheduled or diffed.
• History. Nothing records who changed the field and why.

This is where candidates get found out. The real question is "you deployed to UAT and the field is not there, what do you check". Candidates fail on demonstration, not knowledge.

What is Salesforce DX?

Salesforce DX is the source driven development model plus its tooling: the sf CLI, Dev Hub, source format, scratch orgs, second generation packaging and the VS Code extensions.

Under the old model the org is the master copy and you hope the sandbox matches production. Under Salesforce DX the Git repository is the source of truth and every org is a target rebuildable from source. Source format decomposes objects so two developers editing different fields do not collide, and .forceignore keeps org-specific drift out of retrievals.

sf project deploy start --source-dir force-app --target-org uat
sf apex run test --test-level RunLocalTests --code-coverage --target-org uat

The old sfdx force:source:push and force:source:pull pair no longer exists. Both folded into sf project deploy start and sf project retrieve start, which use source tracking where the org supports it.

What is Destructive Changes?

Metadata deletions performed through the Metadata API with a destructiveChanges.xml manifest, because a normal deployment only adds and updates. Name the file preDestructiveChanges.xml to delete before the payload lands, or postDestructiveChanges.xml to delete after. Use the pre form when a new component collides with an old API name.

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>Quote__c.Legacy_Discount_Rate__c</members>
        <name>CustomField</name>
    </types>
    <types>
        <members>OldQuoteDiscountHandler</members>
        <name>ApexClass</name>
    </types>
    <version>64.0</version>
</Package>

Four rules to state. Wildcards are not allowed, and a custom field is named as Object.Field__c. The file must travel with a package.xml, which may contain no <types> but must carry a <version>. Deletion fails while anything still references the component. And purgeOnDelete bypasses the Recycle Bin in a sandbox only. On the current CLI you pass the manifest with --post-destructive-changes on sf project deploy start.

What is Pre-deployment validation?

A validation is a full deployment that runs every check and every test and commits nothing. On the current CLI it is sf project deploy validate, not a flag on the deploy command. It returns a job ID, and you promote that payload with sf project deploy quick --job-id <id>. A validation stays usable for ten days and the quick deploy skips the test run, which is how a large release reaches production in minutes. Quick deploy needs the validation to have run tests, and nothing in the target may have changed in a way that invalidates the payload.

The deployment code coverage gate, exactly:

• Every test in the run must pass. The deployment is atomic, so one failure means nothing lands.
• Org-wide Apex code coverage must be at least 75 percent once the deployment is applied.
• Every trigger must have some coverage. A trigger at zero blocks the deployment even when the org total is comfortable.
• The 75 percent figure is an org-wide average, not a per class rule. The exception is RunSpecifiedTests, where each class and trigger in the deployment must individually reach 75 percent.
• Test levels are NoTestRun, RunSpecifiedTests, RunLocalTests and RunAllTestsInOrg. NoTestRun is rejected for a production deployment containing Apex. RunLocalTests skips managed package tests and is the usual production choice.
• Sandbox deployments have no coverage gate, which is why a deployment that sailed into UAT can still be rejected by production.

Coverage is a gate, not a goal. An assertion-free test looping 200 records through a trigger clears 75 percent and proves nothing.

What is Post-deployment steps?

The manual work metadata cannot carry, written down before the release rather than remembered during it.

• Assign the new permission sets. Metadata deploys the permission set, not who holds it.
• Insert Custom Setting records and reference data, and re-enter secrets in Named Credentials and protected settings, which arrive empty.
• Schedule Apex jobs, because scheduled jobs are CronTrigger records and a new batch class lands unscheduled.
• Activate Flows that deployed inactive and deactivate the ones they replace.
• Repoint Remote Site Settings, CSP Trusted Sites and outbound message endpoints, which usually still name the sandbox copy of the external system.
• Re-enable anything switched off for a data load, then run the smoke test and watch Apex Jobs and debug logs.

Packaging and scratch orgs

What is a Scratch Org?

A disposable, source driven org created from a Dev Hub and thrown away when the work item closes. A definition file declares the edition, features and settings, so the org's shape is itself under version control.

sf org create scratch --definition-file config/project-scratch-def.json \
  --alias feature-quote-discount --duration-days 7 --set-default

It starts empty, so you push source in and load test data as part of setup. The default life is 7 days and the maximum is 30, so nothing of value lives only there. It consumes Dev Hub allocations for daily creation and for active orgs, which a pipeline creating one per pull request must budget for. A developer sandbox copies production; a scratch org copies your repository.

What is an Unlocked Package?

A second generation package built from source, used to deploy your own internal metadata as a versioned, installable unit.

Its defining trait is in the name. The metadata inside it is not locked in the target org, so an admin can edit a packaged field directly, and the next upgrade overwrites that edit and treats the package version as the authority. That is deliberate: it makes room for the fact that admins configure orgs by clicking. The source stays visible, a namespace is optional, and no Salesforce review is required because the package never leaves your own estate.

What is a Managed Package?

The distribution format for ISVs, built against a registered namespace and installed into customer orgs from AppExchange or an install URL.

The short version: an unlocked package protects your release process, a managed package protects your intellectual property.

What is Security Review?

The assessment Salesforce runs on a managed package before it can be listed publicly on AppExchange, and again on later versions. It pairs an automated static scan with a manual review, and covers the external services the package talks to, not only its Apex.

The recurring failure reasons: SOQL injection from unescaped variables in dynamic queries, missing CRUD and FLS enforcement, cross-site scripting in Visualforce or Aura markup, hardcoded IDs, credentials in code, and sharing not honoured where the design implies it should be.

Version control and CI/CD

What is Version Control in Salesforce?

The org's metadata lives in a Git repository, every change arrives as a commit with an author and a reason, and the org is built from that repository rather than being where changes are invented.

Salesforce makes this harder than ordinary software. Metadata is XML generated by the org, so retrievals are noisy. Admins change configuration by clicking and Git never hears about it, which is drift. And profiles are org-specific by nature, which is why serious teams version permission sets instead.

Git branching strategy for Salesforce

• main mirrors production. Nobody commits to it directly. It receives merges only, and every merge is followed by a production deployment.
• develop is the integration branch. A merge here triggers an automatic deployment to the QA sandbox, so integration problems surface in minutes instead of at UAT.
• feature/W-1042-quote-discount is cut from develop, one branch per work item, built in its own scratch org or developer sandbox, closed by a reviewed pull request.
• release/2026-03 is cut from develop when scope freezes, deploys to UAT, and accepts defect fixes only.
• hotfix/INC-4412 is cut from main, validated, deployed to production, then merged back into main and forward merged into develop and any open release branch.

Rebase a feature branch on develop before raising the pull request, and merge rather than rebase into shared branches. Keep branches short-lived, because a conflict inside an .object-meta.xml or a Flow file gets worse with age.

What is a CI/CD pipeline?

The automation that carries a commit through build, test and deployment without a human moving files between orgs.

1. Trigger. A pull request opened, or a merge to a tracked branch.
2. Authenticate. The runner logs in with the JWT bearer flow using a connected app and a server key from the secret store. Never an interactive login, never a password in a script.
3. Static analysis. Code scanning, failing the build on the severities you agreed to block.
4. Validate. sf project deploy validate at the correct test level, producing a job ID.
5. Test. Apex tests with coverage captured, plus Jest for Lightning web components.
6. Deploy. On merge, sf project deploy quick --job-id <id> promotes the validated payload.
7. Post-deploy. Scheduled jobs recreated, smoke tests run, result posted to the work item.

Stages one to five are continuous integration. Stage six as a button someone presses is continuous delivery, which is what most Salesforce teams run.

What is Jenkins in Salesforce?

A general purpose, self-hosted automation server with no Salesforce knowledge of its own. It runs the Salesforce CLI on an agent, and the pipeline logic lives in a Jenkinsfile in your repository. A typical job authenticates with the JWT bearer flow using credentials from the Jenkins credentials store, validates, runs tests, and quick deploys on merge. You get control and predictable cost, and you also own the agents and the certificate rotation.

If you claim Jenkins on your resume, expect the follow-up about authentication. Interviewers go five levels deep on project claims: which branch triggered it, where the key was stored, what the test level was, who approved the promotion.

What is Gearset or Copado?

Both are commercial DevOps platforms sitting above Git and the Metadata API, giving admins a pipeline they can run without the command line.

Gearset runs outside the org as a SaaS product. Its strength is comparison: an org-to-org or Git-to-org diff with problem analysers that catch the dependency you forgot, plus CI jobs and backup with restore.

Copado is Salesforce-native, installed as a managed package inside your org. It works in user stories and promotions rather than raw diffs, maps a pipeline to your environments and enforces quality gates per stage.

DevOps Center is the Salesforce-provided option at no extra licence cost. It connects a Git repository, tracks work items, and lets an admin promote changes through pipeline stages by clicking, with less control over test levels than a CLI pipeline gives you.

Deployment security and platform security

What is CRUD/FLS enforcement in Apex?

Apex runs in system context by default. It ignores object permissions, field permissions and, unless the class says otherwise, sharing. Enforcement is something you write in. The distinction candidates miss is that with sharing controls record visibility only. It does not stop a user with no read access on Salary__c from receiving that field through your controller.

// User mode on query and DML: enforces CRUD, FLS and sharing
List<Contact> cons = [
    SELECT Id, Email, Salary__c FROM Contact
    WHERE AccountId = :accId WITH USER_MODE
];
update as user cons;

Database.insert(records, AccessLevel.USER_MODE);

if (!Schema.sObjectType.Contact.fields.Salary__c.isUpdateable()) { return; }

Name WITH USER_MODE first, because it covers object permissions, field permissions and sharing in one clause, and as user gives DML the same treatment. WITH SECURITY_ENFORCED is the older SOQL clause: it throws on an inaccessible field or object, but checks the SELECT clause only.

What is StripInaccessible?

Security.stripInaccessible() removes fields the running user cannot access from a list of SObjects, instead of throwing an exception.

SObjectAccessDecision decision = Security.stripInaccessible(
    AccessType.READABLE,
    [SELECT Id, Name, Salary__c FROM Contact WHERE AccountId = :accId]
);
List<Contact> safe = (List<Contact>) decision.getRecords();
Map<String, Set<String>> removed = decision.getRemovedFields();

• AccessType is CREATABLE, READABLE, UPDATABLE or UPSERTABLE. Match it to what you are about to do with the records.
• SObjectAccessDecision returns getRecords() for the sanitised list, getRemovedFields() for a map of object name to stripped fields, and getModifiedIndexes() for which records changed. Log the removed fields, because that map explains why a user sees a blank value.
• It strips fields. By default it does not enforce object-level access on the root object; a third boolean argument turns that check on.
• Fields inside parent relationships and records returned by subqueries are cleaned too.
• A stripped field reads as null, so a sanitised record must never feed logic that assumes the field is populated.

Use WITH USER_MODE when an inaccessible field should stop the transaction, and stripInaccessible when the transaction should continue with less data, which is the usual need in an API response.

What is Shield Platform Encryption?

A licensed add-on encrypting data at rest in the database, the search index and file storage, using keys derived from a tenant secret your administrators control. It is not the old Classic Encrypted Custom Field, which is a separate masked text field type.

Probabilistic encryption produces different ciphertext each time and cannot be filtered or sorted on. Deterministic encryption produces the same ciphertext for the same input, so it supports exact-match filtering, at the cost of revealing which records share a value.

The limitations are the interview content. An encrypted field generally cannot be used in a WHERE clause beyond deterministic exact match, in ORDER BY, in GROUP BY, as an external ID, or in most formula criteria. A user with field access still sees plain text, so Shield replaces nothing in your sharing and FLS design.

What is Event Monitoring?

Event Monitoring exposes low level org activity, such as logins, API calls, report exports and Apex executions, as machine-readable log data. Logs arrive as EventLogFile records, queried through the API and downloaded as CSV on an hourly and daily cycle. Retention is short without the Shield licence and extends to 30 days with it, which is why most customers stream logs into an external monitoring platform.

Real-Time Event Monitoring publishes certain events as platform events you can subscribe to as they happen, which is what makes Transaction Security policies possible: block the action or demand two-factor verification when someone exports a large report.

What is Login Forensics?

The Shield capability that separates normal login behaviour from suspicious behaviour, using login event data rather than the standard login history screen. It answers what plain login history answers slowly: who logged in outside working hours, how a user's login count compares with their own average, which logins came from unfamiliar devices, and which accounts show repeated failures followed by a success.

What is Session Security?

The Setup controls deciding how long a session lives and what can use it.

• Session timeout, configurable from 15 minutes to 24 hours, with the option to force logout on timeout.
• Lock sessions to the originating IP address, which kills a stolen session ID used elsewhere but breaks users on shifting mobile networks.
• Lock sessions to the domain they were first used in, and require HTTPS.
• Session security levels. A login is Standard or High Assurance depending on how the user authenticated. You then mark a profile, connected app or report type as requiring High Assurance.
• Login IP Ranges on the profile block a login outright, unlike Trusted IP Ranges under Network Access, which only let a known network skip identity verification.

What is Content Security Policy?

A browser standard, delivered as a response header, telling the browser which origins may supply scripts, styles, images and frames for a page. Salesforce enforces it in Lightning Experience and Experience Cloud to contain cross-site scripting.

Inline JavaScript in markup is blocked, so script belongs in the component's JavaScript file or a static resource. A third party script or browser-side endpoint must be registered under CSP Trusted Sites in Setup against the directive it applies to, such as script-src, connect-src or frame-src. A library loads from a static resource through loadScript in lightning/platformResourceLoader, not from a CDN URL in the markup.

Lightning Web Security governs what component JavaScript can reach at runtime. CSP governs where the code came from.

What is Two-Factor Authentication?

A second proof of identity after the password. Multi-factor authentication is now a baseline requirement for direct Salesforce logins rather than an option you switch on when convenient.

Accepted verification methods are the Salesforce Authenticator app, any TOTP authenticator app, physical security keys using WebAuthn or U2F, and built-in device authenticators such as Touch ID or Windows Hello. Email codes, SMS codes and phone callbacks are identity verification and do not satisfy the multi-factor requirement.

The Multi-Factor Authentication for User Interface Logins permission enforces it per user, single sign-on orgs enforce MFA at the identity provider, and API-only integration users are handled through connected app and OAuth policies.

What is Zero Trust Security?

A design posture, not a product. No user, device or network is trusted by default, so every request is authenticated, authorised and logged on its own merits. In Salesforce settings:

• Identity: MFA or SSO on every login, session security levels on sensitive resources, no shared logins.
• Authorisation: least privilege through permission sets and permission set groups, profiles kept minimal, no standing Modify All Data for convenience.
• Access boundaries: login IP ranges and login hours where the role allows, connected app policies with scoped OAuth permissions.
• Detection: Event Monitoring, Transaction Security policies and Security Health Check reviewed on a schedule.
• Data: Shield encryption where justified, field-level security enforced in Apex rather than assumed.

What is Disaster Recovery in Salesforce?

A shared responsibility. Salesforce protects the infrastructure, replicating data across sites, publishing availability on Trust and running across availability zones on Hyperforce. None of that recovers records your integration overwrote at 3 am, and a bad deployment causes more incidents than an outage. Your half of the plan:

• A stated recovery point objective and recovery time objective, agreed with the business rather than assumed.
• Metadata in Git, plus a tagged commit per production release so you can redeploy the last known-good state.
• Scheduled exports through the Data Export Service, remembering that generated files are available for a limited window and that an export is not a restore.
• A backup and restore product for anything with a serious RPO, because rebuilding record relationships from CSV by hand is where recovery time is lost.
• The Recycle Bin treated as a 15 day safety net, and a restore rehearsal in a sandbox, because a backup nobody has restored is an assumption.

Salesforce does offer a paid, last-resort recovery service with a long turnaround and no guarantee of completeness. Name it as the last line, never the strategy.

What the interviewer is actually checking

• On change sets and Salesforce DX: whether you know what the tool cannot do. Knowing a change set carries no deletions, no data and no audit trail shows you have shipped with one.
• On packaging and scratch orgs: whether you pick a tool for a reason. Scratch org against developer sandbox, and unlocked against managed package, are decisions with a trade-off behind them.
• On version control and CI/CD: whether your pipeline story survives the follow-up. Which branch triggered the job, how it authenticated, what test level ran. Specificity creates credibility.
• On security: whether you understand that Apex enforces nothing by itself, and that sharing, FLS and encryption solve three different problems.
• Across all of it: whether you can debug. "The deployment failed with this coverage error, what next" tells the interviewer more than any definition you can recite.

Where to take this next

Set up a Dev Hub, create a scratch org, push source into it, then break a deployment on purpose with a missing dependency and read the error properly. Build the smallest pipeline that validates on a pull request and quick deploys on merge, and every question above becomes something you answer from memory.

If you would rather build it with guidance, the Salesforce training in Pune with placement support covers the same ground with live orgs, real work items and interview practice.