Security+ 801 Countdown, T-17: Resilience Rewritten Around Immutable Backups and Recovery Metrics

Resilience and recovery are the parts of security architecture that assume a control will eventually fail. Resilience is a system’s capacity to keep delivering service while components fail underneath it; recovery is the work of restoring service and data after an outage that resilience did not absorb. A backup is a copy of data, system state, and configuration held apart from the system it protects, so that the system can be rebuilt after loss. SY0-801 objective 3.4, “Explain the importance of resilience and recovery in security architecture,” expands the topic with four backup properties (Retention, Immutability, Scope, and Restoration testing), a Recovery metrics bullet (RTO, RPO, MTTR, and MTBF), and a Redundancy strategies and solutions bullet that gathers load balancing, clustering, autoscaling, high availability, multicloud systems, and power (CompTIA 2025).

Read together, these items describe ransomware recovery. The questions a backup program must answer are whether an attacker holding administrator rights can destroy the copies, how far back the copies reach, and whether a restore has been proven against a stated time target.

Immutability: copies an administrator cannot delete

Why attackers go after backups first

Ransomware operators target the copies as well as the data. CISA’s #StopRansomware Guide says actors “attempt to find and subsequently delete or encrypt accessible backups” (CISA 2023). On a single host the technique is ATT&CK T1490, Inhibit System Recovery, and the canonical artifact is vssadmin.exe delete shadows /all /quiet, which deletes the host’s volume shadow copies (MITRE 2026). At enterprise scale the target moves up a level: M-Trends 2026 reports Akira and Qilin operators targeting “backup infrastructure, identity services, and virtualization management planes” (Mandiant 2026). A backup that the same compromised administrator account can delete is, for planning purposes, not a backup.

WORM storage and policy state

Immutability means a stored object cannot be modified or deleted for a defined period, no matter who asks. The storage mechanism is WORM (write once, read many): during retention an object can be read but not modified or deleted. Immutability is not encryption. Encryption stops an attacker from reading a backup; immutability stops the attacker from destroying it, and an encrypted backup with no immutability protection can still be deleted.

The catch is policy state. An Azure time-based retention policy starts unlocked “for testing purposes,” and while unlocked it can be shortened or deleted; Microsoft says that unlocked policies “don’t provide delete protection.” A locked policy can only be lengthened (at most five times at container scope), and the storage account cannot be deleted while any container holds one (Microsoft 2026). With illustrative names, creating and locking a 35-day policy looks like this:

az storage container immutability-policy create --resource-group rg-backup \
  --account-name stbackupexample --container-name sql-backups --period 35

etag=$(az storage container immutability-policy show --account-name stbackupexample \
  --container-name sql-backups --query etag --output tsv)

az storage container immutability-policy lock --resource-group rg-backup \
  --account-name stbackupexample --container-name sql-backups --if-match $etag

The lock passes the policy’s current ETag as If-Match. Afterward, deleting a blob inside its 35 days fails for every identity, Owner included (headers trimmed):

DELETE /sql-backups/erp/erp-full-2026-10-30.bak HTTP/1.1
Host: stbackupexample.blob.core.windows.net

HTTP/1.1 409 Conflict
x-ms-error-code: BlobImmutableDueToPolicy

<?xml version="1.0" encoding="utf-8"?><Error><Code>BlobImmutableDueToPolicy</Code>
<Message>This operation is not permitted as the blob is immutable due to a policy.</Message></Error>

That 409 is the control working. S3 Object Lock, which requires versioning, draws the same line with modes instead of a lock step. Governance mode lets a principal holding s3:BypassGovernanceRetention override retention by sending x-amz-bypass-governance-retention:true; in compliance mode no user, root included, can delete a protected version or shorten its period (AWS n.d.). For ransomware purposes, governance mode behaves like an unlocked Azure policy: a sufficiently privileged identity can still remove the protection.

Storm-0501 and the unlocked policy

Storm-0501 shows why the state matters. Microsoft reported on August 27, 2025, that the actor, holding Azure Owner rights, ran locks/delete and immutabilityPolicies/delete, mass-deleted data stores, and encrypted what stayed protected with a customer-managed key in a new Key Vault (Microsoft Threat Intelligence 2025). Microsoft does not say whether those policies were locked; since locked policies cannot be deleted, the inference is that they were not.

Immutable storage is one layer. CISA cautions that immutable storage “does not meet compliance criteria for certain regulations” and pairs it with offline, encrypted backups (CISA 2023). NIST SP 800-53 Rev. 5 CP-9(7) adds dual authorization for deletion (NIST 2020), and backup administrator accounts belong outside the production domain. The SY0-801 objectives do not name offline copies, WORM, or object lock; treat them as the implied practice behind the single word Immutability.

Retention, scope, and restoration testing

Immutability protects a copy from change. The three remaining backup properties decide which copies exist, what is inside them, and whether they work.

Retention

Retention is how long copies are kept; immutability is whether they can change meanwhile; a legal hold freezes data until someone clears it. Retention must outlast the attacker. M-Trends 2026 puts the 2025 global median dwell time at 14 days (Mandiant 2026), so with seven days of retention every restore point may postdate the compromise. Grandfather-father-son rotation gives weekly, monthly, and yearly copies separate retention, so a long intrusion still leaves an older point. Age alone does not make a copy clean, though: CSF 2.0 RC.RP-03 calls for verifying backup integrity, including a check for indicators of compromise, before restoring (NIST 2024).

Scope

Scope is what the backup covers. CompTIA does not define the term; this interpretation follows NIST SP 800-53 Rev. 5 CP-9: user data, system-level information (OS, applications, licenses, system state), and documentation, with CP-9(3) storing critical security information, key management included, separately (NIST 2020). An encrypted backup without its keys is unrecoverable, so a scope that includes the database and excludes the key store has preserved ciphertext.

Scope also reaches into services the organization does not operate. Microsoft’s shared responsibility model leaves data, configurations, and identities with the customer even in SaaS (Microsoft 2026), so Microsoft 365 mail and the identity store are in scope for the customer’s own backups. CISA adds golden images and offline IaC templates (CISA 2023), so the environment itself can be rebuilt.

Restoration testing

Restoration testing turns the other three properties into evidence. CSF 2.0 PR.DS-11 example 2 says to test backups and restores “at least annually” (NIST 2024), and CP-9(2) calls for test restoration using sampling (NIST 2020). Restore a random point into an isolated recovery VLAN, compare hashes with the catalog, run an application consistency check, smoke-test the service, and record the clock against the targets (illustrative):

restore-test 2026-10-28 system=erp-db point=2026-10-27T23:00Z
  integrity  sha256 matches catalog; DBCC CHECKDB: 0 allocation errors, 0 consistency errors
  elapsed=3h16m     RTO=4h    PASS
  newest_txn=22:58Z RPO=24h   PASS

The two PASS lines are the point: elapsed time is checked against RTO and the newest transaction against RPO, so the restore test audits the metrics as well as the file. A green job status proves less. SQL Server’s RESTORE VERIFYONLY checks that the backup set “is complete and the entire backup is readable” but “does not attempt to verify the structure of the data” (Microsoft 2026). Readable and restorable are different claims.

Recovery metrics: RTO, RPO, MTBF, and MTTR

SY0-801 names four metrics. Two are targets the business sets; two are averages the engineering team measures.

NIST SP 800-34 Rev. 1 defines the targets. The recovery time objective (RTO) is “the maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact”; the recovery point objective (RPO) is the point in time to which data can be recovered from the latest backup; and RTO must normally be shorter than the maximum tolerable downtime (MTD) (NIST 2010). The business sets RTO and RPO. The distinction I press hardest when I teach this is direction: RPO is data loss measured backward from the failure to the last good copy, and it drives backup frequency; RTO is downtime measured forward from the failure to restored service, and it drives the site tier and the redundancy design. The business impact analysis that produces these numbers is covered at T-6, and the BC and DR plans that carry them at T-7.

Mean time between failures (MTBF) and mean time to repair (MTTR) are the measured averages: MTBF describes reliability, how long a component runs before it fails, and MTTR describes maintainability, how long a repair takes once it has. Together they give availability, A = MTBF / (MTBF + MTTR) (AWS 2021). An RTO is a target and an MTTR is a track record; an MTTR above the RTO is a gap.

Consider a server with an MTBF of 2,000 hours and an MTTR of 4 hours: 2000/2004 gives 99.80 percent, about 17.5 hours down a year. A 99.95 percent target allows 4.38 hours, so at the same MTBF, MTTR must fall to 2000 x 0.0005 / 0.9995, about 1.0 hour. The other route is to add a node. Two independent 99.80 percent nodes in active-active are both down only when both fail at once, a probability of 0.002 squared, so the pair is available 99.9996 percent of the time. The word doing the work is “independent,” and it is the case for 801’s Platform diversity sub-bullets (vendor platform, hardware, and virtualization): a shared hypervisor, power feed, or vendor bug fails both nodes at once, and the arithmetic no longer applies. Diversity under objective 3.2 is covered at T-20, and multicloud as an architecture at T-22.

Redundancy strategies and site design

The targets pick the design. The mapping below follows SP 800-34 Table 3-2 (low availability impact: tape and a cold site; high: mirroring and a hot site); the intervals are illustrative (NIST 2010).

Target	Design that meets it
RPO 24 hours	Nightly backup
RPO 15 minutes	Log backups or asynchronous replication every 15 minutes or less
RPO near zero	Synchronous replication, plus point-in-time copies
RTO days	Cold site: space, power, and environmental controls
RTO hours	Warm site: partially equipped
RTO minutes	Hot or mirrored site, or active-active HA

A cold site supplies space, power, and environmental controls with nothing installed, so recovery takes days; a warm site is partially equipped; a hot or mirrored site takes load in minutes. Replication appears in two RPO rows, and it is not a backup. Replication copies ciphertext and corruption too (CISA warns that synced cloud copies can overwrite unaffected files), hence the point-in-time copies in the near-zero row: a replica gives the current state, good or bad, and a point-in-time copy gives a state from before the damage.

Load balancing and clustering are the two ways to make several nodes act as one, and they split on state. A load balancer spreads requests across nodes and drops any node that fails its health checks; a cluster coordinates nodes that share state and fails a role over from one node to another. Autoscaling adds replicas (horizontal) or resizes instances (vertical) as load changes; a maximum capacity caps the bill when attack traffic scales you out, the condition called economic denial of sustainability. High availability (HA) is what these mechanisms deliver: the service survives component failure in place, without a recovery procedure.

Power gets four sub-bullets. A surge protector clamps voltage spikes and provides no runtime. A UPS bridges the gap until the generator starts, the arrangement SP 800-53 PE-11 describes (NIST 2020), and the power generator carries the site once it is running. A redundant power supply (RPS) is dual supplies in one device, ideally fed from separate A and B feeds.

Three sub-bullets are undefined by CompTIA, and the readings here are interpretations. Environmental, under site considerations, follows SP 800-34: an alternate site “unlikely to be negatively affected by the same hazard” as the primary, such as flood or fire (NIST 2010). Storage means the copies a storage layer keeps on its own, such as RAID or Azure LRS, ZRS, and GRS; a snapshot kept with its disk is not an isolated backup. Testing has three modes: failover moves production to the recovery system; simulation rehearses the plan in a simulated environment; parallel processing runs the recovery systems alongside production without cutover.

Business continuity and disaster recovery close the objective, and they are not synonyms. NIST SP 800-34 Rev. 1 Table 2-2 makes a continuity of operations (COOP) plan a federally mandated plan to sustain mission-essential functions at an alternate site for up to 30 days, a business continuity plan (BCP) the plan that sustains business operations during recovery, and a disaster recovery plan (DRP) a plan to relocate information systems (NIST 2010). The division of labor is then: HA survives component failure in place; DR restores systems, often elsewhere; BC keeps business functions running while that happens.

What you need to know for SY0-801

• Immutability stops deletion; encryption stops reading. An encrypted backup can still be deleted.
• Only a locked Azure policy or S3 compliance mode stops an admin or Owner; unlocked and governance modes allow a privileged override.
• Retention must exceed dwell time plus detection time.
• Scope includes SaaS data, identity stores, configurations, IaC, and backup encryption keys.
• “Backups existed but the restore failed” means restoration testing: a real restore, timed against RTO and checked against RPO.
• RPO is data loss measured back to the last good copy and drives backup frequency; RTO is downtime measured forward and drives site tier and redundancy.
• RTO is a target; MTTR is a measured average, and an MTTR above the RTO is a gap. Use CompTIA’s expansion, “Mean time to repair.”
• HA survives component failure in place; DR restores systems, often elsewhere; BC keeps business functions running.
• Continuity of operations is 701-era vocabulary; SY0-801 lists Business continuity and Disaster recovery, and NIST SP 800-34 treats COOP, BCP, and DRP as three different plans.
• Distractors: a UPS or surge protector when one power supply failed (RPS), a warm site for an RTO in minutes, and more frequent backups for deleted backups.

Check yourself

These are original practice questions, not exam items.

1. A ransomware actor used a cloud administrator account to shorten retention on the backup container, then deleted every restore point. Which change most directly prevents a repeat?

• A. Encrypt the backups with a customer-managed key.
• B. Increase backup frequency from daily to hourly.
• C. Apply a locked time-based retention policy to the backup container.
• D. Contract a warm site in a second region.

Answer: C. A locked policy cannot be shortened or deleted, even by an administrator, so the restore points survive. Encryption, frequency, and a warm site all leave the copies deletable by the same account.

2. A server has an MTBF of 2,000 hours and an MTTR of 4 hours. The availability target is 99.95 percent. Which change, by itself, meets the target?

• A. Raise MTBF to 2,500 hours.
• B. Cut MTTR to about 1 hour.
• C. Set the RPO to 15 minutes.
• D. Set the RTO to 4 hours.

Answer: B. At an MTBF of 2,000 hours, 99.95 percent requires an MTTR of about 1 hour (2000/2001). An MTBF of 2,500 with an MTTR of 4 gives about 99.84 percent, and RPO and RTO are targets, not fixes.

3. A nightly backup job has reported success for a year. During an outage, the restored database fails consistency checks and the team misses its four-hour RTO. Which SY0-801 backup element was missing?

• A. Retention.
• B. Immutability.
• C. Scope.
• D. Restoration testing.

Answer: D. A success status, like RESTORE VERIFYONLY, proves the file is readable, not that the system comes back. Only a real, validated, timed restore proves that.

This is T-17 of the Security+ 801 Countdown: one change from SY0-701 to SY0-801 every morning until the new exam launches on November 17, 2026. Tomorrow, T-16: Objective 4.1 Becomes the Mitigating-Controls Catalog. New here? Start with T-38: The Blueprint Was Reweighted and Trimmed to 27 Objectives.

References

Amazon Web Services. 2021. “Understanding Availability.” In Availability and Beyond: Understanding and Improving the Resilience of Distributed Systems on AWS. AWS Whitepaper, November 12, 2021.

Amazon Web Services. n.d. “Locking Objects with Object Lock.” Amazon S3 User Guide. Accessed October 12, 2026.

CISA. 2023. #StopRansomware Guide. Version 3.0, October 2023.

CompTIA. 2023. CompTIA Security+ SY0-701 Certification Exam Objectives. Version 5.0.

CompTIA. 2025. CompTIA Security+ SY0-801 V8 Certification Exam Objectives. Document Version 2.0.

Mandiant. 2026. “M-Trends 2026.” Google Cloud Threat Intelligence blog, March 23, 2026.

Microsoft. 2026. “Immutable Storage for Blob Data Overview.” Microsoft Learn. See also “Configure Immutability Policies for Containers,” “Container-Level WORM Policies for Immutable Blob Data,” “Blob Storage Error Codes,” “Shared Responsibility in the Cloud,” “Azure Backup Glossary,” and “RESTORE VERIFYONLY.” Accessed October 12, 2026.

Microsoft Threat Intelligence. 2025. “Storm-0501’s Evolving Techniques Lead to Cloud-Based Ransomware.” Microsoft Security Blog, August 27, 2025.

MITRE. 2026. “Inhibit System Recovery, T1490.” MITRE ATT&CK. Version 1.6, last modified May 12, 2026.

NIST. 2010. Contingency Planning Guide for Federal Information Systems. NIST SP 800-34 Rev. 1.

NIST. 2020. Security and Privacy Controls for Information Systems and Organizations. NIST SP 800-53 Rev. 5.

NIST. 2024. The NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29. See also the CSF 2.0 Implementation Examples.