Companion to 07_Topic07_DevOps_SFDX.md — open ONLY after you have written your own attempt.

Protocol (file 00): write ≥2 hypotheses + 2 solution attempts before reading. Then compare your attempt against this sheet like an investigator comparing a suspect's story to the evidence. The contrast IS the learning. Then REDO from memory, then do the drill.

INCIDENT 1 — THE FIELD THAT WOULDN'T DIE

The problem restated

A Change Set reported 100% success but a field deleted in sandbox still exists in production. What can Change Sets never do, what fixes it, and what's the corrected process?

Model answer (2-min interview version)

Change Sets are additive/metadata-only — they can add or update components in the target org, but they can never delete a component. There's no delete action in the Change Set model; the "100% success" was true because everything IN the Change Set deployed — the deletion was simply never in it.
The only programmatic deletion path: a destructive-changes manifest — destructiveChangesPre.xml (deletions before the rest of the package deploys — for renames/replacements) or destructiveChanges.xml (deletions after — the common cleanup case), paired with package.xml, deployed via Metadata API / SFDX (sf project deploy start --pre-destructive-changes / --post-destructive-changes) or a CI pipeline.
Corrected process: author destructiveChanges.xml listing the field as a CustomField member, deploy explicitly, then verify by retrieving metadata from prod and confirming absence — never trust the deploy success log alone.
Other Change Set limits to know cold: 10,000 files / 400MB cap; one-directional (needs an explicit deployment connection between the two specific orgs); 30-day expiry after upload; no rollback of a successful deploy; no version control/code review/CI. Validate vs Deploy vs Quick Deploy: Quick Deploy reuses a prior successful validation's test run within a 10-day cache window.

Self-grade checklist

Change Sets cannot delete components — ever
destructiveChangesPre.xml vs destructiveChanges.xml — named and differentiated
Corrected process includes verification (retrieve + confirm absence), not just deploy success
Change Set size/expiry/rollback limits named (10,000 files/400MB, 30 days, no rollback)
Quick Deploy's 10-day cache window mentioned

THE REDO — model answer

Change Sets: additive/metadata-only, cannot delete, one-directional, 10,000 files/400MB,
             30-day expiry, no rollback of successful deploy.
Deletion path: destructiveChangesPre.xml (before) / destructiveChanges.xml (after) + package.xml
             → sf project deploy start --post-destructive-changes destructiveChanges.xml
Verify: retrieve metadata post-deploy, confirm field absent — never trust the deploy log alone.

RETRIEVAL DRILL — model answers

Can a Change Set delete a component? → No, never — Change Sets are additive/update-only.
The two destructive-changes manifests? → destructiveChangesPre.xml (deletes before the rest of the package deploys) and destructiveChanges.xml (deletes after).
Change Set size/file limits? → 10,000 files / 400MB.
Change Set expiry after upload? → 30 days.
Quick Deploy reuses what, and for how long? → A prior successful validation's test results, reusable within a 10-day cache window, skipping re-running tests on the real deploy.

INCIDENT 2 — THE SCRATCH ORG THAT VANISHED AT MIDNIGHT

The problem restated

Three weeks of unpushed work in a scratch org disappeared on expiry. Is it recoverable, what's the lifecycle rule, and what's the corrected workflow?

Model answer (2-min interview version)

Verdict: not recoverable. Scratch orgs have a hard maximum life of 30 days; on expiry the org and everything unpushed inside it is permanently deleted — no recycle bin, no support-ticket recovery.
Dev Hub economics: roughly 40 active scratch orgs concurrently / 80 created per day per Dev Hub (edition-dependent), each capped around 200MB storage — numbers that exist because a scratch org is meant to be reproducible from source, not stored in.
Scratch org ≠ sandbox: scratch orgs are ephemeral, definition-file-driven, source-first; sandboxes are refresh-based copies of production's org shell, not subject to a 30-day expiry-and-delete clock.
The corrected workflow: commit to the feature branch daily in small increments (not "when it's done"); treat the scratch org as disposable compute — rebuild from source in minutes via sf org create scratch + sf project deploy start; track expiry proactively (sf org list shows days remaining) and flag scratch orgs nearing expiry with uncommitted work; script data setup so it's reproducible too, never uniquely stored in the org.

Self-grade checklist

Verdict stated clearly: unrecoverable, and why (permanent deletion, no support recovery)
30-day hard max life named
Dev Hub active/daily caps + ~200MB storage named
Scratch org vs sandbox distinction stated
Corrected workflow: daily commits + org treated as disposable compute

THE REDO — model answer

Verdict: gone — scratch org expired = permanently deleted, no recovery.
Lifecycle: 30-day max life; ~40 active / 80 daily per Dev Hub; ~200MB storage.
Scratch org ≠ sandbox (ephemeral/source-driven vs refresh-based org-shell copy).
Fix: commit daily to feature branch; scratch org = disposable compute, rebuilt from
     source in minutes; track expiry proactively; script data setup into the repo too.

RETRIEVAL DRILL — model answers

Max scratch org lifespan? → 30 days.
What happens on expiry? → Permanent deletion — no recovery.
Dev Hub limits? → Roughly 40 active / 80 created per day (edition-dependent).
Scratch org storage cap? → ~200MB.
The actual single source of truth? → Git — every org (scratch, sandbox, prod) is a deployable/disposable target, never the record of truth.

INCIDENT 3 — THE PIPELINE THAT PASSED AND STILL BROKE PROD

The problem restated

CI was green with RunLocalTests, but a managed-package integration seam broke production. Name the four test levels, explain the gap, and fix the release process.

Model answer (2-min interview version)

The four test levels: NoTestRun (no tests; sandboxes/scratch orgs/validation-only checks; not legal for production deploys), RunSpecifiedTests (only named classes), RunLocalTests (every local Apex test, excluding managed-package test classes), RunAllTestsInOrg (everything, including package tests).
Why RunLocalTests let this through: the level ran every local test correctly — the gap was that no local test existed exercising the call into the managed package's changed method. Aggregate coverage (≥75% required for production) was satisfied by unrelated well-tested classes; aggregate coverage percentage is not the same as coverage of the specific at-risk integration path.
The fix: risk-based test-level selection (escalate to RunSpecifiedTests naming boundary tests, or RunAllTestsInOrg, for releases touching package integration points); mandatory boundary tests for any class calling a managed package's public API (mock/stub the seam); a validation-only deploy gate on every PR against a sandbox that mirrors production's installed packages.

Self-grade checklist

All four test levels named with what each covers/excludes
RunLocalTests explicitly excludes managed-package tests
Aggregate coverage ≠ coverage of the at-risk path — stated explicitly
Fix: boundary/seam tests for managed-package calls
Fix: risk-based test-level escalation + PR-level validation-only gate

THE REDO — model answer

Levels: NoTestRun / RunSpecifiedTests / RunLocalTests (excludes managed-pkg tests) / RunAllTestsInOrg
Gap: no local test existed for the NightlyIntegrationBatch → package call; aggregate
     coverage (75%+) came from unrelated classes.
Fix: boundary test at every managed-package seam; escalate test level for
     integration-touching releases; PR-level validation-only deploy against a
     package-mirrored sandbox.

RETRIEVAL DRILL — model answers

Four test levels? → NoTestRun, RunSpecifiedTests, RunLocalTests, RunAllTestsInOrg.
RunLocalTests excludes? → Managed-package test classes.
Minimum aggregate coverage for production? → ≥75%.
Why did green CI still miss it? → No test existed for the specific integration path; aggregate coverage doesn't measure coverage of specific at-risk code.
Fix for a managed-package seam? → A dedicated boundary/unit test mocking or exercising that call path directly.

INCIDENT 4 — THE MANAGED PACKAGE THAT BROKE EVERY SUBSCRIBER

A field rename in a push-upgraded managed package broke every subscriber's Flow simultaneously. Name the packaging concept violated, why renames are uniquely dangerous, and the corrected release discipline.

Model answer (2-min interview version)

Packaging concept violated: managed packages (1GP legacy / 2GP modern) promise backward compatibility as their core value — subscribers install a black box and expect versioned, non-breaking upgrades. Salesforce blocks deleting a global member outright at package-version creation, but a rename achieves the same subscriber-facing break if not caught by that check.
Why renames are uniquely dangerous here (vs. unmanaged code): subscribers reference the package's public surface by name through declarative tools (Flow) with no compiler warning and no code visibility into the ISV's obfuscated Apex — they cannot pre-empt or patch around the break; an internal-org rename is a one-repo problem, this is a "every independent customer org breaks simultaneously" problem, and rollback (downgrade) is itself restricted for managed packages.
Corrected discipline: additive-only public API evolution (add orderAmountV2, deprecate amount over 2+ major versions, never rename/remove global members); staged rollout (beta/pilot cohort + deprecation notice, not silent mandatory push); breaking changes go into a new major version subscribers opt into; automated compatibility tests running the previous major version's contract against every new build before release.

Self-grade checklist

Backward-compatibility promise named as the core managed-package value violated
Explains why subscribers can't patch around it (declarative name-reference, no visibility, downgrade restricted)
Additive-only API evolution stated as the fix
Staged/opt-in rollout for breaking changes vs. silent push upgrade
Automated compatibility test suite mentioned

THE REDO — model answer

Violated: managed-package backward-compatibility promise (global members treated as permanent).
Why unique: subscribers reference by name via declarative tools, no visibility, no compiler
            warning, downgrade restricted — one ISV mistake breaks every customer at once.
Fix: additive-only (new field/method, deprecate old), staged/opt-in rollout for breaking
     changes, compatibility test suite vs. previous major version before every release.

RETRIEVAL DRILL — model answers

Unlocked vs Managed — when each? → Unlocked: internal multi-team modularization, CI/CD-friendly, not IP-protected. Managed: AppExchange/IP-protected distribution with a versioned upgrade contract.
Can you delete a global member from a released package version? → No — Salesforce blocks it at package-version creation.
Why is a rename as dangerous as a deletion here? → Subscribers reference the old name by string in declarative tools; a rename removes that reference's target just like a deletion would.
What's a push upgrade, and when avoid it? → ISV-forced version bump on all installed orgs; avoid for breaking changes — reserve for additive/security fixes; breaking changes should be subscriber-initiated major-version upgrades.
Safeguard before every new package version ships? → An automated compatibility test suite exercising the previous major version's public contract.

INCIDENT 5 — THE REFRESH THAT ERASED THE INTEGRATION

The problem restated

A sandbox refresh broke OAuth/integration and reset passwords, and "shouldn't have touched anything." What always resets on refresh, what interface automates recovery, and what's the runbook?

Model answer (2-min interview version)

What ALWAYS resets, regardless of sandbox type: (1) all OAuth tokens/active sessions invalidated (breaking Named Credentials/Connected Apps); (2) every user password reset, forcing a reset flow; (3) outbound email deliverability defaults to "System email only." These are guaranteed platform behaviors on every refresh — Developer, Developer Pro, Partial Copy, or Full.
The interface built for this: SandboxPostCopy — implement runApexClass(SandboxContext context); Salesforce automatically invokes it immediately after a refresh completes, keyed per sandbox via context.sandboxName(). It's the documented place to trigger Named Credential re-auth/notifications, reset feature-flag Custom Metadata, and redirect endpoints.
The runbook: pre-refresh notice to integration owners (OAuth invalidation is guaranteed, not a maybe); a SandboxPostCopy class deployed in advance for automated remediation/notification; a documented post-refresh checklist (re-authorize Named Credentials, communicate password reset, verify email deliverability setting, re-point sandbox-only config); treat refresh with production-deploy-level change management.

Self-grade checklist

Three guaranteed resets named (OAuth/sessions, passwords, email deliverability)
Stated these happen on EVERY sandbox type, not just Full
SandboxPostCopy interface named with its method and trigger timing
Pre-refresh notice as part of the runbook
Post-refresh checklist items named

THE REDO — model answer

Always resets (any sandbox type): OAuth/session tokens invalidated, passwords reset,
  outbound email → System email only.
Automation: SandboxPostCopy.runApexClass(SandboxContext) — auto-invoked right after refresh.
Runbook: pre-refresh notice → SandboxPostCopy deployed in advance → post-refresh checklist
  (re-auth Named Credentials, comms on password reset, verify email setting, re-point config).

RETRIEVAL DRILL — model answers

Three guaranteed resets? → OAuth/session invalidation, password reset, email deliverability set to System-only.
Interface + method for automated remediation? → SandboxPostCopy interface, runApexClass(SandboxContext context).
Refresh intervals? → Developer/Developer Pro: 1 day; Partial Copy: 5 days; Full: 29 days.
Storage caps? → Partial Copy: 5GB data + 5GB files (max ~10k records/object via template); Full: complete copy of production.
Does Developer Pro differ from Full on OAuth/password reset? → No — those three resets are guaranteed on every sandbox type, regardless of size/refresh cadence.

INCIDENT 6 — THE PROMOTION THAT JUMPED THE QUEUE

The problem restated

An out-of-order hotfix promotion silently reverted a shared Apex class to an older version instead of failing the deploy. Explain the mechanism, the conflict-detection gap, and the hotfix-lane fix.

Model answer (2-min interview version)

The mechanism: promotion-based tools (Copado's Promotion, Gearset's org diff) move the metadata snapshot associated with the story from its current environment — promoting #4033 out of order pulled whatever version of the shared class existed in that environment, which was behind #4021's newer pending edit. The deploy succeeded because nothing conflicted with Production's current state — it just silently carried an older file forward. A successful deploy, not a failure, is exactly why nobody caught it immediately.
Why conflict detection missed it: these tools typically diff the incoming promotion against the target org's current state only — they don't simulate cross-environment lineage (two stories, in different pipeline stages, both eventually reaching the same target). That's an ordering/lineage problem, structurally invisible to a point-in-time diff.
The fix — a dedicated hotfix lane: cut hotfix branches from Production's actual current state (never from a mid-pipeline environment that might be behind); promote through an expedited but still-ordered/approved path; immediately back-merge the hotfix into every open release branch; add a file-ownership/communication norm flagging when two active stories touch the same file.

Self-grade checklist

Names Promotion vs Deployment vocabulary correctly
Explains WHY it was a silent success, not a failure
Names the conflict-detection blind spot (target-state diff, not cross-environment lineage)
Hotfix lane cut from Production's true state, not mid-pipeline
Mandatory back-merge into pending release branches

THE REDO — model answer

Mechanism: promotion carries the story's environment snapshot; #4033's promotion pulled
  an older PricingCalculator.cls, behind #4021's pending newer edit — deploy succeeded,
  silently reverted shared code.
Gap: conflict detection diffs incoming change vs target org only, not cross-environment
  lineage between not-yet-promoted stories.
Fix: hotfix lane cut from Production's current state, expedited but ordered/approved,
  immediate back-merge into all pending release branches, file-touch coordination alert.

RETRIEVAL DRILL — model answers

Promotion vs Deployment (Copado)? → Promotion: commit a story's metadata forward through the pipeline from its current environment. Deployment: push a specific package/version to a target org.
Why no deploy error? → The promoted metadata didn't conflict with Production's current state — it simply carried an older file version forward silently.
What conflict detection catches vs misses? → Catches same-target, same-time divergent changes; misses cross-environment lineage conflicts between stories that haven't both reached the target yet.
Four parts of a safe hotfix lane? → Cut from Production's true current state; expedited but ordered/approved path; mandatory immediate back-merge into pending branches; file-touch coordination alerts.
Gearset's headline differentiator? → Metadata comparison/diff-driven automated deploys, scheduled backups, one-click rollback.

INCIDENT 7 — THE JWT THAT WORKED ON TUESDAY

The problem restated

CI's JWT auth suddenly fails with invalid_grant: user hasn't approved this consumer. Name the JWT flow's moving parts, each one's failure mode, and the resilient setup.

Model answer (2-min interview version)

The moving parts and failure modes: (1) self-signed certificate — breaks on expiry (invalid_grant: invalid assertion-type error, not this one); (2) Connected App consumer key — breaks if regenerated without updating CI's stored secret; (3) pre-authorization ("Admin approved users are pre-authorized" + the integration user's profile/permission-set assignment to the Connected App) — breaks if that assignment is removed, e.g., by an unrelated permission-set cleanup — this produces exactly invalid_grant: user hasn't approved this consumer; (4) IP relaxation/login IP ranges — breaks with a distinct ip restricted error.
The likely culprit given the exact error text: the pre-authorization/permission-set assignment, not the certificate.
The resilient setup: dedicated integration user with access via a permission set (not baked into a profile likely to be refactored); certificate expiry monitored via an automated check well ahead of expiry with a rotation runbook; a pre-flight auth-only smoke test in CI that fails fast and isolates "auth broke" from "the deploy broke"; change-management review that explicitly checks Connected App/integration-user impact before any permission-set or profile cleanup merges.

Self-grade checklist

All four JWT moving parts named
Correctly maps THIS error to pre-authorization, not certificate expiry
Permission set (not profile) for integration user access, with reasoning
Pre-flight auth-only smoke test in CI
Change-management check before permission-set/profile cleanups

THE REDO — model answer

Parts: certificate (expiry), consumer key (rotation), pre-authorization/permission-set
  (removed by unrelated cleanup — THIS error), IP relaxation (tightened ranges).
Fix: integration user via permission set; cert-expiry monitoring; pre-flight auth smoke
  test in CI; change-review gate on any permission-set/profile cleanup for Connected
  App impact.

RETRIEVAL DRILL — model answers

Four moving parts? → Certificate, consumer key, pre-authorization/permission-set assignment, IP relaxation/login IP ranges.
Error text for lost pre-authorization vs expired cert? → invalid_grant: user hasn't approved this consumer (pre-auth) vs an invalid assertion-type error (expired/invalid cert signature).
Why permission set over profile? → Permission sets are additive and reviewed independently — far less likely to be silently stripped during an unrelated profile refactor/cleanup.
Value of a pre-flight auth-only smoke test? → Isolates "CI auth infra is broken" from "the deploy itself failed," saving diagnostic time.
Other silent blocker besides certs/permissions? → IP relaxation / login IP range tightening blocking the CI runner's egress IP.

INCIDENT 8 — THE CANDIDATE WHO ONLY KNEW CHANGE SETS

The problem restated

A candidate's entire deployment answer was Change Sets, and three follow-ups exposed gaps. Name the three gaps, explain why "no Git" is worst, and give the correct 2-minute answer.

Model answer (2-min interview version)

The three gaps: (1) no Git — no diff history, no code review, no CI gate, no single source of truth; (2) no rollback plan — the candidate didn't know Change Sets have no rollback of a successful deploy, and can't delete either; (3) no branch/scratch-org-per-feature model — parallel work collides in a shared sandbox and gets reconciled by hand instead of via Git merge.
Why "no Git" is the worst: it's not a missing feature, it's the missing foundation — every other 2026 practice (CI gates, code review, automated testing, packaging, rollback, parallel branches) is built on top of "metadata is versioned text in a repo." Without it, nothing else can be bolted on without a foundational migration first.
The correct 2-minute answer: Git as source of truth (SFDX project, force-app/main/default, feature branches) → scratch orgs (or dev sandboxes) per feature → PR triggers a validation-only deploy with RunSpecifiedTests/RunLocalTests as a CI gate → merge to develop/integration branch → deploy to integration sandbox → release branch → UAT → main → Production via CI with full coverage → rollback is a Git revert + redeploy (or a tool with built-in rollback), never "a new Change Set to undo it." Change Sets get one calibrated sentence: fine for a single quick admin-only move, never the primary pipeline.

Self-grade checklist

All three gaps named specifically (not just "doesn't know SFDX")
Explains why the Git gap is foundational, not just one more missing feature
Full branch→environment mapping given in the model answer
Correct rollback story (Git revert/redeploy or dedicated tool, never "new Change Set")
Change Sets placed correctly (minor legitimate tool, not the whole answer)

THE REDO — model answer

Gaps: (1) no Git = no source of truth/CI/review; (2) no rollback story (Change Sets have
  none, can't delete either); (3) no branch/scratch-org-per-feature model.
Worst: no Git — foundational, everything else depends on it.
Model answer: Git → feature branch → scratch org → PR + validation-only CI gate →
  develop → integration sandbox → release branch → UAT → main → Production (full
  coverage). Rollback = Git revert + redeploy. Change Sets = one-off admin tool only.

RETRIEVAL DRILL — model answers

What's structurally missing if the whole answer is "Change Sets"? → A Git-based source of truth — and everything downstream of it (CI, review, rollback, branching).
Why can't you "make a new Change Set to undo" a bad deploy? → Change Sets have no rollback of a successful deploy, and can't delete components either — reconstructing prior state manually is error-prone and incomplete.
What replaces manual sandbox merging? → Feature branches + scratch orgs (or isolated dev sandboxes) per developer/feature, merged via Git with a real diff/conflict view.
Branch → environment mapping? → Feature → scratch org/dev sandbox → develop → integration sandbox → release branch → UAT → main → Production.
Correct calibrated way to mention Change Sets? → As a legitimate but minor tool for a single quick admin-driven metadata move between two connected orgs — never as the primary team pipeline.

🏆 CAPSTONE — THE RELEASE THAT ATE ITSELF (model report)

Symptom-by-symptom root cause:
- A (managed-package integration failure) → Incident 4's class: the vendor's auto-push package update made a breaking API change on a public surface the subscriber's code depended on, with no compatibility testing on either side before the push. Fix: pin/stagger package version adoption where possible, add a boundary test around the integration call, and push the vendor (or internal package owner) toward additive-only API discipline.
- B (CI JWT auth failure) → Incident 7's class, with the exact trigger event named in the report: the "permission-set consolidation" removed 14 "unused" permission sets — one of which was the integration user's Connected App pre-authorization grant. Fix: restore/recreate the permission set granting Connected App access to the CI integration user; going forward, any permission-set/profile cleanup requires an explicit "does this touch Connected App/integration access" check.
- C (two bundled root causes) → (i) Incident 5's class: the Full sandbox refresh guaranteed a password reset and session/OAuth invalidation, breaking every Selenium login test that assumed stable credentials — fix: pre-refresh notice to QA, update Selenium's credential-refresh step, and implement SandboxPostCopy to automate what can be automated. (ii) Incident 1's class, resurfacing: last month's "Change Set cleanup" never actually removed Discount_Override__c because Change Sets cannot delete components — the field never left production; fix: author destructiveChanges.xml for the field now, and add a mandatory post-deploy retrieve-and-verify step to the release checklist so this class of failure can never silently persist for a month again.
Priorities (what to say first at the 2:00 PM sync): Tonight — restore the CI integration user's permission-set access (B is blocking every future deploy, highest leverage per minute spent) and file the compliance-flagged field deletion (C-ii) via destructiveChanges.xml with verification, since it's a repeat compliance exposure. This week — assess the managed-package break (A) with the vendor/internal package owner and add the boundary test; fix the Selenium suite's credential assumptions (C-i) and stand up a SandboxPostCopy class. This quarter — the structural fix: a change-management checklist applied to every "small, unrelated" change (permission-set edits, sandbox refreshes, package updates, destructive changes) that currently ships with zero review of its blast radius; also flag the US-5190 out-of-order hotfix promotion as a latent Incident-6-class risk to fix with a proper hotfix lane before it causes a fourth incident.
The one systemic root cause: "None of these three symptoms are isolated bugs — they're all the same governance gap: the org has no discipline that treats 'small, unrelated' operational changes (a permission-set cleanup, a sandbox refresh, a vendor package auto-update, a Change Set cleanup) as release-worthy events requiring their own verification. Each one shipped with zero review of its blast radius, and each one silently broke something nobody was watching."
The verification/regression checklist (for every future release):
- Any permission-set or profile change is reviewed for Connected App / integration-user impact before merge.
- Any sandbox refresh has a pre-notice to integration/QA owners and a deployed SandboxPostCopy class (or a documented manual checklist if none exists yet).
- Any managed-package version bump (vendor or internal) is tested against a boundary/compatibility test suite before being allowed into production, and push-upgrades of internal packages are staged, never blanket.
- Any destructive change (field/component removal) is verified by retrieving metadata post-deploy and confirming absence — never trusted from deploy-success status alone.
- Any hotfix promoted out of standard pipeline order goes through a defined hotfix lane (cut from Production's current state, expedited-but-approved, immediately back-merged into all open release branches) — never an ad hoc skip.
The 2-minute answer (say out loud at the sync): "All three symptoms this week trace back to one root cause, not three separate bugs: we have no discipline that treats routine-looking operational changes — a permission-set cleanup, a sandbox refresh, a vendor package update, a Change Set field removal — as release-worthy events that need their own review and verification. The permission-set consolidation silently broke our CI's Connected App access; the sandbox refresh did exactly what refreshes always do — invalidate sessions and reset passwords — and nobody had a runbook or a SandboxPostCopy class ready for it; and a field we 'deleted' last month never actually left production because Change Sets can't delete components, and nobody verified the retrieved metadata afterward. Tonight I'm restoring CI's access and filing a proper destructive-changes deploy with verification for the field. This week I'm adding a compatibility test around the managed-package integration and fixing the Selenium credential assumptions. And starting this release, every one of these 'small, unrelated' change types goes through a checklist before it ships — because right now, none of them do."

KNOWLEDGE SPINE — rapid-fire (model answers)

Can a Change Set delete a component? → No — additive/update-only.
Two destructive-changes manifests? → destructiveChangesPre.xml (before) / destructiveChanges.xml (after).
Change Set file/size limit? → 10,000 files / 400MB.
Change Set expiry? → 30 days after upload.
Quick Deploy cache window? → 10 days.
Scratch org max life? → 30 days, then permanent deletion.
Dev Hub scratch org caps? → ~40 active / 80 per day (edition-dependent).
Scratch org storage cap? → ~200MB.
Test level that excludes managed-package tests? → RunLocalTests.
Minimum coverage for production deploy? → 75%.
Managed package: can you delete a global member post-release? → No.
Unlocked vs Managed — core difference? → Unlocked: internal/CI-friendly, not IP-protected. Managed: IP-protected, AppExchange, versioned compatibility contract.
Sandbox refresh — three guaranteed resets? → OAuth/session invalidation, password reset, System-only email.
Interface for post-refresh automation? → SandboxPostCopy (runApexClass(SandboxContext)).
Sandbox refresh cadences? → Developer/Dev Pro: 1 day; Partial Copy: 5 days; Full: 29 days.
Copado: Promotion vs Deployment? → Promotion = move a story's metadata through the pipeline; Deployment = push a package/version to a target org.
Gearset's headline feature? → One-click rollback + automated metadata-diff deploys + backup.
JWT auth error for lost pre-authorization? → invalid_grant: user hasn't approved this consumer.
Why use a permission set for CI integration users? → Additive, independently reviewed, less likely to be silently stripped by a profile cleanup.
The 2026 interview red flag? → Naming only Change Sets as your deployment process, with no Git-based pipeline behind it.

INTERLEAVED PRACTICE SET — model answers

Limit hunt: (a) Module 7 — Change Sets can't delete (Incident 1); (b) Module 7 — RunLocalTests excludes managed-package tests (Incident 3); (c) Module 7 — sandbox refresh always resets OAuth/passwords/email (Incident 5); (d) Module 7 — JWT pre-authorization silently removed by a permission-set cleanup (Incident 7); (e) Module 7 — promotion tools diff against target state only, missing cross-environment lineage conflicts (Incident 6).
Design (2 min): a CI/CD pipeline for a 10-developer team shipping weekly — Git as source of truth, feature branches → scratch orgs per feature, PR triggers validation-only deploy with RunSpecifiedTests as the CI gate, merge to develop → integration sandbox, release branch → UAT (Partial Copy sandbox), main → Production via CI with RunAllTestsInOrg/coverage gate; packaging via Unlocked packages for internal modularity; rollback via Git revert + redeploy; a documented hotfix lane cut from Production's current state with mandatory back-merge.
Module-4 bridge: the order-of-execution and fault-path disciplines from Module 4 apply directly to Module 7's fault-aware release design — just as a Flow's "success" isn't proof of convergence, a Change Set's "100% success" isn't proof of a completed change (Incident 1); both require verification (a queryable convergence field / a post-deploy metadata retrieve), not trust in a green status.
Module-6 bridge: the "boundary/seam test" discipline from Module 6's mocking lesson is exactly the fix for Incident 3's managed-package test gap — treat any call into a package's public API as an external dependency requiring its own explicit test with a mock/stub, never assumed covered by aggregate percentage.
One-card answer (5 bullets + incident map): (1) Git is the foundation — Change Sets alone is a red flag (I1/I8); (2) know every environment's exact numeric limits and expiry (I1/I2/I5); (3) pick the right test level and packaging model for the risk (I3/I4); (4) treat "small unrelated" changes (permission-set edits, refreshes, package pushes, deletions) as release-worthy events needing verification (I5/I7/Capstone); (5) hotfixes need a dedicated lane with back-merge, never an ad hoc pipeline skip (I6).

THE ONE-CARD ANSWER KEY (carry this)

"Walk me through how your team deploys changes" — 5 lines:

Git is the source of truth, not Change Sets: SFDX project (sfdx-project.json, force-app/main/default, .forceignore), feature branches, scratch orgs per feature. Change Sets are a minor one-off tool, never the primary pipeline.
Know the exact numbers for every environment: Change Set 10,000 files/400MB/30-day expiry/no rollback/no delete; scratch org 30-day max life/permanent deletion/~200MB; sandbox refresh cadences (Dev 1d, Partial 5d, Full 29d) and its three guaranteed resets (OAuth, password, email).
Validate before you deploy: the four test levels (NoTestRun/RunSpecifiedTests/RunLocalTests/RunAllTestsInOrg), RunLocalTests excludes managed-package tests, ≥75% coverage for production, validation-only PR gates.
Deletion is deliberate, never assumed: destructiveChangesPre.xml/destructiveChanges.xml are the only programmatic deletion path — always verify by retrieving metadata post-deploy.
Pick tooling to match team maturity and name the tradeoffs: Unlocked packages for CI-friendly internal modularity, Managed for AppExchange with a backward-compatibility promise; DevOps Center (native, GitHub-only) vs Copado (Promotion/Deployment, Pipelines, approval gates, hotfix lanes) vs Gearset (diff-driven deploys, backup, one-click rollback) — and a defined hotfix lane with mandatory back-merge.

Numbers to say cold: Change Set 10,000 files / 400MB / 30-day expiry / 10-day Quick Deploy cache · scratch org 30-day max life / ~40 active / ~80 daily / ~200MB · sandbox refresh: Developer & Dev Pro 1 day, Partial Copy 5 days, Full 29 days · Partial Copy 5GB data+files / ~10k records per object · production coverage ≥75% · destructiveChangesPre.xml (before) / destructiveChanges.xml (after) · SandboxPostCopy.runApexClass(SandboxContext) · sf CLI (force:* deprecated).

Module 7 — ANSWER SHEET (SEALED)

On this page