Auto Scaling practice questions

Increase the ALB target group deregistration delay.

Why wrong: Deregistration delay affects how long old instances stay in service during scale-in, not how quickly new instances become available.

Reduce the Auto Scaling group minimum size to one instance.

Why wrong: Lowering minimum capacity can reduce cost, but it does not make additional instances available faster during demand spikes.

Replace the Application Load Balancer with a Network Load Balancer.

Why wrong: A Network Load Balancer does not solve instance bootstrapping time and is not the main lever for faster scale-out readiness.

Reduce the ASG health check grace period to 0 seconds so issues are detected faster.

Why wrong: A shorter grace period increases the chance that instances will be marked unhealthy before the application finishes startup or initialization. That can reduce available capacity and increase downtime during deployments.

Restrict the ASG to a single Availability Zone so health check evaluation is simpler.

Why wrong: Reducing the ASG to one Availability Zone decreases fault tolerance. It also increases the blast radius of deployment errors or AZ issues, worsening resiliency rather than improving it.

Disable ALB health checks so the ASG does not terminate instances on HTTP 5xx responses.

Why wrong: Disabling health checks removes the safety mechanism that prevents routing traffic to broken instances. The system can become unavailable or degrade because the ALB may route requests to unhealthy targets.

Keep the ASG scaling policy based on CPU utilization, but increase the ASG min capacity by 50%.

Why wrong: Raising the minimum capacity can reduce the odds of running out of healthy targets, but the scaling decision is still driven by CPU. In this scenario, CPU is explicitly <40% during the timeouts, so CPU-based scaling may not trigger additional capacity early enough for the request-rate increase. This also permanently increases baseline cost even when traffic is low.

Enable EC2 detailed monitoring for one-minute granularity and keep CPU scaling.

Why wrong: More frequent CPU measurements may make scaling react slightly faster, but it does not change the underlying signal. Since CPU remains below 40% during timeouts, the CPU metric still won’t reflect the bottleneck (insufficient healthy targets for the request rate), so scaling may not increase capacity when needed.

Switch to scaling based on the ASG network out bytes metric only, ignoring ALB response metrics.

Why wrong: Network out bytes can correlate with traffic, but it is not a direct measure of user-perceived performance. It can be noisy (for example, from background data transfer) and it may not capture saturation effects that show up as rising ALB latency or request queuing. ALB request/latency metrics provide a closer feedback loop to timeouts.

Add more subnets across additional Availability Zones to distribute the same instances more widely.

Why wrong: Adding subnets/AZs increases fault tolerance, but it does not address the immediate cause of the outage: the target group (via ALB health checks) is marking instances unhealthy before the application is ready. The unhealthy/replace loop would still occur for each instance that starts during deployments.

Switch the load balancer target type from instance targets to IP targets to avoid health check failures.

Why wrong: Target type does not change application readiness. Even with IP targets, the ALB health check fails until the application starts responding on the configured health check path/port, so the Auto Scaling group would still see unhealthy targets and replace instances.

Reduce the ALB health check interval so unhealthy targets are removed faster.

Why wrong: Reducing the interval makes ALB detect failure conditions sooner. With a ~2-minute initialization time, this increases the chance that instances are marked unhealthy and replaced before they can become ready, making the problem worse rather than improving start-up resilience.

Increase the Auto Scaling group's desired capacity to a higher number than required.

Why wrong: Higher desired capacity may reduce the symptoms by keeping more instances running, but it does not stop the ASG from terminating individual instances that fail health checks before the app is ready.

Disable ALB target group health checks so instances are considered healthy as soon as they register.

Why wrong: Disabling health checks can route traffic to targets that are still warming up. That can increase 5xx errors and does not address ASG termination based on unhealthy health evaluations.

Change the Auto Scaling health check type from ELB to EC2 so the ALB will no longer determine instance health.

Why wrong: Even if EC2 status checks pass, the application may still not be ready. The instance can remain in service while still causing failed requests, and the ASG will not use ALB readiness to enforce correct routing behavior.

Amazon EKS

Why wrong: Amazon EKS is Kubernetes-based. Even though it is AWS-managed, it still requires a Kubernetes control plane and Kubernetes-specific operational concepts (for example, deployments, services, and Kubernetes APIs). This is unnecessary when Kubernetes compatibility is explicitly not required.

An EC2 Auto Scaling group only

Why wrong: An EC2 Auto Scaling group can scale compute instances, but it does not orchestrate containers (it does not schedule, place, or manage container tasks). You would still need an orchestration/control layer (such as ECS/EKS or a custom solution).

Amazon SQS as the compute layer

Why wrong: Amazon SQS is a messaging/queueing service. It does not run containers or provide container orchestration (it cannot schedule container tasks, maintain desired task counts, or manage runtime placement).

Increase the instance size so each server can handle more traffic alone.

Why wrong: A larger instance may improve capacity, but it does not protect against an Availability Zone failure. If the Zone goes down, all instances in that Zone are still lost regardless of their size.

Disable ALB health checks so instances stay registered longer.

Why wrong: Health checks are useful for removing unhealthy targets quickly. Disabling them would make failover and recovery worse because the load balancer could keep sending traffic to broken instances.

Run the whole stack in one Availability Zone for simpler networking.

Why wrong: A single Availability Zone creates a clear single point of failure. Simplicity may be appealing, but it does not meet the goal of surviving a Zone outage.

Move PostgreSQL to Amazon DynamoDB without redesigning the application.

Why wrong: DynamoDB is a different database model and is not a drop-in replacement for PostgreSQL. Using it would require significant application and data-model changes, so it does not fit the goal of a low-friction cost and operations improvement.

Replace RabbitMQ with another EC2-based broker cluster for more control.

Why wrong: This keeps the same operational burden because the team still has to patch, back up, and scale the broker infrastructure. More control is not the same as lower cost or lower management overhead.

Keep the same design and increase instance sizes to simplify maintenance.

Why wrong: Larger instances may temporarily reduce tuning pressure, but they do not remove the operational work of managing a database and broker. The scenario is about reducing self-managed infrastructure overhead, not only increasing raw capacity.

Increase provisioned concurrency to 100 so that cold starts never occur, regardless of traffic patterns.

Why wrong: Higher provisioned concurrency increases cost and does not address idle spend during low traffic periods.

Turn provisioned concurrency off permanently and rely on retries at the client side to mask cold starts.

Why wrong: Disabling provisioned concurrency reintroduces cold starts and may degrade user experience, especially during spikes.

Replace Lambda with a single always-on EC2 instance sized for peak demand to eliminate cold starts.

Why wrong: Always-on instances can be more expensive during idle periods and contradict the serverless cost tradeoff goal.

Keep both workloads on large provisioned RDS instances and add read replicas for the cart store.

Why wrong: Incorrect. This keeps both systems on fixed-capacity relational infrastructure even where a simpler managed database would be cheaper. The cart workload does not justify expensive relational replicas.

Use DynamoDB provisioned capacity with a fixed minimum despite the unpredictable traffic.

Why wrong: Incorrect. Fixed provisioned capacity can be cheaper only when traffic is stable and predictable. Here, the company explicitly wants to avoid paying for idle capacity during variable demand.

Replace the relational order system with a wide-column table to reduce SQL licensing.

Why wrong: Incorrect. Replacing the relational system would force a redesign and remove the SQL and transaction model that order processing usually needs. Cost optimization should not break the application requirements.

A VPC endpoint for CloudWatch only

Why wrong: A VPC endpoint changes network path, not instance capacity.

S3 Object Lock

Why wrong: Object Lock controls retention, not EC2 compute capacity.

Disable health checks

Why wrong: Disabling health checks weakens availability and does not improve capacity.

All instances in one larger subnet

Why wrong: One AZ remains a single point of failure.

A Network Load Balancer in one subnet

Why wrong: A load balancer in one AZ does not make the application resilient to AZ failure.

A single EC2 instance with detailed monitoring

Why wrong: Monitoring does not provide redundancy.

Create an IAM user for each developer and keep the existing broad permissions, rotating keys every 90 days.

Why wrong: Long-lived IAM user access contradicts temporary credentials requirements. Rotating keys reduces exposure but does not prevent repeated leakage or enforce least privilege at scale.

Attach a policy that allows ecs:* and autoscaling:* and rely on developers to self-review that no IAM statements are added to their roles.

Why wrong: Self-review is not an enforceable control. Without a permission boundary or explicit deny, developers could add iam:* permissions and violate the security requirement.

Create a single shared IAM role with full administrator permissions so developers can troubleshoot faster when deployments fail.

Why wrong: Administrator permissions violate least-privilege and allow IAM changes. A shared role also makes accountability weaker and increases blast radius of mistakes.

Increase the t3.large maximum CPU credits and keep the Auto Scaling group using the same burstable instance type.

Why wrong: Increasing credits can reduce throttling for short or intermittent bursts, but t3 instances still depend on accumulated CPU credits. During sustained peak traffic, credits will deplete and the instance can throttle, so p95 latency predictability remains limited.

Add a placement group to the existing t3.large instances so they are packed close together for lower latency between nodes.

Why wrong: Placement groups can help certain network-oriented communication patterns by improving latency and/or bandwidth, but the observed symptom is CPU credit depletion on burstable instances. Changing placement does not address CPU throttling caused by credit exhaustion.

Switch the workload to run on Lambda with the same logic so invocations automatically scale without instance selection changes.

Why wrong: Lambda may scale automatically, but provisioned and on-demand execution characteristics do not inherently remove the underlying issue you observed (burstable CPU throttling on t3). For CPU-bound, latency-sensitive batch-like processing, moving to Lambda could introduce other constraints (cold starts, execution limits, concurrency dynamics) and does not directly target credit-based throttling as the root cause.

Keep the ASG in one subnet/AZ, but enable ALB stickiness to reduce session interruption.

Why wrong: Stickiness affects session routing but does not create targets in a second AZ during an AZ outage.

Add a NAT gateway in the public subnets so instances can reach the internet during maintenance events.

Why wrong: NAT affects outbound connectivity, not target placement or health during an AZ outage.

Create a second ALB in the same Availability Zone and route traffic using DNS failover.

Why wrong: DNS failover adds complexity and still depends on healthy targets; without multi-AZ instances, failover won’t help much.

Place the instances in a single subnet and increase the instance size.

Why wrong: This does not add automatic recovery or remove unhealthy instances from service.

Use a network ACL to detect failed instances and restart them.

Why wrong: Network ACLs filter traffic, but they do not monitor instance health or restart servers.

Store the web servers on EBS volumes so the data survives failures.

Why wrong: Persistent storage alone does not automatically recover failed compute instances or shift traffic.

Stop resizing EBS and only scale out the ASG during peak traffic, because changing EBS performance settings risks latency spikes.

Why wrong: The problem includes both overprovisioned gp3 performance and underutilized CPU. Only scaling out during peaks increases compute cost and does not address the consistently low gp3 IOPS/throughput utilization that is already wasting money.

Switch the instances to EC2 Spot immediately, because Spot always lowers costs without adding operational risk or affecting performance.

Why wrong: Spot can reduce costs, but it introduces possible interruptions and capacity variability. The prompt does not state the workload can safely handle interruptions, and it does not guarantee that performance will remain stable under Spot interruptions/replacements.

Move the workload to a larger instance class and keep the gp3 settings unchanged to avoid operational tuning work.

Why wrong: Using larger instances increases compute cost and does not address the unnecessary gp3 provisioned IOPS/throughput that is already underutilized. This contradicts the goal of reducing cost while maintaining performance.

Set the target group HealthCheckGracePeriod to a very short value so the ALB quickly declares instances healthy or unhealthy.

Why wrong: A short grace period makes the target group start health evaluation before the application is ready. Instances that are still bootstrapping can be marked unhealthy, increasing the likelihood that all targets become unhealthy during rollout.

Disable ALB target group health checks and route traffic to any registered targets so replacements do not depend on health check status.

Why wrong: Without ALB target health checks, the ALB cannot prevent requests from being forwarded to targets that are not ready or are failing during deployment. That directly increases the risk of 502 errors.

Reduce the ASG desired capacity by one instance during deployments so the replacement happens faster.

Why wrong: Lowering desired capacity reduces the number of instances that can be healthy during the deployment. During transient bootstrapping or restart periods, it becomes easier for the entire target group to reach zero healthy targets.

Reduce the ASG desired capacity by 1 and rely on the ALB to route traffic to fewer instances during the outage.

Why wrong: Reducing desired capacity makes the ASG intentionally maintain less capacity. It does not address why instances are not being replaced, so capacity may not recover automatically to the original level after the outage.

Move the ALB to only one subnet so health checks and routing remain consistent during the outage.

Why wrong: An ALB can only route traffic through the load balancer nodes placed in the selected subnets/AZs. If the single selected subnet/AZ is affected, the ALB can become unavailable even if the ASG launches healthy instances elsewhere.

Add an S3 event trigger to terminate unhealthy instances so the ASG can scale back out using its scheduled actions.

Why wrong: S3 events do not correlate with ALB target health or Availability Zone failures for EC2 instances. Scheduled scaling actions may also not run immediately in response to health deterioration, so this approach will not directly fix the recovery mechanism.

A single EC2 instance with detailed monitoring

Why wrong: Monitoring does not provide redundancy.

All instances in one larger subnet

Why wrong: One AZ remains a single point of failure.

A Network Load Balancer in one subnet

Why wrong: A load balancer in one AZ does not make the application resilient to AZ failure.