Environment risks, backup and business continuity
Which environment risks an architect must plan for and how to mitigate each: coordinated multi-system releases with additive changes, data backups that metadata rollback cannot replace, tested restores, kept pipeline artifacts, capacity and load testing before peaks, deployment windows with notice and post-deploy checks, and continuity plans for communication and vendors.
Understand customer environment risks and articulate appropriate mitigation strategies.
~8 min read · 13 practice questions ·
What the exam expects
- Recommend a backup and restore strategy that separates metadata (restored by redeploying from source) from record data (restored only from a backup taken before the change), and test restores on a schedule.
- Mitigate cross-system release risk with coordinated releases, compatibility testing and additive interface changes.
- Plan business continuity for people, communication channels and vendor dependencies.
- Reduce release risk with kept pipeline artifacts, capacity projection, production-scale load tests, deployment windows, stakeholder notice and post-deployment checks.
Key terms: RTO (maximum acceptable downtime after a failure); RPO (maximum acceptable data loss, measured in time); additive change (adding a field or element instead of renaming or removing one); build artifact (the deployment package, test results, scan reports and logs a pipeline run keeps); deployment window (a planned low-usage period for a release).
Key facts
- Detail
- Redeploy the previous version; no native rollback command
- Detail
- Need a pre-deployment backup to restore
- Detail
- Holds deleted items, not prior values of updated records
- Detail
- Every 7 days (weekly export) or 29 days; files need their own options; zips deleted after 48 hours; not in sandboxes
- Detail
- Set by RPO; daily backup gives a 24-hour RPO; native export has no point-in-time restore
- Detail
- Quarterly, into scratch orgs or developer sandboxes
- Detail
- Keep packages, test results, scan reports and logs
- Detail
- Processed in series, not parallel
- Detail
- Runs as the Automated Process user, which lacks access to some objects
- Detail
- Smoke tests, then enhanced monitoring for 24-48 hours
Sources for this section (7)
- Operational Excellencearchitect.salesforce.com (opens in a new tab)
- Recycle Binhelp.salesforce.com (opens in a new tab)
- Export Backup Datahelp.salesforce.com (opens in a new tab)
- Reliabilityarchitect.salesforce.com (opens in a new tab)
- DevOps Patternsarchitect.salesforce.com (opens in a new tab)
- Sandbox Best Practiceshelp.salesforce.com (opens in a new tab)
- SandboxPostCopydeveloper.salesforce.com (opens in a new tab)
- Why does a release that bulk-updates records need a backup even when every version is tagged in Git?
- When is a backup trustworthy?
- Why do several sandbox refreshes started together appear stuck?
- What should stakeholders hear before a deployment window?
The questions are free to read. Answers with their sources and self-grading are included with the pack.
Keep reading with the Platform Development Lifecycle and Deployment Architect pack
- Core concepts
- Exam traps
- Worked scenario
The pack includes:
- All 26 lessons of the Platform Development Lifecycle and Deployment Architect guide, with reading progress
- Interactive decision walks and step-by-step sequence steppers
- Inline practice questions and one-click topic practice (13 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Unlimited timed practice exams