Resiliency Flashcards

Redundancy = having a spare component available, but not running. If the primary fails, the spare must be found, installed, configured, and started — potentially taking minutes to hours. High availability (HA) = all components already powered on and serving real traffic simultaneously. If one fails, others immediately absorb the load — zero service interruption. The key difference is the "switchover window." Redundancy has one; HA does not. HA always costs more — you are running and paying for all components continuously. The exam may describe HA as "always on, always available."

Multiple components simultaneously handling production traffic. All nodes are active and sharing the load at all times — no component is standing by idle. If one component fails, the remaining active components absorb its share immediately — they were already serving requests. Active/active provides: (1) fault tolerance — failure of one node doesn't interrupt service; (2) scalability — adding nodes increases total capacity; (3) efficiency — all hardware is earning its keep. Exam note: "Active/active can provide scalability advantages" is specifically cited in the exam objectives. Contrast: active/passive — one handles all traffic while the other waits idle.

Both distribute work across multiple servers — but differently. Clustering: nodes know about each other; cluster software coordinates them; shared storage so all nodes access same data; typically requires same OS on all nodes. Load balancing: servers are completely unaware of each other — only the load balancer knows all servers; load balancer routes each request; servers can run different OSes; no shared storage required. Failure handling: cluster software redistributes work when a node fails; load balancer health checks detect failure and remove the server from the pool. Key exam distinction: clustering = nodes coordinate; load balancing = servers are independent and load balancer is the central coordinator.

A disaster recovery site that is a fully operational, always-current duplicate of the primary data center. All hardware installed and running; applications continuously updated to match primary; data continuously replicated in real time or near-real time. When a disaster occurs, failover is fast — operations redirect to the hot site quickly. RTO: hours or less. RPO: minutes or less. Cost: highest — you effectively run two data centers simultaneously; "you buy two of everything." Exam trigger phrases: "exact replica," "flip a switch," "real-time replication," "most expensive," "fastest recovery." Appropriate when downtime cost exceeds the cost of maintaining the duplicate infrastructure.

A disaster recovery facility that is an empty building with power and physical infrastructure only. No hardware, no software, no synchronized data, no on-site personnel. When a disaster is declared: equipment must be transported or purchased, OS and applications installed, data restored from off-site backups, and staff transported on-site. RTO: longest — days to weeks. RPO: highest data loss — limited by backup frequency. Cost: lowest — ongoing expense is just the facility lease and utilities. Appropriate for organizations with tight budgets and high tolerance for recovery time. Exam trigger phrases: "empty building," "no hardware," "bring everything," "cheapest," "longest recovery time."

A disaster recovery site between hot and cold: partially equipped and ready. Typically has rack space, some hardware, and basic network connectivity. What it lacks: current data (must be restored from backup), full software configuration, possibly some additional hardware. RTO: moderate — hours rather than days or weeks. RPO: moderate — limited by backup frequency. Cost: between hot and cold — some infrastructure maintained, but not full duplication. Most common practical choice: provides meaningful DR capability at a fraction of hot site cost. Exam trigger phrases: "middle ground," "some hardware," "bring software and data," "just enough to get going," "moderate cost and recovery time."

The requirement that recovery and backup sites be physically located far enough from the primary site that a single regional disaster cannot affect both simultaneously. A recovery site in the same city provides no protection against a hurricane, earthquake, or regional power failure that affects the entire metropolitan area — both sites go down together. Geographic dispersion means placing recovery in a different region or state. Challenges: equipment transport, staff relocation, maintaining geographically distant infrastructure, and eventually returning to primary. All must be planned in advance. Exam principle: "A recovery site down the street is not a recovery site if both are in the hurricane's path." Recovery sites in different states or regions are the standard recommendation.

Intentionally using multiple different operating systems, application frameworks, or hardware architectures across infrastructure, so a vulnerability specific to one platform cannot compromise everything simultaneously. Key principle: most security vulnerabilities are platform-specific — a critical Windows kernel vulnerability does not affect Linux or macOS. By running mixed platforms (e.g., Linux web servers + Windows database servers + macOS clients), a Windows zero-day has limited blast radius — Linux and macOS systems remain operational during the patching window. Tradeoff: managing multiple platforms requires cross-platform expertise, separate patch workflows, and more complex operations. Risk spread across platforms vs. operational simplicity of a single platform is the core tradeoff.

Distributing workloads and data across multiple cloud providers (AWS, Azure, GCP) rather than relying entirely on one. Benefits: (1) provider diversity — an outage or security incident specific to one provider does not affect the others; (2) geographic dispersion — different providers use different physical infrastructure; (3) reduced vendor lock-in — negotiating leverage, no single-provider dependency. Tradeoffs: significantly increased management complexity — different consoles, IAM models, APIs, billing, and security tooling; data synchronization between providers adds cost and latency; staff must be trained on multiple platforms. Most organizations use two providers to balance resilience benefit against operational overhead. Exam principle: distributes both geographic risk and provider-specific risk.

A framework ensuring essential functions continue when technology systems are completely unavailable. COOP replaces digital processes with manual alternatives for the duration of the outage: manual transaction forms with physical signatures (instead of POS systems), phone calls to card processors for voice approval (instead of automated payment networks), paper receipts (instead of electronic receipts), paper routing and physical signatures (instead of digital approval workflows). Critical requirements: (1) procedures must be documented in writing before a disaster occurs — not improvised during one; (2) physical copies of forms, procedures, and contact directories must be accessible when digital systems are down; (3) staff must be trained and procedures regularly tested. An untested COOP plan is likely to fail when needed.