AWS SysOps Reliability and Business Continuity: 80 practice questions

12 of the 80 Reliability and Business Continuity questions in the Certsqill AWS SysOps bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AWS SysOps? Take the free 5-min readiness check →

1. Target tracking scaling policy with a target value of 50%: Which scaling policy type is most appropriate?

1. Target tracking scaling policy with a target value of 50% for the average CPUUtilization metric, which automatically creates and manages both the scale-out and scale-in CloudWatch alarms. ✓

   Target tracking policies maintain a metric at a specified target value. Auto Scaling automatically creates and manages the underlying CloudWatch alarms and adjusts instance count to keep average CPU near 50%. No separate scale-in/scale-out alarm configuration is needed.
2. Scheduled scaling that uses a recurring cron expression to set a fixed desired capacity derived from historical CPU patterns, adjusting the instance count on a predetermined daily timetable.

   Scheduled scaling applies fixed capacity at set times and cannot react to real-time CPU utilization, so it will not converge on a 50% average. Target tracking adapts continuously to the metric.
3. Simple scaling policy tied to a single CloudWatch alarm at 50% CPU that adds one instance whenever the threshold is breached and then waits out a cooldown period before evaluating again.

   Simple scaling reacts to one threshold with a cooldown and needs separate policies to scale in; it does not continuously drive average utilization toward a target. Target tracking handles both directions automatically.
4. Step scaling policy with manually defined steps at 40% and 60% CPU that adds instances above 60% and removes instances below 40%, using separate scale-out and scale-in step adjustments.

   Step scaling requires hand-defining steps and separate scale-in and scale-out policies. Target tracking reaches the same outcome automatically from a single target value of 50%.

Target tracking with CPUUtilization target=50% automatically creates both scale-out and scale-in CloudWatch alarms and converges fleet CPU to the target.

2. Configure a lifecycle hook on the autoscaling: What Auto Scaling feature prevents premature traffic routing?

1. Increase the Auto Scaling health check grace period to 600 seconds so the group waits ten minutes after launch before the load balancer routes any traffic to the new instance.

   The grace period only delays Auto Scaling from terminating a new instance during startup; it does not hold the instance out of the load balancer target group. A launching lifecycle hook provides that pause.
2. Configure a lifecycle hook on the autoscaling:EC2_INSTANCE_LAUNCHING transition that keeps the instance in a 'Pending:Wait' state until the configuration script sends a CONTINUE signal. ✓

   Lifecycle hooks pause instance transition during launch (Pending:Wait) or termination (Terminating:Wait). During the wait, the instance is not added to the load balancer target group. Once the configuration script calls CompleteLifecycleAction with CONTINUE, the instance transitions to InService and joins the target group.
3. Configure the Application Load Balancer target group with a slow start duration of 600 seconds so incoming traffic is withheld from each new target until its ten-minute configuration completes.

   ALB slow start only ramps traffic up gradually; requests still begin flowing to the target immediately at a reduced rate. It cannot block all traffic until configuration finishes, unlike a lifecycle hook.
4. Add a 'sleep 600' command to the EC2 instance user data script so the instance defers starting its application for ten minutes, preventing registration with the load balancer until configuration ends.

   User data runs at boot but does not pause Auto Scaling's registration of the instance with the target group; the instance still goes InService once health checks pass. A launching lifecycle hook is required.

Lifecycle hooks on EC2_INSTANCE_LAUNCHING keep the instance in Pending:Wait state — preventing load balancer registration — until the configuration script signals CONTINUE.

3. RDS Read Replicas: Which RDS feature addresses this specific problem?

1. RDS Multi-AZ DB Cluster deployment used purely for high availability, which leaves read throughput unchanged because every client connection is still served exclusively by the single writer instance.

   Even though a Multi-AZ DB Cluster does offer readable standbys, this option treats it as HA-only with a single serving node. The standard, simplest way to distribute read connections for RDS MySQL is Read Replicas.
2. Increase the RDS instance class to a larger size so the single primary has more vCPUs and memory to accept a greater number of simultaneous read connections during the peak hours.

   Scaling up raises the capacity of one instance but does not distribute reads horizontally, and a larger instance still has connection limits. Read Replicas add separate read endpoints to spread the load.
3. RDS Read Replicas, which add one or more asynchronously replicated read endpoints that the application can direct read queries to, distributing the concurrent read load across multiple instances. ✓

   Read Replicas create one or more asynchronously replicated copies of the primary that serve read traffic. Applications must be modified (or use a proxy) to route read queries to replica endpoints. Multiple replicas can be created to scale reads horizontally.
4. RDS Multi-AZ deployment, whose synchronous standby replica serves read traffic during normal operation while also providing automatic failover if the primary Availability Zone becomes unavailable.

   A standard Multi-AZ standby is synchronous and used only for failover; it never serves read traffic. Multi-AZ addresses availability, not read scaling, so Read Replicas are required here.

RDS Read Replicas create additional read endpoints for distributing read load; Multi-AZ standby instances do NOT serve read traffic.

4. Enable an Auto Scaling warm pool: What feature reduces the time-to-ready for new instances without maintaining

1. Enable EC2 hibernation on the group's instances so each one can persist its RAM to EBS and resume from memory far faster than a cold boot when the Auto Scaling group needs to scale out.

   Hibernation speeds resume for individually stopped instances but is not the Auto Scaling scale-out mechanism and is not supported on all instance types or AMIs. A warm pool is the feature built for pre-initialized scale-out capacity.
2. Enable Predictive Scaling so the group forecasts demand from historical patterns and provisions capacity ahead of anticipated traffic spikes, removing the effect of the five-minute per-instance launch lag.

   Predictive Scaling starts scaling earlier but still launches fresh instances that incur the full boot and configuration time. Reducing that per-instance launch latency is exactly what a warm pool does.
3. Switch the launch template to a smaller instance type with a quicker boot sequence so that the combined AMI boot and user data configuration time drops well below the current five-minute lag.

   A smaller instance does little to shorten the user data configuration step that dominates the lag. A warm pool skips the boot and configuration entirely by keeping instances pre-initialized.
4. Enable an Auto Scaling warm pool, which keeps pre-initialized instances in a stopped state ready to be started on demand during scale-out, bypassing most of the boot and configuration time. ✓

   A warm pool holds pre-initialized instances in a stopped (or running) state. When the Auto Scaling group needs to scale out, it starts instances from the warm pool instead of launching fresh ones, reducing the scale-out latency from 5 minutes to ~30 seconds (start time for stopped instances).

Auto Scaling warm pools hold pre-initialized stopped instances that can launch in ~30 seconds instead of 5 minutes, enabling fast scale-out without permanent over-provisioning.

5. The company can restore to any point in time within: What is the most granular recovery point available?

1. The company can restore to any point in time within the past 7 days up to 5 minutes before the current time, using RDS Point-In-Time Recovery (PITR), which replays transaction logs over the 2:00 AM backup. ✓

   RDS automated backups include full daily snapshots AND continuous transaction log backups. PITR restores a fresh DB instance by replaying transaction logs over the nearest backup, allowing recovery to any specific second within the retention window (up to 5 minutes before the current time).
2. The company can only restore to the 2:00 AM automated snapshot and will lose the thirteen hours of data written between 2:00 AM and the 3:00 PM corruption, since daily snapshots are the finest recovery point.

   RDS automated backups include continuous transaction log archival, not just the daily snapshot, so PITR can recover to nearly any second before the corruption. Snapshot-only recovery is not the finest available point.
3. The company can restore to roughly 2:00 PM, one hour before the corruption, because RDS ships transaction logs to S3 in hourly batches and the most recent recoverable point is the last completed batch.

   RDS streams transaction logs continuously rather than in hourly batches, so PITR granularity is about five minutes, not one hour. Recovery can land just before the 3:00 PM corruption.
4. The company must launch a new RDS instance from the 2:00 AM snapshot and then manually replay application-level logs to reconstruct the data written between 2:00 AM and the 3:00 PM corruption event.

   Manual application-log replay is unnecessary because PITR automatically replays the archived transaction logs over the nearest backup to reach the chosen timestamp without any manual reconstruction.

RDS PITR uses continuous transaction log backups to restore to any second within the retention window — not limited to daily snapshot timestamps.

6. Enable Predictive Scaling in ForecastOnly mode first: Which Auto Scaling feature addresses this requirement?

1. Configure a scheduled scaling action that adds a fixed number of instances every Monday morning at a preset time, with the size of the increase derived from the historical weekly traffic pattern the group has recorded over the last 60 days.

   Scheduled scaling with a fixed time is brittle: if the spike shifts earlier or later it over- or under-provisions. Predictive Scaling continuously relearns from new data and adapts the forecast timing.
2. Enable Predictive Scaling in ForecastOnly mode first to evaluate forecast accuracy against the 60 days of history, then switch to ForecastAndScale mode so Auto Scaling proactively adds capacity ahead of the Monday spike. ✓

   Predictive Scaling analyzes historical traffic patterns and forecasts future capacity needs. ForecastOnly mode evaluates accuracy without actually scaling. Once validated, ForecastAndScale mode proactively adjusts capacity based on the forecast, adding instances before predicted spikes.
3. Enable target tracking scaling with a fifteen-minute cooldown period so the group starts adding instances just before the CPU threshold is actually breached, giving lead time ahead of the Monday morning spike.

   Target tracking is reactive and only responds after a metric breach, and a cooldown merely paces scaling actions rather than anticipating them. Predictive Scaling is the proactive, forecast-driven approach.
4. Use AWS Forecast to build a custom demand-prediction model from the historical data and feed its output to the Auto Scaling group through a Lambda function that sets desired capacity before each spike.

   AWS Forecast is a standalone service that would require significant custom Lambda integration to drive Auto Scaling. Predictive Scaling natively integrates forecasting into the Auto Scaling group with no custom code.

Predictive Scaling forecasts future capacity needs from historical patterns; use ForecastOnly mode to validate, then ForecastAndScale to proactively add capacity.

7. Both the source and destination buckets must have: What are the prerequisites for enabling Cross-Region Replic

1. Both buckets must reside in the same AWS account, because cross-account replication is not supported by S3 CRR and would instead require a separate Snowball Edge transfer between the two accounts.

   S3 CRR supports both same-account and cross-account replication; cross-account simply requires the destination account ID and appropriate IAM permissions. Snowball Edge is unrelated to CRR.
2. When the replication rule is first configured, S3 CRR automatically copies every object that already exists in the source bucket to the destination bucket in addition to all newly written objects.

   CRR only replicates new objects written after the rule is created; existing objects are not copied automatically. Replicating pre-existing objects requires a separate S3 Batch Replication job.
3. Both the source and destination buckets must have versioning enabled, and an IAM role must be provided that grants S3 permission to read source objects and replicate them to the destination bucket. ✓

   S3 CRR prerequisites: (1) versioning must be enabled on both source and destination buckets; (2) an IAM role with s3:GetObject on source and s3:ReplicateObject on destination must be specified in the replication configuration.
4. Only the source bucket needs versioning enabled, and the destination bucket automatically receives and stores versioned copies of each replicated object without any versioning configuration of its own.

   Both the source and the destination buckets must have versioning enabled before CRR can be configured; versioning on the destination is a hard prerequisite, not something applied automatically.

S3 CRR requires versioning on BOTH source and destination buckets plus an IAM role; existing objects are NOT auto-replicated — use S3 Batch Replication for those.

8. Network Load Balancer: Which load balancer type should be used?

1. Classic Load Balancer running in TCP passthrough mode, which delivers Layer 4 load balancing for non-HTTP traffic and preserves the client source IP address for the gaming backend connections.

   Classic Load Balancer is the legacy option not recommended for new architectures and lacks the performance profile of NLB. Network Load Balancer is the modern Layer 4 choice for TCP with source IP preservation.
2. Gateway Load Balancer (GWLB), which provides transparent Layer 4 pass-through with client source IP preservation across all protocols and is specifically optimized for the ultra-low latency the gaming workload demands.

   GWLB is purpose-built to insert third-party appliances such as firewalls and IDS/IPS into the traffic path using GENEVE; it is not a general-purpose application load balancer and does not fit this use case.
3. Application Load Balancer (ALB), which delivers the best real-time performance through advanced request routing algorithms and preserves the client source IP directly on each backend TCP connection.

   ALB operates at Layer 7 for HTTP/HTTPS, adds request-processing overhead, cannot handle arbitrary TCP, and exposes the client IP only via X-Forwarded-For headers. NLB is correct for Layer 4 TCP.
4. Network Load Balancer (NLB), which operates at Layer 4, handles TCP connections with ultra-low latency, and preserves the original client source IP address through its client IP preservation feature. ✓

   NLB operates at Layer 4 (TCP/UDP/TLS), provides the lowest latency of AWS load balancers, and can preserve the original client IP address for TCP connections (configurable per target group). It handles millions of requests per second with consistent performance.

NLB operates at Layer 4, provides ultra-low latency for TCP, and supports client IP preservation — the correct choice for non-HTTP, latency-sensitive applications.

9. The application's database connection pool is caching: What is the most likely cause of the delay?

1. The application's database connection pool is caching the old primary's IP address. When RDS updates the DNS record after failover, clients with cached DNS entries continue connecting to the old primary until the TTL expires (typically 60-120 seconds) or the pool refreshes. ✓

   RDS Multi-AZ failover updates the DNS CNAME record to point to the new primary (formerly the standby). Applications that cache DNS lookups at the connection pool or OS level continue attempting to connect to the old primary IP until the DNS TTL expires and new lookups succeed.
2. AWS Route 53 must propagate the updated RDS endpoint record across its global network of name servers after the failover, and that two-to-three-minute propagation delay is what produces the connection errors until the record finally resolves to the newly promoted primary in every region.

   RDS manages its own endpoint DNS and updates the record quickly; the delay comes from client-side DNS caching of the old TTL, not from global propagation time.
3. The standby replica requires additional initialization time after it is promoted to primary before it can accept and serve the application's active database connections, and that post-promotion warm-up window is exactly what the clients experience as the two-to-three-minute error period.

   The Multi-AZ standby is continuously synchronized and is ready to serve as primary immediately upon promotion, so no post-promotion initialization occurs. The delay is caused by cached DNS entries on the clients.
4. The RDS Multi-AZ failover process itself takes a full two to three minutes to complete, and the application's connection errors occur throughout that window while the standby is still being promoted and the endpoint switched to the new primary.

   RDS Multi-AZ failover typically completes in 60-120 seconds, and the question states the errors happen after failover has already completed. The residual delay is cached DNS pointing at the old primary.

RDS failover updates the DNS endpoint quickly, but client DNS cache TTL (60-120 seconds) causes applications to retry old primary IP until the cache expires.

10. Poll the EC2 instance metadata service: How should the application handle Spot Instance interruption notices t

1. Use an Amazon SQS visibility timeout so job messages are hidden but not deleted until each job finishes, letting an interrupted job's message reappear and be retried automatically on any other available Spot Instance.

   SQS visibility timeout enables retry of the whole job but does not preserve in-progress work, so an interrupted job restarts from the beginning. Checkpointing state on the two-minute notice is what minimizes lost work.
2. Poll the EC2 instance metadata service for the spot/termination-time endpoint. When a 2-minute notice is detected, checkpoint job state to S3 and gracefully shut down so the job can resume from the checkpoint on a new instance. ✓

   AWS provides a 2-minute interruption notice via the instance metadata endpoint (http://169.254.169.254/latest/meta-data/spot/termination-time). Applications can poll this endpoint and, upon receiving a notice, save their state to S3/EFS before termination, enabling a replacement instance to resume from the checkpoint.
3. Enable EC2 Hibernate so the Spot Instance automatically saves its RAM state to EBS when AWS reclaims it, allowing the batch job to resume from exactly where it stopped on the very same instance later.

   AWS Spot reclamation terminates the instance and does not trigger hibernation, so RAM state is not saved on interruption. The application must instead detect the notice and checkpoint its state externally.
4. Turn on Capacity Rebalancing for the Auto Scaling group so it proactively launches replacement Spot Instances as soon as an interruption warning is signaled, keeping the running fleet at full size throughout the entire batch run.

   Capacity Rebalancing maintains fleet capacity by launching replacements early, but it does not checkpoint or transfer job state, so in-progress work is still lost unless the app saves state on the notice.

Poll the EC2 metadata spot/termination-time endpoint for the 2-minute interruption notice and checkpoint job state to S3 before graceful shutdown.

11. EBS snapshots are incremental after the first snapshot: What is the most cost-efficient way to reduce snapshot

1. Switch from EBS snapshots to EBS-backed AMIs, which store the volume data more efficiently than raw snapshots and therefore reduce the total storage cost of retaining thirty days of daily backups, since AMIs deduplicate the underlying block data across all retained images in a way plain snapshots cannot.

   EBS-backed AMIs are themselves backed by EBS snapshots and use the same incremental billing model, so switching to AMIs does not deduplicate data or lower snapshot storage cost.
2. Enable EBS Snapshot Archive on all thirty daily snapshots so their data is moved into the low-cost archive tier while every snapshot remains immediately available for the daily 30-day rotation and for creating the next incremental snapshot in the chain.

   Archived snapshots leave the incremental chain and take 24-72 hours to restore, so they cannot back a daily rotating set. Archive suits long-term isolated snapshots, not a 30-day incremental rotation.
3. EBS snapshots are incremental after the first snapshot — only changed blocks are stored. The displayed size shows the total volume data but billing is based on the incremental difference. Costs may already be near-optimal; verify by checking the snapshot's storage usage in the EBS console. ✓

   EBS snapshots are incremental. The first snapshot stores all used blocks; subsequent snapshots store only changed blocks. The 'size' shown in the console is the total volume size, not the actual stored data. Billing is based on actual stored blocks across all snapshots, not 30 × full volume size.
4. Retain only weekly snapshots, about four or five per month instead of thirty daily ones, to cut the number of stored snapshots and reduce the overall EBS snapshot charges, accepting a coarser recovery cadence in exchange for the far lower snapshot count.

   Because snapshots are incremental, fewer snapshots do not proportionally cut cost, and reducing frequency raises RPO. The question asks to cut cost without changing retention, which the incremental model already addresses.

EBS snapshots are incremental — only changed blocks are stored after the first snapshot; displayed size is volume size, not stored delta size. Verify actual stored bytes in the console.

12. AWS Backup, which provides a centralized console: Which service simplifies this?

1. Build a Lambda function on an EventBridge schedule that calls each service's native backup API in turn and enforces retention through per-service lifecycle rules, giving one custom orchestrator for all resource types.

   Custom Lambda orchestration requires substantial development and ongoing maintenance and reimplements what AWS Backup already provides as a managed, centralized service with no custom code.
2. Use AWS CloudFormation StackSets to deploy service-specific backup configurations consistently across every account and Region, standardizing the schedules and retention for RDS, EBS, DynamoDB, and EFS.

   StackSets can provision backup settings but still leaves each resource type managed through its own separate mechanism. AWS Backup adds a unified management layer across all these services.
3. Continue using each service's own native backup features — RDS automated backups, EBS lifecycle policies, DynamoDB PITR, and EFS backups — and coordinate their schedules and retention individually per service.

   Separate native mechanisms create exactly the multi-console, inconsistent-schedule complexity described in the scenario. AWS Backup consolidates them into a single backup plan and console.
4. AWS Backup, which provides a centralized console for defining backup plans — schedules, retention, and cross-region copy rules — that apply consistently across RDS, EBS, DynamoDB, EFS, and other supported services. ✓

   AWS Backup unifies backup management across supported services: EC2 (EBS volumes), RDS (including Aurora), DynamoDB, EFS, FSx, S3, Storage Gateway, and more. A single backup plan with rules defines backup schedule, retention, and optional cross-region/cross-account copy — applied via resource tag assignment or specific resource ARN selection.

AWS Backup centralizes backup plans across RDS, EBS, DynamoDB, EFS, and more — one policy covers schedules, retention, and cross-region copies across all supported services.

Other AWS SysOps domains

• Monitoring, Logging, and Remediation — 100 questions →
• Networking and Content Delivery — 90 questions →
• Deployment, Provisioning, and Automation — 89 questions →
• Security and Compliance — 79 questions →
• Cost and Performance Optimization — 60 questions →
• All 498 AWS SysOps questions →