2.2 - Resilient databases and data

AWS Solutions Architect Associate objective 2.2 covers making data and databases resilient. Enabling a Multi-AZ deployment gives an Amazon RDS database automatic synchronous failover to a standby replica in another Availability Zone, improving availability rather than read scaling (read replicas do the latter). In an Amazon Aurora cluster with one writer and several readers across AZs, if the writer fails Aurora automatically promotes a reader based on the configured failover priority, usually within seconds. To automate creating, cross-Region copying and retention of EBS snapshots, Amazon Data Lifecycle Manager (DLM) policies handle it without custom scripts. You should also know backups, point-in-time recovery and cross-Region replication. Expect scenario questions that describe automatic database failover, Aurora recovery behaviour, or automated snapshot management, and ask which resilient data feature - RDS Multi-AZ, Aurora failover or DLM - applies.

Memory hook
Automatic synchronous DB failover to another AZ = RDS Multi-AZ (read replicas = scaling, not HA). Aurora promotes a reader by failover priority. Automate EBS snapshot create/copy/retention = Data Lifecycle Manager (DLM).

Practice questions

1. Which feature gives an Amazon RDS database automatic synchronous failover to a standby in another AZ?

  • Multi-AZ deployment (correct answer)
  • Read replicas
  • Automated snapshots
  • Reserved instances

RDS Multi-AZ keeps a synchronous standby in a second AZ and fails over automatically via DNS on failure. Read replicas scale reads (asynchronous) but are not automatic failover.

2. A stateful app stores session data in memory on each EC2 instance, so scaling in loses user sessions. What is the best fix?

  • Enable termination protection on all instances
  • Store session state in Amazon ElastiCache or DynamoDB (correct answer)
  • Increase the instance size to hold more sessions
  • Disable Auto Scaling to keep instances running

Externalizing session state to ElastiCache or DynamoDB makes instances stateless, so any instance can serve any user and scaling in/out is safe.

3. Which storage option gives shared, elastic file storage that many Linux EC2 instances across AZs can mount at once?

  • Amazon EBS gp3 volume
  • Instance store
  • Amazon EFS (correct answer)
  • Amazon S3 Glacier

Amazon EFS is a managed NFS file system, mountable concurrently by many instances across AZs and elastic in size. EBS attaches to one instance (in one AZ) at a time.

4. A company needs an RPO of a few seconds for a critical S3 dataset, protected against the loss of an entire Region. What should they enable?

  • S3 Versioning only
  • S3 Lifecycle transitions to Glacier
  • EBS snapshots copied nightly
  • S3 Cross-Region Replication (correct answer)

S3 Cross-Region Replication asynchronously copies new objects to a bucket in another Region within seconds to minutes, protecting against a Region-level loss. Versioning is a prerequisite but not sufficient alone.

5. A globally distributed app needs a relational database with sub-second cross-Region replication and fast Region-level failover for reads. Which option fits?

  • RDS single-AZ with manual snapshots
  • One Aurora cluster in a single Region
  • Cross-Region read replica added ad hoc
  • Amazon Aurora Global Database (correct answer)

Aurora Global Database replicates to secondary Regions with typically sub-second lag and supports fast cross-Region failover (often under a minute) plus local low-latency reads. A single-Region cluster has no cross-Region resilience.

6. An Amazon Aurora cluster has one writer and three readers across AZs. How is failover behavior controlled when the writer fails?

  • Aurora always promotes the oldest reader regardless of any configuration
  • Aurora promotes a reader based on the failover priority tier assigned to each replica (correct answer)
  • Failover requires manually restoring the cluster from the latest snapshot
  • A new writer must be launched by an administrator before reads can resume

Aurora replicas have failover priority tiers (0-15); on writer failure Aurora automatically promotes the reader in the lowest-numbered tier (largest size breaks ties), typically within about 30 seconds.

Related objectives