Reliability and Business Continuity practice questions

Answer: A) Enable S3 Versioning on the bucket; B) Attach the AWSBackupServiceRolePolicyForS3Backup managed policy (and the S3 restore policy for restores) to the role used by the backup plan

AWS Backup for S3 needs S3 Versioning on the bucket and an IAM role with the S3 backup (and restore) permissions from the AWSBackupServiceRolePolicyForS3Backup/Restore managed policies.

• ACorrect. AWS Backup requires S3 Versioning on the buckets it protects. Versioning is off by default on a new bucket.
• BCorrect. The S3 backup permissions are in separate managed policies. A role built only for EC2 and EBS backups lacks them, so the backup job is denied.
• CIncorrect. Transfer Acceleration speeds up uploads from distant clients over CloudFront edge locations. AWS Backup doesn't need it.
• DIncorrect. Object Lock protects objects from deletion, but it isn't required for AWS Backup. To make backups immutable, you would use AWS Backup Vault Lock.
• EIncorrect. S3 buckets aren't in a VPC, and AWS Backup reaches S3 directly. A gateway endpoint doesn't affect backup jobs.

Answer: A) Turn on cross-account backup in the AWS Backup settings of the organization's management account; B) Add an access policy to the destination vault in the backup account that allows backup:CopyIntoBackupVault from the production account

Cross-account AWS Backup copy needs the organization-level cross-account setting in the management account and a destination vault access policy that allows the source account to copy in. Encrypted resources must use a customer managed key.

• ACorrect. Cross-account copy is controlled at the organization level. It must be enabled from the management account before member accounts can copy backups to each other.
• BCorrect. The destination vault must allow the source account to copy recovery points into it. Without this vault access policy, the copy job is denied.
• CIncorrect. Backup vaults aren't shared through AWS RAM. Copies are allowed by the organization setting and the destination vault's access policy.
• DIncorrect. AWS Backup copies recovery points through the service itself. No network connection between the accounts' VPCs is involved.
• EIncorrect. It works the other way: resources encrypted with an AWS managed key can't be copied to another account. A customer managed key, with its key policy allowing the destination account, is what cross-account copy needs.

Answer: A) Create a predictive scaling policy in forecast only mode and review the forecast data in the console or with GetPredictiveScalingForecast

Forecast only mode generates predictive scaling forecasts without taking any scaling actions, so administrators can evaluate accuracy before switching to forecast and scale mode.

• ACorrect. In forecast only mode, predictive scaling generates capacity forecasts but doesn't scale the group. The engineer can compare forecasts with actual load before switching to forecast and scale mode.
• BIncorrect. A zero scheduling buffer only means instances aren't launched ahead of time. In forecast and scale mode, the group still scales out at the start of each hour based on the forecast.
• CIncorrect. Honoring the maximum capacity only stops the policy from scaling above the group's maximum. It still adds instances up to that limit based on the forecast.
• DIncorrect. Target tracking is reactive dynamic scaling. It produces no predictive forecast, and it still changes capacity when it scales out.

Answer: A) Sign in as the bucket owner's root user and enable MFA Delete in the bucket's versioning configuration by using the AWS CLI or S3 API

MFA Delete makes each request that permanently deletes an object version or changes the versioning state include a code from a hardware or virtual MFA device. Only the bucket owner (root user) can enable it, using the AWS CLI or API.

• ACorrect. MFA Delete requires the request's security credentials plus the MFA device's serial number (or ARN for a virtual device) and its current code. It applies both to permanently deleting a version and to changing the versioning state. Only the bucket owner (root user) can enable it, and only through the AWS CLI or the API.
• BIncorrect. You can't enable MFA Delete in the AWS Management Console; you must use the AWS CLI or the API. Also, only the bucket owner (root user) can enable it, not an IAM administrator.
• CIncorrect. Governance-mode Object Lock protects object versions from deletion during the retention period. It doesn't make each delete or versioning-change request carry an MFA code, and users with the bypass permission can still remove the protection.
• DIncorrect. MFA at console sign-in doesn't make S3 demand an MFA code in each request that deletes a version or changes the versioning state. That per-request requirement comes from MFA Delete in the bucket's versioning configuration.

Answer: A) AWS Elastic Disaster Recovery with the replication agent installed on each source server

AWS Elastic Disaster Recovery continuously replicates servers at the block level into a low-cost staging area. This gives near-zero RPO, recovery within minutes, non-disruptive drills, and failback. Application Migration Service targets migrations, and periodic backups cannot achieve near-zero data loss.

• ACorrect. Elastic Disaster Recovery replicates source servers at the block level into a low-cost staging area subnet, keeping RPO near zero. It launches recovery instances within minutes, supports non-disruptive drills, and supports failback to the primary site.
• BIncorrect. Application Migration Service uses similar block-level replication, but it is built for one-time lift-and-shift migrations (test and cutover). It is not built for ongoing DR readiness with recovery drills and failback. Elastic Disaster Recovery is the AWS service for that.
• CIncorrect. A daily AWS Backup plan creates periodic recovery points, so up to a day of data could be lost. It does not continuously replicate block-level changes to give near-zero RPO.
• DIncorrect. Volume Gateway snapshots are point-in-time copies of the gateway's volumes taken on a schedule. They do not continuously replicate whole servers or automatically convert them to boot as EC2 instances.

Answer: A) Create a CloudWatch alarm on the StatusCheckFailed_System metric for the instance, with the EC2 recover action

Host problems cause the system status check to fail. CloudWatch action based recovery (an alarm on StatusCheckFailed_System with the recover action) moves the instance to new hardware and keeps its ID and IP addresses. It is required here because simplified automatic recovery does not support instances with instance store volumes attached at launch.

• ACorrect. CloudWatch action based recovery uses an alarm on StatusCheckFailed_System with a recover action. It is supported for C3 instances that have instance store volumes attached at launch. The recovered instance keeps its instance ID, public, private and Elastic IP addresses, and attached EBS volumes. Data in RAM and on instance store volumes is lost.
• BSimplified automatic recovery is not supported for instances that attach instance store volumes at launch, so this instance would not be protected by the default mechanism.
• CThe instance status check reflects problems inside the instance, such as OS or configuration issues. Automatic instance recovery does not run if only the instance status check fails. A host problem shows up in the system status check.
• DA reboot does not move the instance off the faulty host. Only the recover action (or a manual stop and start) migrates the instance to different hardware.

Answer: B) To any second within the retention period, up to the latest restorable time, which is typically within the last 5 minutes

RDS point-in-time restore works to any second in the retention period, up to the LatestRestorableTime, which is typically within 5 minutes because transaction logs are uploaded every 5 minutes.

• AIncorrect. RDS also uploads transaction logs to Amazon S3, so restores aren't limited to the daily snapshot. They can go to any second up to the latest restorable time.
• BCorrect. RDS combines the automated snapshot with transaction logs that it uploads every 5 minutes. The DB instance's LatestRestorableTime is therefore typically within the last 5 minutes.
• CIncorrect. Transaction logs are uploaded periodically, not synchronously, so the newest few minutes may not yet be restorable.
• DIncorrect. There's no 24-hour delay. Point-in-time restore works up to the latest restorable time, usually a few minutes ago.

Answer: A) Apply AWS Backup Vault Lock in compliance mode and let the grace time expire

Only AWS Backup Vault Lock in compliance mode, after its grace time expires, makes the vault immutable against every user, including the root user. Governance mode and access policies can be removed by privileged users.

• ACorrect. Once the compliance-mode grace time (at least 3 days) has expired, the vault and its lock are immutable and can't be changed or deleted by any user or by AWS. Recovery points can't be deleted until their lifecycle completes. During the grace time, the lock can still be removed or changed.
• BIncorrect. Governance mode lets users with sufficient IAM permissions manage or remove the lock. A compromised administrator with full IAM permissions could remove the lock and then delete recovery points.
• CIncorrect. A vault access policy is an extra layer of control, but a privileged user can edit or remove it. It doesn't make the protection immutable the way a compliance-mode Vault Lock does.
• DIncorrect. A second unlocked vault in the same account is controlled by the same administrators, so a compromised administrator account could delete the copies too. Copying adds redundancy, not immutability.

Answer: A) Update the Auto Scaling group to set MaxInstanceLifetime to 2592000 seconds

Maximum instance lifetime is a built-in Auto Scaling group setting. It replaces any instance that has been in service longer than the configured number of seconds, whether or not the instance is healthy.

• ACorrect. Maximum instance lifetime is the longest time, in seconds, that an instance can be in service before Auto Scaling terminates and replaces it. It applies to all current and future instances in the group, whether or not they are healthy. 2592000 seconds is 30 days.
• BIncorrect. ELB health checks replace an instance only after the load balancer reports it as unhealthy. They never replace a healthy instance because of its age, and the grace period only delays the first health check after launch.
• CIncorrect. An instance refresh is a one-time operation that replaces the instances in the group when it is started. It does not keep enforcing a 30-day limit unless someone runs it again on a schedule, which the requirement rules out.
• DIncorrect. Dropping capacity to zero takes down every instance at the same time and causes an outage. It also doesn't track each instance's own time in service, so instances launched between the scheduled actions could still be in service when the 30-day limit is reached.

Answer: A) Create EBS snapshots of the volume on a regular schedule, for example with Amazon Data Lifecycle Manager

EBS snapshots are durable point-in-time backups stored in S3 that can be used to create a new volume with the data as it was when the snapshot was taken. Multi-Attach, RAID 1 mirroring, and instance store copies don't keep a durable earlier version of the data.

• ACorrect. An EBS snapshot is an incremental point-in-time copy of a volume, stored in Amazon S3 and replicated across the Availability Zones in the Region. A new volume created from a snapshot starts as an exact copy of the source volume at the moment the snapshot was taken.
• BIncorrect. Multi-Attach lets several instances in the same Availability Zone share one io1 or io2 volume. There is still only one copy of the data, so corruption or loss of the volume affects every attached instance, and there is no earlier version to go back to.
• CIncorrect. RAID 1 copies every write to both volumes as it happens, so corrupted data lands on the mirror too. It protects against losing one disk but doesn't keep any earlier copy of the data.
• DIncorrect. Instance store is temporary block storage that is tied to the instance. Its data is lost when the instance stops, terminates, or its host fails, so it isn't a durable backup that can be used to rebuild an EBS volume.