Cost Optimization practice questions

A startup has a stable production web service that runs continuously (24/7) on AWS. They have consistent compute requirements for the next 1 year, but the instance size and family might change as they optimize performance. To reduce cost while maintaining flexibility across instance types, which purchasing option should they consider?

Trap 1: Reserved Instances with a fixed instance type

Fixed instance-type Reserved Instances can limit flexibility if the team needs to change instance families.

Trap 2: Spot Instances

Spot is interruption-capable and may not be appropriate for always-on production without added complexity.

Trap 3: On-Demand Instances

On-Demand provides maximum flexibility but generally lacks the savings of commitment-based plans.

A
Compute Savings Plans
Compute Savings Plans discount compute usage while allowing flexibility across instance families, sizes, and even some services.
B
Reserved Instances with a fixed instance type
Why wrong: Fixed instance-type Reserved Instances can limit flexibility if the team needs to change instance families.
C
Spot Instances
Why wrong: Spot is interruption-capable and may not be appropriate for always-on production without added complexity.
D
On-Demand Instances
Why wrong: On-Demand provides maximum flexibility but generally lacks the savings of commitment-based plans.

Question 2easymultiple choice

An application runs on an EC2 Auto Scaling group. Over the last month, CPU utilization averaged 8% with no sustained memory pressure, and response times are stable. The team wants to lower monthly cost without changing the application. What is the most appropriate next step for cost optimization?

Trap 1: Increase desired capacity to 2x so utilization increases and…

Doubling desired capacity increases the number of running instances and therefore increases cost. The observed low CPU utilization indicates the opposite direction (reducing capacity/infrastructure).

Trap 2: Disable Auto Scaling so the group never scales down to preserve…

Disabling Auto Scaling removes the ability to scale down during low-demand periods, which typically increases cost. It also reduces resilience to demand changes.

Trap 3: Switch the workload to Spot instances immediately to avoid…

Spot can reduce cost, but the scenario provides no evidence that the application can tolerate interruptions or forced termination. Right sizing should be done based on observed utilization and workload tolerance.

A
Evaluate a smaller EC2 instance type (via the Auto Scaling launch template/configuration) for the group and validate performance metrics after the change.
If utilization is consistently low and performance is stable, the current instances are likely overprovisioned. Moving to a smaller instance type directly reduces compute cost while preserving capacity for normal load.
B
Increase desired capacity to 2x so utilization increases and instances become “more efficient.”
Why wrong: Doubling desired capacity increases the number of running instances and therefore increases cost. The observed low CPU utilization indicates the opposite direction (reducing capacity/infrastructure).
C
Disable Auto Scaling so the group never scales down to preserve baseline performance.
Why wrong: Disabling Auto Scaling removes the ability to scale down during low-demand periods, which typically increases cost. It also reduces resilience to demand changes.
D
Switch the workload to Spot instances immediately to avoid On-Demand charges, regardless of interruption risk.
Why wrong: Spot can reduce cost, but the scenario provides no evidence that the application can tolerate interruptions or forced termination. Right sizing should be done based on observed utilization and workload tolerance.

Question 3mediummultiple choice

An Auto Scaling group for a background worker runs EC2 instances continuously. Over the last 30 days, CloudWatch shows sustained CPU utilization around 6% with no memory pressure, and queue processing latency meets all SLAs. The team wants to lower monthly cost with minimal risk. What is the best next action?

Trap 1: Increase the instance size to reduce CPU throttling risk

The metrics show sustained low CPU with no reported throttling risk. Increasing size would likely increase cost immediately without addressing an existing performance problem.

Trap 2: Switch the group to Spot Instances to reduce cost without changing…

Spot could reduce compute price, but it introduces interruption risk and additional operational complexity. When the primary waste is clearly overprovisioned capacity, downsizing is the more direct and lower-risk cost optimization.

Trap 3: Buy Reserved Instances with a long term commitment before making…

Purchasing capacity commitments can reduce unit price, but it does not fix the cost waste from running much larger-than-needed instances. Since the instance utilization indicates overprovisioning, right sizing should come first to maximize savings with minimal risk.

A
Increase the instance size to reduce CPU throttling risk
Why wrong: The metrics show sustained low CPU with no reported throttling risk. Increasing size would likely increase cost immediately without addressing an existing performance problem.
B
Perform right sizing by downsizing to a smaller instance family/size and validate SLAs
Right sizing uses actual utilization to remove overprovisioning. With low CPU and no memory pressure and SLAs already met, downsizing (while validating under load and during a controlled rollout) is the safest way to reduce waste.
C
Switch the group to Spot Instances to reduce cost without changing instance sizing
Why wrong: Spot could reduce compute price, but it introduces interruption risk and additional operational complexity. When the primary waste is clearly overprovisioned capacity, downsizing is the more direct and lower-risk cost optimization.
D
Buy Reserved Instances with a long term commitment before making any sizing changes
Why wrong: Purchasing capacity commitments can reduce unit price, but it does not fix the cost waste from running much larger-than-needed instances. Since the instance utilization indicates overprovisioning, right sizing should come first to maximize savings with minimal risk.

Review the full routing breakdown →

Question 4hardmultiple choice

Based on the exhibit, the company runs a self-managed RabbitMQ cluster on EC2 for asynchronous work. The queue only needs durable at-least-once delivery, and the application does not require AMQP-specific features such as exchanges, routing keys, or broker plugins. Which change is the best cost-optimization move?

Exhibit

Architecture inventory:
  3 EC2 instances for RabbitMQ
  2 EC2 instances for application workers
  Average broker CPU: 8%-12%
  Average broker memory: 18%-22%
  Monthly ops time spent on broker patching, backups, and failover testing: 14 hours
Message requirements:
  Durable queueing
  At-least-once delivery acceptable
  No need for broker-managed topics or complex routing
Failure note:
  A node reboot caused a 9-minute enqueue outage last month

Trap 1: Replace RabbitMQ with Amazon MQ for RabbitMQ to keep the same…

Amazon MQ reduces some administration effort, but it is still a broker service with broker-related costs. For a workload that does not need AMQP-specific features, SQS is typically cheaper and simpler because it removes the broker layer entirely.

Trap 2: Increase the RabbitMQ instance size and add a fourth node for…

The exhibit shows very low CPU and memory utilization, so scaling the cluster up would raise cost without addressing the underlying self-managed broker overhead. It also does not eliminate the patching, backup, and failover-testing burden.

Trap 3: Move the queue to Amazon DynamoDB and use scans for consumers to…

DynamoDB is not a queue service, and scanning it for work items is inefficient and expensive at scale. This would add complexity and would not provide the same messaging semantics as a real queue.

A
Replace RabbitMQ with Amazon SQS Standard and keep the workers unchanged except for the queue client library.
Amazon SQS is a fully managed queue that satisfies durable, at-least-once messaging without requiring broker administration. It removes the EC2 broker fleet, patching, backups, and failover testing, and it reduces outage risk from broker maintenance. Because the workload does not need AMQP-specific features such as exchanges or routing keys, SQS is the most cost-effective and operationally simple replacement.
B
Replace RabbitMQ with Amazon MQ for RabbitMQ to keep the same protocol and reduce costs.
Why wrong: Amazon MQ reduces some administration effort, but it is still a broker service with broker-related costs. For a workload that does not need AMQP-specific features, SQS is typically cheaper and simpler because it removes the broker layer entirely.
C
Increase the RabbitMQ instance size and add a fourth node for higher availability.
Why wrong: The exhibit shows very low CPU and memory utilization, so scaling the cluster up would raise cost without addressing the underlying self-managed broker overhead. It also does not eliminate the patching, backup, and failover-testing burden.
D
Move the queue to Amazon DynamoDB and use scans for consumers to detect new messages.
Why wrong: DynamoDB is not a queue service, and scanning it for work items is inefficient and expensive at scale. This would add complexity and would not provide the same messaging semantics as a real queue.

Question 5easymultiple choice

CloudWatch metrics show your EC2 instances have average CPU utilization around 10% with stable performance over several weeks. The application does not require additional headroom right now. What is the most effective cost-optimization action?

Trap 1: Increase the Auto Scaling desired capacity to add more instances

Adding more instances increases total compute capacity and typically increases cost, even if CPU utilization is low. Auto Scaling is intended to respond to demand changes; raising desired capacity without a demand need does not address the current overprovisioning.

Trap 2: Switch to Spot Instances immediately even though interruptions…

Switching to Spot is a pricing decision that introduces interruption risk. The scenario’s primary measurable issue is persistent underutilization; switching to Spot would be unnecessary and potentially risky given the stated interruption impact. Cost optimization here should first target the dominant cost lever: oversized compute.

Trap 3: Disable detailed monitoring to reduce CPU usage from the monitoring…

Reducing monitoring detail might lower monitoring charges, but it does not address the main driver of EC2 cost: unused instance capacity. Any CPU impact from monitoring is usually minor compared with the savings from downsizing instances.

A
Right-size the instances to a smaller size that matches the observed utilization
Right sizing reduces cost by matching instance capacity to actual demand. If average CPU is consistently low (around 10%) and performance is stable, it strongly indicates overprovisioning. Moving to a smaller instance (or a smaller capability within the same family) typically lowers hourly cost while maintaining sufficient capacity for the workload.
B
Increase the Auto Scaling desired capacity to add more instances
Why wrong: Adding more instances increases total compute capacity and typically increases cost, even if CPU utilization is low. Auto Scaling is intended to respond to demand changes; raising desired capacity without a demand need does not address the current overprovisioning.
C
Switch to Spot Instances immediately even though interruptions would impact users
Why wrong: Switching to Spot is a pricing decision that introduces interruption risk. The scenario’s primary measurable issue is persistent underutilization; switching to Spot would be unnecessary and potentially risky given the stated interruption impact. Cost optimization here should first target the dominant cost lever: oversized compute.
D
Disable detailed monitoring to reduce CPU usage from the monitoring agent
Why wrong: Reducing monitoring detail might lower monitoring charges, but it does not address the main driver of EC2 cost: unused instance capacity. Any CPU impact from monitoring is usually minor compared with the savings from downsizing instances.

Read the full NAT/PAT explanation →

Question 6hardmultiple choice

A batch analytics job currently uses two NAT gateways in each of three Availability Zones, but only one private subnet per AZ needs outbound internet access. What should the architect review first?

Trap 1: Replacing every NAT gateway with an internet gateway attached to…

Private subnets cannot use an internet gateway directly without public IP routing.

Trap 2: Disabling route tables

Route tables are required for subnet routing.

Trap 3: Moving all workloads to public subnets

This weakens security posture and is not a cost-first best practice.

A
Replacing every NAT gateway with an internet gateway attached to private subnets
Why wrong: Private subnets cannot use an internet gateway directly without public IP routing.
B
Whether one NAT gateway per AZ is sufficient for the required private subnets
NAT gateways are normally deployed per AZ for resilience; duplicate NAT gateways in the same AZ may be unnecessary.
C
Disabling route tables
Why wrong: Route tables are required for subnet routing.
D
Moving all workloads to public subnets
Why wrong: This weakens security posture and is not a cost-first best practice.

Question 7mediummultiple choice

A media company runs a 24/7 recommendation engine on EC2 in one AWS Region. The workload is interruption-intolerant, and the team expects steady usage but may change instance families and sizes during planned optimizations. Compared to the current On-Demand setup, they want the lowest cost while avoiding the rigidity of locking to a specific instance type.

What should the solutions architect recommend?

Trap 1: Switch the instances to Spot Instances and use interruption…

Spot Instances provide strong discounts, but interruption tolerance is required, which the workload lacks.

Trap 2: Purchase a Standard Reserved Instance tied to a single specific…

Standard RIs can reduce cost, but they are less flexible when the team needs instance-type changes.

Trap 3: Keep On-Demand and rely on Auto Scaling to reduce capacity when…

Auto Scaling can help, but for interruption-intolerant 24/7 usage it usually cannot match Savings Plans.

A
Switch the instances to Spot Instances and use interruption handling because it is the largest discount.
Why wrong: Spot Instances provide strong discounts, but interruption tolerance is required, which the workload lacks.
B
Purchase a Compute Savings Plan for the expected steady hourly usage in that Region.
Compute Savings Plans discount the usage while allowing flexibility across instance families and sizes in the Region.
C
Purchase a Standard Reserved Instance tied to a single specific instance type for the next 3 years.
Why wrong: Standard RIs can reduce cost, but they are less flexible when the team needs instance-type changes.
D
Keep On-Demand and rely on Auto Scaling to reduce capacity when utilization is low.
Why wrong: Auto Scaling can help, but for interruption-intolerant 24/7 usage it usually cannot match Savings Plans.

Question 8mediummulti select

A company is running a stateful web application on EC2 instances that processes user uploads. The architecture currently uses a Multi-AZ deployment for high availability. Which three cost-optimization strategies can be applied without sacrificing high availability? (Choose three.)

Question 9mediummulti select