Task 2.3: Implement backup and restore strategies.

• AAmazon Data Lifecycle Manager policies that target resources with the backup=daily tag

  Incorrect

  Data Lifecycle Manager automates EBS snapshots and EBS-backed AMIs. It does not back up RDS DB instances or DynamoDB tables.

• BAn AWS Backup plan with a cross-Region copy rule and resources selected by tag

  Correct

  A backup plan schedules and retains backups across services, can copy them to another Region automatically, and can select resources by tag.

• CRDS automated backups and DynamoDB point-in-time recovery, each set to 35 days

  Incorrect

  These are separate, service-by-service settings. They leave out EC2 and EBS and do not give one central policy.

• DA scheduled AWS Lambda function that calls each service's backup API and copies the results

  Incorrect

  Custom code is exactly what the team wants to avoid. AWS Backup exists to replace per-service scripts with central policies.

One schedule, one retention, one cross-Region copy rule, selected by tag across several services: that is an AWS Backup plan.

• ARestore the 03:00 automated snapshot onto the existing DB instance

  Incorrect

  A snapshot cannot be restored onto an existing DB instance; it creates a new one. Restoring it would also lose everything written since 03:00.

• BPromote the read replica to a standalone DB instance

  Incorrect

  RDS replays every change from the primary on the read replica, so the dropped table is gone there as well.

• CUse point-in-time restore to 14:04 and repoint the application

  Correct

  Point-in-time restore creates a new DB instance at any time within the backup retention period, using backups and transaction logs.

• DReboot the DB instance with failover to switch to the standby

  Incorrect

  The standby is a synchronous copy of the primary, so it holds the same dropped table.

Replicas and standbys copy mistakes as faithfully as data. Recovering from a logical error means going back in time, and point-in-time restore gets closest to the moment before it.

• AS3 Object Lock in compliance mode with a 30-day retention period

  Incorrect

  Compliance mode stops every user, including the root user, from deleting a protected version until retention ends. That is immutability, not recovery with automatic cleanup.

• BAn S3 Lifecycle rule that moves objects to S3 Glacier Flexible Retrieval after 30 days

  Incorrect

  A transition changes the storage class of objects. Without versioning, an overwritten or deleted object still cannot be brought back.

• CS3 server access logging to a separate bucket, so that every deletion is recorded

  Incorrect

  Access logs record the requests made to a bucket. They show who deleted an object but cannot restore it.

• DS3 Versioning, plus a Lifecycle rule that expires noncurrent versions after 30 days

  Correct

  Versioning keeps every version and turns a delete into a delete marker, so earlier versions can be restored; the Lifecycle rule permanently deletes noncurrent versions after the chosen time.

Versioning gives the undo button, and a noncurrent-version expiration rule keeps the history from growing forever.

• AWarm standby, with a scaled-down but working copy running in the recovery Region

  Correct

  Warm standby keeps everything deployed and running at reduced size, so it can handle traffic immediately and only needs to scale up.

• BPilot light, with data replicated and the application servers switched off until a failover

  Incorrect

  A pilot light cannot process requests until servers are turned on and possibly more infrastructure is deployed, so it cannot serve immediately.

• CBackup and restore, with backups copied to the recovery Region on a schedule

  Incorrect

  With backup and restore, the infrastructure must be deployed and the data restored from backups before any request can be served.

• DMulti-site active/active, with the full workload serving users in both Regions

  Incorrect

  Active/active is the most complex and costly strategy. It goes beyond what the runbook asks for.

"Serve immediately, at reduced capacity, then scale up" is the definition AWS gives for warm standby, and it costs less than running both Regions at full size.

• AShadow copies on the file system, taken on a regular schedule

  Correct

  With shadow copies enabled, users can restore previous versions of files and folders themselves with Restore previous versions in File Explorer.

• BA longer retention period for the file system's automatic daily backups

  Incorrect

  Each FSx backup is restored by creating a new file system, so an administrator would still do the work, and only once a day's versions would exist.

• CAn AWS Backup plan that backs up the file system every hour

  Incorrect

  Restoring through AWS Backup also creates a new file system from the recovery point, which users cannot do from File Explorer.

• DA Multi-AZ deployment of the file system with a standby file server

  Incorrect

  Multi-AZ replicates data synchronously and fails over to the standby for availability. A bad edit is replicated too.

Backups protect the whole file system and are restored by an administrator; shadow copies keep earlier versions inside the file system for users to restore themselves.