Reliability and Business Continuity practice questions

Answer: A) Add a warm pool so pre-initialized instances wait in a Stopped, Hibernated, or Running state

A warm pool keeps pre-initialized instances in a Stopped, Hibernated, or Running state so the group can bring them into service quickly during scale-out. That avoids repeating the long initialization during a traffic spike.

• ACorrect. A warm pool is a pool of pre-initialized instances that sits alongside the group. On scale-out, the group draws from the pool (a warm start), so instances that already finished the long initialization go into service quickly. Stopped or Hibernated keeps costs low because you pay mainly for EBS volumes and attached Elastic IP addresses.
• BIncorrect. On its own, a launch lifecycle hook only holds a newly launched instance until custom actions finish. It makes sure instances aren't put in service before they're ready, but the full initialization still happens after the spike starts, so the delay stays the same. Hooks are often used with a warm pool, but they don't replace one.
• CIncorrect. The health check grace period only delays health checks so that instances still initializing aren't marked unhealthy and replaced. It doesn't make instances ready any sooner.
• DIncorrect. Scale-in protection only stops Auto Scaling from terminating protected instances during scale-in. It has no effect on how quickly new instances can serve traffic during scale-out.

Answer: A) Configure a slow start duration on the target group

Slow start mode increases traffic to a newly healthy target linearly over the configured duration, which gives the application time to warm up. Deregistration delay, the routing algorithm and health check thresholds don't ramp up traffic.

• ACorrect. With slow start on, a newly healthy target enters slow start mode, and the load balancer increases its share of requests linearly until the configured duration ends. Slow start works with round robin. It can't be used with the least outstanding requests or weighted random algorithms.
• BIncorrect. Deregistration delay controls how long the load balancer lets in-flight requests finish on a target that is being removed (draining). It has no effect on how much traffic a newly registered target receives.
• CIncorrect. This algorithm routes each request to the target with the fewest in-progress requests, so a new target can still get plenty of traffic right away. AWS also states that slow start mode can't be enabled with this algorithm.
• DIncorrect. A higher healthy threshold only means more consecutive successful checks are needed before a target is marked healthy. Once the target is healthy, it still receives its full share of requests at once.

Answer: A) Enable automatic backups with a multi-day retention limit, and restore a pre-corruption backup into a new cache when needed

Multi-AZ failover, replicas, and Global Datastore all copy the current data, so they copy any corruption as well. Only ElastiCache backups (snapshots) stored in S3 let you restore data from before the corruption into a new cache.

• ACorrect. ElastiCache automatic backups are created daily, stored durably in Amazon S3, and kept for a retention limit of up to 35 days. You can restore an earlier backup into a new cache to get back the data from before the corruption.
• BIncorrect. A Global Datastore copies writes to the secondary Region, so corrupted data would be copied there too. It gives Regional disaster recovery, not a way back to an earlier point in time.
• CIncorrect. Read replicas receive the same writes as the primary, so they would hold the same corrupted data. More replicas improve availability and read capacity but can't restore earlier data.
• DIncorrect. Data tiering moves less-used data from memory to SSD to lower cost. It holds the current, possibly corrupted data and doesn't keep earlier copies to restore from.

Answer: A) It updates the standby, promotes the standby to primary, and then updates the old primary, which becomes the new standby

For Multi-AZ DB instances, RDS applies OS updates by updating the standby, failing over to it, and then updating the old primary, so downtime is limited to roughly one failover. Engine version upgrades, by contrast, modify both instances at the same time.

• ACorrect. For Multi-AZ deployments, RDS applies OS updates in this order: maintenance on the standby, promotion of the standby to primary, then maintenance on the old primary, which becomes the new standby. The application is affected only during the short failover.
• BIncorrect. This is how RDS handles database engine version upgrades on a Multi-AZ instance: both instances are modified at once, which causes downtime. OS updates use the standby-first sequence and a failover.
• CIncorrect. In a Multi-AZ DB instance deployment, the standby doesn't serve read traffic. RDS also updates the standby first and then fails over, rather than patching the primary in place first.
• DIncorrect. RDS Blue/Green Deployments are an optional feature that you set up yourself to reduce downtime, for example for engine upgrades. RDS doesn't create one automatically to apply OS updates.

Answer: A) An S3 Batch Operations job that uses an S3 Inventory report as its manifest

S3 Batch Operations applies one operation, such as tagging, to millions or billions of existing objects. Amazon S3 tracks the job and can write a completion report with the result of each task.

• ACorrect. S3 Batch Operations runs one operation, such as setting object tags, across every object listed in a manifest. An S3 Inventory report can serve as that manifest. Amazon S3 tracks the job's progress, and you can configure a completion report that describes the result of each task.
• BIncorrect. S3 Lifecycle rules can move objects to other storage classes or expire them. They cannot add tags to objects, and they produce no report of per-object results.
• CIncorrect. A replication rule copies new objects to a destination bucket. It does not add new tags to objects already in the source bucket, and it produces no per-object completion report.
• DIncorrect. S3 Inventory only lists the objects and their metadata. It does not change any objects. Its report can serve as the input manifest for a Batch Operations job, but Inventory alone cannot apply tags.

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 administrator 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) Enable S3 Object Lock on the bucket and apply a 7-year default retention period in compliance mode

Only S3 Object Lock in compliance mode stops every user, including the root user, from deleting or overwriting object versions or shortening retention. Governance mode, MFA delete, and bucket policies can all be bypassed or changed by privileged users.

• ACorrect. In compliance mode, no user, including the root user, can overwrite or delete a protected object version. The retention mode can't be changed and the period can't be shortened. Object Lock requires S3 Versioning, which is enabled automatically on buckets that use it.
• BIncorrect. Governance mode protects objects from most users, but anyone with the s3:BypassGovernanceRetention permission can override or remove the retention settings by sending the bypass header. That doesn't meet a requirement that no user can remove the protection.
• CIncorrect. MFA delete only adds a second authentication factor for permanently deleting versions or changing the versioning state. The bucket owner (root user) can still delete versions with valid MFA, and there's no enforced retention period.
• DIncorrect. A bucket policy is a configuration that a principal with enough permissions, such as the root user, can change or delete and then remove the data. It doesn't give the provable, non-overridable retention the regulation requires.

Answer: A) Assign that replica promotion tier 0 and give the other replicas higher-numbered tiers

Aurora promotion tiers (0 highest to 15 lowest) set the order in which replicas are promoted during failover. If several replicas share a tier, Aurora promotes the largest one, and if they also match in size it picks one arbitrarily.

• ACorrect. Each Aurora Replica can be given a failover priority from 0 (highest) to 15 (lowest). If the writer fails, Aurora promotes the replica with the highest priority. You can change the priority at any time without triggering a failover.
• BIncorrect. Custom endpoints only control which instances receive client connections. They don't change which replica Aurora promotes during a failover.
• CIncorrect. RDS Proxy routes connections to whatever instance becomes the new writer, which shortens failover time. It doesn't decide which replica Aurora promotes.
• DIncorrect. Aurora Auto Scaling adds and removes replicas based on load. It has no setting that controls the order in which replicas are promoted.

Answer: A) AWS Fault Injection Service (AWS FIS) experiment templates with defined actions, targets and stop conditions

AWS Fault Injection Service (formerly Fault Injection Simulator) runs controlled fault injection experiments on real AWS resources, with CloudWatch alarm-based stop conditions as guardrails. Monitoring and advisory services observe or assess the application but don't create disruptions.

• ACorrect. AWS FIS runs chaos engineering experiments that carry out real actions on real AWS resources. An experiment template defines actions, targets and stop conditions. A stop condition is a CloudWatch alarm that stops the experiment if it is triggered.
• BIncorrect. Canaries watch availability and latency from the outside by running scripted requests. They observe the application but don't inject faults into its resources.
• CIncorrect. AWS Health reports real service events and scheduled changes. It can't create controlled disruptions to test how the application responds.
• DIncorrect. Trusted Advisor checks configuration against best practices, such as Multi-AZ setup or backups. It doesn't run live failure experiments.

Answer: A) An AWS Site-to-Site VPN connection to the same gateway, using BGP dynamic routing

A Site-to-Site VPN that uses BGP gives a low-cost backup path for a single Direct Connect connection. Traffic fails over to the VPN automatically, and Direct Connect stays the preferred path while it is up.

• ACorrect. AWS describes a Site-to-Site VPN as a cost-effective backup to a primary Direct Connect connection. With BGP, traffic fails over to the VPN automatically if Direct Connect goes down. While the Direct Connect path is up, AWS always prefers it.
• BIncorrect. A second virtual interface runs over the same physical connection. If that connection fails, both virtual interfaces fail with it, so this adds no independent path.
• CIncorrect. BFD helps BGP detect a link failure faster. It does not create a second path, so traffic still has nowhere to go when the only connection fails.
• DIncorrect. Route propagation adds learned routes to VPC route tables, but it does not create any new connection. With only one Direct Connect link, there is still no alternate path.