Design Resilient Architectures practice questions

Answer: A) A copy action in the backup plan rule that copies recovery points to a backup vault in the DR Region; B) Cross-account backup that copies recovery points to a vault in a backup account in the same organization

AWS Backup plan rules can automatically copy recovery points to a vault in another Region and to a vault in another account in the same organization. Vault Lock, cold storage lifecycle rules, and restores don't create off-Region or off-account copies.

• AAWS Backup can copy backups to another Region automatically as part of a scheduled backup plan, which meets the geographic DR requirement.
• BAfter cross-account backup is enabled from the Organizations management account, and the destination vault's access policy allows backup:CopyIntoBackupVault, a backup plan can copy recovery points into another account's vault.
• CVault Lock makes recovery points immutable (WORM) and protects them from deletion. It doesn't copy them to another Region or account, so the only copy still sits in the production account and Region.
• DCold storage lowers storage cost but keeps backups in the same vault, Region, and account. AWS Backup also doesn't support cross-Region or cross-account copies for cold-tier storage.
• EAWS Backup doesn't support restoring a backup from one account directly into another. You must first copy the backup to the other account and then restore it there. This option also creates no DR copies ahead of time.

Answer: A) Create a CloudWatch alarm on the instances' StatusCheckFailed metric and a health check that monitors the alarm

Route 53 health checks can monitor endpoints, other health checks (calculated checks), or CloudWatch alarms. Because health checkers run outside the VPC, a health check based on a CloudWatch alarm is the way to monitor instances that have only private IP addresses.

• ARoute 53 health checkers are outside the VPC. AWS recommends a health check that monitors the data stream of a CloudWatch alarm, for example on StatusCheckFailed, for instances that have only private IP addresses.
• BEndpoint health checks are sent from Route 53 health checkers outside the VPC, so they cannot reach private IP addresses. An instance would need a public IP address for this to work.
• CA calculated health check only combines the status of its child health checks. The children here are endpoint checks on private IPs, which Route 53 health checkers cannot reach, so the result is still wrong.
• DHealth checkers send their requests over the internet from outside the VPC. Using a private domain name does not let them reach resources inside the VPC.

Answer: A) A scheduled scaling action on the Auto Scaling group that raises minimum capacity shortly before 12:00, alongside dynamic (target-tracking) scaling for the rest of the day

• AScheduled scaling pre-provisions capacity for a known event so instances are already warm when the spike hits; dynamic scaling then handles the unpredictable remainder.
• BReactive policies lag a sudden step change; the scenario already says that isn't fast enough.
• CThat wastes capacity for the other 23 hours.
• DManual daily intervention is error-prone; scheduled scaling automates exactly this.

Answer: A) Deploy one NAT gateway per Availability Zone and give each AZ's private subnets a route table that uses the NAT gateway in the same AZ

• AA per-AZ NAT gateway removes the cross-AZ single point of failure: if one AZ (or its NAT gateway) fails, the other AZs keep their outbound connectivity.
• BSize doesn't change the fact that one AZ's failure takes down internet egress for every AZ routed through it.
• CThat exposes all instances directly to the internet, defeating the private-subnet design.
• DPrivate subnets by definition have no route to an internet gateway; adding one makes them public.

Answer: A) Store uploads in Amazon S3 (or Amazon EFS for shared file semantics) instead of instance storage

• ADurable shared storage decouples data from any single instance so scale-in or replacement does not lose files.
• BThat trades away elasticity and still loses data on any instance failure.
• CInstance store is still ephemeral regardless of size.
• DInstance store is not EBS, and snapshots do not make active writes durable in real time.

Answer: A) Workers receive jobs from an Amazon SQS queue and delete each message only after the job has finished successfully

Workers should pull jobs from SQS and delete each message only after the job finishes. If a worker is terminated mid-job, the visibility timeout expires and the message reappears for another worker.

• AIf a worker is terminated before deleting the message, the message becomes visible again when the visibility timeout expires. Another worker can then process it, so the job is not lost.
• BOnce the message is deleted, the queue no longer has a copy. If the worker is interrupted mid-job, the job is lost.
• CSNS pushes the message and considers it delivered once the endpoint accepts it. If the worker then dies mid-job, nothing makes the job available to another worker.
• DMemory and instance store data are lost when the instance is terminated, so pending and in-progress jobs can't be recovered.

Answer: A) Configure the target group health check to request an application path such as /health that exercises the app

EC2 system and instance status checks cover host and OS health, not the application's responses. An ALB target group health check that probes an application path marks the hung instance unhealthy and stops routing to it.

• AThe ALB sends HTTP requests to the configured health check path. After UnhealthyThresholdCount consecutive failures, it takes the target out of service and routes only to healthy targets. Setting the Auto Scaling group's health check type to ELB would also get the instance replaced.
• BSystem status checks find problems with the underlying AWS host, such as power or network loss. They don't look at the application's responses, and in this scenario the check is passing.
• CThe instance status check tests OS-level reachability with an ARP request to the network interface, and it is passing here, so the alarm never fires. A recover action also doesn't remove a target from the load balancer.
• DWith the default settings, Auto Scaling uses the built-in EC2 status checks, which still pass when only the application has hung. Nothing tells the load balancer to stop sending traffic.

Answer: A) Amazon DynamoDB global tables with a replica table in each Region the application runs in; B) Amazon Route 53 latency-based records with health checks on each Region's endpoint

Active-active across Regions needs a data store that accepts writes in every Region (DynamoDB global tables) and DNS routing that sends users to a nearby healthy Region (Route 53 latency routing with health checks). Aurora Global Database has a single writer Region, and failover routing is active-passive.

• AGlobal tables are multi-Region and multi-active. Any replica can serve reads and writes, and data is replicated automatically, so each Region serves its users locally and traffic can shift away from a failed Region.
• BLatency routing sends users to the Region with the best latency. Health checks take a failed Region's endpoint out of DNS answers, so users are sent to the healthy Regions.
• CAurora Global Database has one primary Region where data is written and read-only secondary Regions. Write forwarding still sends writes to the primary, so this is not active-active for writes.
• DFailover routing is for active-passive setups. The secondary gets traffic only when the primary is unhealthy, so users are not served locally in every Region.
• ESimple routing returns the values in random order without considering latency, and the IP addresses are not health checked, so users can be sent to a failed Region.

Answer: A) Raise the target group's deregistration delay to a value longer than the slowest request, such as 120 seconds

During scale-in, the ALB drains a deregistering target for the deregistration delay before Auto Scaling can terminate the instance. If the delay (lowered here to 30 s) is shorter than the longest request (90 s), in-flight requests fail. Set the delay longer than the slowest request.

• ACorrect. A deregistering target enters the draining state. The ALB stops sending it new requests and waits for the deregistration delay before the instance can be terminated. With a 30-second delay, 90-second requests are cut off, and if a target closes connections before draining finishes, clients get 500-level errors. A delay longer than the slowest request lets those requests finish.
• BIncorrect. Stickiness only decides which target receives a client's later requests, and the ALB sends new requests away from draining targets anyway. It does not keep a deregistering instance alive long enough for in-flight requests to finish.
• CIncorrect. Slow start gives newly registered, healthy targets time to warm up before they receive a full share of requests. It has no effect on targets being deregistered during scale-in.
• DIncorrect. Detecting an unhealthy target sooner does not let requests already running on it finish. How long a deregistering target is allowed to drain is controlled by the deregistration delay, not by health checks.

Answer: A) Turn on Elastic Load Balancing health checks for the Auto Scaling group

An Auto Scaling group defaults to EC2 status checks, which only cover instance state and hardware/software impairment, and it ignores load balancer health results until ELB health checks are turned on. Turning them on lets the group replace instances whose application fails the load balancer check.

• ACorrect. By default, Auto Scaling uses only EC2 status checks and ignores load balancer health results. Once ELB health checks are turned on for the group, an instance the load balancer reports as unhealthy is marked unhealthy and replaced.
• BIncorrect. EBS health checks only confirm that the instance's EBS volumes are reachable and passing I/O status checks. A crashed application process with healthy volumes wouldn't fail them.
• CIncorrect. The grace period only delays when health checks begin after launch. It doesn't change which signals Auto Scaling uses, so load balancer results would still be ignored.
• DIncorrect. The target group already detects the failure. The problem is that the Auto Scaling group isn't using load balancer health results at all, so a better load balancer check alone won't trigger replacement.