CCNA Design Cost-Optimized Architectures Questions — Page 2 of 3

MCQmedium

A internal reporting portal serves infrequently accessed user documents that must be available immediately when requested. Which S3 storage class is likely the best cost fit?

A.Instance store volumes

B.S3 Glacier Deep Archive

C.S3 Standard for all objects

D.S3 Standard-IA or S3 One Zone-IA depending on resilience requirements

AnswerD

S3 Standard-IA is the right baseline for infrequent access because it charges less for storage than S3 Standard while still providing millisecond first-byte latency and multi-AZ durability. If the reporting data can be regenerated or an AZ failure is an acceptable risk, S3 One Zone-IA costs even less by storing copies in a single availability zone, but it sacrifices resilience to AZ destruction. The choice between the two depends on the portal's recovery point objective and whether losing the current copy would be disruptive to the business.

Why this answer

S3 Standard-IA or S3 One Zone-IA is the best cost fit because the data is infrequently accessed but must be available immediately when requested. These storage classes offer low-latency retrieval (milliseconds) at a lower storage cost than S3 Standard, with the trade-off of a retrieval fee. The choice between Standard-IA and One Zone-IA depends on whether the application requires resilience against Availability Zone failures.

Exam trap

The trap here is that candidates may choose S3 Standard for all objects because they assume 'immediately available' requires the highest performance tier, overlooking that Standard-IA and One Zone-IA offer identical retrieval latency at a lower storage cost for infrequently accessed data.

How to eliminate wrong answers

Option A is wrong because instance store volumes are ephemeral block storage attached to EC2 instances, not an S3 storage class, and data is lost if the instance is stopped or terminated. Option B is wrong because S3 Glacier Deep Archive has retrieval times of 12–48 hours, which does not meet the 'immediately available' requirement. Option C is wrong because S3 Standard is designed for frequently accessed data and would incur higher storage costs for infrequently accessed objects, making it less cost-optimal than Standard-IA or One Zone-IA.

Practice this question →

MCQeasy

Your global users access static images stored in S3. Origin bandwidth costs are higher than expected because CloudFront is not caching effectively. What change most directly reduces origin fetches (and typically lowers data transfer costs) without changing application logic?

A.Configure CloudFront caching by setting appropriate cache-control headers and/or CloudFront cache policy/TTL values for the static objects

B.Disable CloudFront caching so every request goes back to S3 for the latest image

C.Route users directly to the S3 website endpoint to bypass CloudFront

D.Turn on a NAT Gateway for the CloudFront origin to reduce bandwidth charges

AnswerA

CloudFront reduces origin fetches when responses are cacheable and allowed to remain in the edge cache for a meaningful duration. Ensuring the objects include correct cache-control headers (or configuring CloudFront cache policy TTLs) increases cache hit rate, so fewer requests require fetching from S3 origin. This directly reduces origin bandwidth and related data transfer costs.

Why this answer

The high origin bandwidth costs are caused by CloudFront not caching effectively, meaning too many requests reach the S3 origin. By configuring appropriate Cache-Control headers or a CloudFront cache policy with optimal TTL values, you ensure that CloudFront caches the static images at edge locations for longer periods. This directly reduces the number of origin fetches, lowering data transfer costs without any changes to the application logic.

Exam trap

The trap here is that candidates may think disabling caching or bypassing CloudFront entirely will reduce costs, when in fact the opposite is true—effective caching is the key to reducing origin fetches and lowering data transfer costs.

Why the other options are wrong

Disabling CloudFront caching forces every request to the S3 origin, increasing origin fetches and data transfer costs, which is the opposite of the goal to reduce them.

A NAT Gateway is used to enable private subnets to access the internet or other AWS services, not to reduce bandwidth charges for CloudFront origins. It does not affect CloudFront caching or origin fetch behavior.

Practice this question →

MCQmedium

A team runs an EC2-based service and ships logs to Amazon CloudWatch Logs. They enabled long log retention and turned on detailed monitoring to improve troubleshooting. Their monthly CloudWatch costs have grown unexpectedly. Compliance requires that the logs remain available in CloudWatch Logs (for querying and audits) for 90 days, and alerts/alarms do not require detailed EC2 monitoring. What change best reduces cost while meeting requirements?

A.Keep the current long retention and detailed monitoring; reduce the log volume by sampling 10% of events

B.Set the CloudWatch Logs retention to 90 days and disable detailed EC2 monitoring (use standard monitoring) for the instances

C.Move all logs to S3 immediately and delete the CloudWatch log groups to reduce costs

D.Increase CloudWatch alarm thresholds to reduce the number of metric datapoints

AnswerB

CloudWatch Logs storage costs are driven primarily by retention period. Setting retention to exactly 90 days reduces storage cost while meeting compliance. Disabling detailed EC2 monitoring reduces the number/granularity of metrics (detailed is billed more than standard), lowering monitoring cost without impacting alarms that don’t require high-resolution metrics.

Why this answer

Reduces costs by setting CloudWatch Logs retention to exactly 90 days (meeting compliance) and disabling detailed monitoring (which incurs per-minute metrics charges) in favor of standard 5-minute monitoring. This directly addresses the two main cost drivers—long retention and detailed EC2 monitoring—while preserving the required 90-day log availability for queries and audits.

Exam trap

The trap here is that candidates may think sampling logs or moving them to S3 is acceptable, but the requirement explicitly states logs must remain available in CloudWatch Logs for querying and audits, making those options non-compliant.

How to eliminate wrong answers

Option A is wrong because sampling only 10% of log events would lose critical data for troubleshooting and audits, violating the compliance requirement that logs remain available for 90 days. Option C is wrong because moving logs to S3 immediately and deleting CloudWatch log groups would remove the ability to query logs in CloudWatch Logs Insights, breaking the requirement that logs remain available in CloudWatch Logs for querying. Option D is wrong because increasing alarm thresholds does not reduce the number of metric datapoints collected; detailed monitoring still sends per-minute metrics, and thresholds only affect when alarms trigger, not the volume of data ingested or stored.

Practice this question →

MCQmedium

A dev sandbox has unpredictable DynamoDB traffic with long idle periods and occasional spikes. Which capacity mode should minimize operational overhead and avoid paying for idle provisioned capacity? The architecture review board prefers a managed AWS-native control.

A.Reserved capacity for maximum daily traffic

B.Provisioned capacity set for peak traffic

C.DynamoDB on-demand capacity mode

D.Global tables in every Region

AnswerC

DynamoDB on-demand capacity mode charges only for the read and write requests you actually make, with no minimum capacity, no capacity planning, and no manual scaling. It can instantly scale from zero to any required throughput to absorb traffic spikes, making it ideal for unpredictable workloads like a development sandbox that may sit idle for hours or days. During idle periods your bill drops to near zero, and you never have to worry about throttle errors or forecasting demand—exactly matching the workload characteristics described in the question.

Why this answer

DynamoDB on-demand capacity mode (Option C) is ideal for unpredictable traffic with long idle periods and spikes because it automatically scales to handle workload demands without requiring any capacity planning. You pay only for the reads and writes you perform, eliminating the cost of idle provisioned capacity and the operational overhead of managing scaling thresholds.

Exam trap

The trap here is that candidates may confuse 'Reserved capacity' (an EC2/RDS concept) with DynamoDB pricing, or assume Provisioned capacity is always cheaper without considering the cost of idle resources in unpredictable workloads.

How to eliminate wrong answers

Option A is wrong because Reserved capacity is not a DynamoDB pricing model; it applies to Amazon RDS and EC2, not DynamoDB, and would lock you into a fixed cost regardless of usage. Option B is wrong because Provisioned capacity set for peak traffic would require you to pay for the peak capacity even during idle periods, leading to wasted cost and manual scaling adjustments. Option D is wrong because Global tables are a replication feature for multi-Region active-active setups, not a capacity mode; they add complexity and cost without addressing the need to avoid paying for idle provisioned capacity.

Practice this question →

MCQmedium

A marketing site runs on x86 EC2 instances and uses open-source software with no architecture-specific licensing restriction. What should be evaluated to reduce compute cost? The design must avoid adding custom operational scripts.

A.Cross-Region data replication for all data

B.io2 Block Express volumes for all instances

C.AWS Graviton-based instances after performance testing

D.Dedicated Hosts by default

AnswerC

Graviton instances often provide better price performance for compatible workloads.

Why this answer

AWS Graviton-based instances (ARM architecture) offer up to 40% better price-performance compared to comparable x86 instances for many workloads. Since the marketing site uses open-source software with no architecture-specific licensing restrictions, migrating to Graviton after performance testing can significantly reduce compute costs without requiring custom operational scripts, as the OS and software can be recompiled for ARM natively.

Exam trap

The trap here is that candidates may assume Dedicated Hosts (Option D) are a cost-saving measure, but they actually increase costs unless you have specific licensing needs, and they violate the 'no custom operational scripts' constraint by requiring manual host management.

How to eliminate wrong answers

Option A is wrong because Cross-Region data replication increases data transfer and storage costs, and it does not reduce compute costs; it is a disaster recovery or latency optimization strategy, not a cost-saving measure for compute. Option B is wrong because io2 Block Express volumes are high-performance, high-cost SSD volumes designed for latency-sensitive workloads like databases, not for reducing compute costs; they would increase storage costs without affecting compute efficiency. Option D is wrong because Dedicated Hosts are a licensing option that incurs additional per-host charges and are only cost-effective for specific scenarios like bring-your-own-license (BYOL) software with socket/core restrictions; they do not reduce compute costs for open-source software and would increase operational overhead.

Practice this question →

MCQhard

A company runs a containerized microservices application on Amazon ECS with the Fargate launch type. The application experiences highly variable traffic, with long periods of low utilization and occasional sharp spikes. The company wants to minimize cost while ensuring the application can scale quickly during spikes. The tasks are stateless and can be restarted. Which combination of actions will meet these requirements MOST cost-effectively?

A.Use Fargate Spot for all tasks and enable ECS deployment circuit breaker to replace interrupted tasks.

B.Use Fargate On-Demand for all tasks and configure a scheduled scaling policy to add tasks at known peak times.

C.Use Fargate Spot capacity for all tasks and configure a target tracking scaling policy based on CPU utilization.

D.Use a mix of Fargate On-Demand for a baseline and Fargate Spot for additional capacity, with a target tracking scaling policy.

AnswerD

This approach uses On-Demand capacity to guarantee a reliable baseline and Spot capacity to handle bursts at a lower price. A target tracking policy scales the service based on demand, so during spikes more tasks are added. Since the tasks are stateless and restartable, Spot interruptions are tolerable, and the mix balances cost and availability.

Why this answer

For variable traffic with occasional spikes, a baseline of On-Demand capacity combined with Spot for burst capacity balances reliability and cost. Target tracking scaling responds to actual demand, and stateless tasks make Spot interruptions acceptable. Using Spot for everything risks availability, while using On-Demand for everything forgoes savings.

Exam trap

The trap here is assuming that Fargate Spot alone will always be cheaper and sufficient, ignoring the two-minute interruption notice and the need for a reliable baseline during sharp spikes.

Practice this question →

MCQhard

Based on the exhibit, the team wants to minimize compute cost for a workload with a steady 24/7 baseline and a separate nightly batch job that can be interrupted and resumed from checkpoints. They also expect to change EC2 instance families during the year as performance needs evolve. Which approach is the best fit?

A.Buy EC2 Instance Savings Plans for the baseline and run the nightly batch on On-Demand instances.

B.Use a Compute Savings Plan to cover the steady baseline and run the nightly batch on Spot Instances.

C.Purchase Standard Reserved Instances for all 12 instances and keep the current families fixed.

D.Run both tiers entirely on Spot Instances and rely on automatic restarts for the baseline web tier.

AnswerB

A Compute Savings Plan provides discount coverage while preserving flexibility across EC2 families and even other compute services. That makes it ideal for the steady baseline when future family changes are expected. Spot Instances are the lowest-cost choice for the restartable batch tier because interruptions are acceptable and checkpointing is already in place.

Why this answer

A Compute Savings Plan covers any EC2 instance family (or even container/Fargate usage) at a discounted rate, making it ideal for the steady 24/7 baseline. The nightly batch job can be interrupted and resumed from checkpoints, which is a perfect use case for Spot Instances, offering up to 90% cost savings. This combination minimizes compute cost while maintaining flexibility to change instance families during the year.

Exam trap

The trap here is that candidates often assume Reserved Instances or Instance Savings Plans are always cheaper, but they fail to recognize that the requirement to change instance families during the year makes Compute Savings Plans the only flexible discount option, and they overlook that Spot Instances are ideal for interruptible batch jobs.

How to eliminate wrong answers

Option A is wrong because EC2 Instance Savings Plans lock you into a specific instance family within a region, which conflicts with the requirement to change instance families during the year; also, running the nightly batch on On-Demand instances is more expensive than using Spot Instances. Option C is wrong because Standard Reserved Instances require a 1- or 3-year commitment and lock you into a specific instance family, which prevents the flexibility to change families and does not leverage Spot Instances for the interruptible batch job. Option D is wrong because running the steady baseline entirely on Spot Instances risks interruption (Spot Instances can be reclaimed with a 2-minute warning), which is unsuitable for a 24/7 workload that must remain stable and available.

Practice this question →

MCQhard

A media processing workflow generates analytics files that are accessed unpredictably. Some files become hot again months later. The team wants automatic storage cost optimisation without retrieval delays. What should be used?

A.S3 Intelligent-Tiering

B.Manual monthly review and object copying

C.S3 Glacier Flexible Retrieval for all files

D.EFS One Zone for analytics files

AnswerA

S3 Intelligent-Tiering automatically tracks object access and moves data between frequent and infrequent access tiers, with optional archive tiers, while charging no retrieval fees. It preserves S3 Standard latency and throughput, so analytics files remain immediately available when accessed. Because the tiering is entirely automated and backed by an SLA, it removes the need for human intervention or lifecycle guessing.

Why this answer

S3 Intelligent-Tiering automatically moves objects between access tiers (frequent, infrequent, and archive instant access) based on changing access patterns, with no retrieval delays for hot objects. This is ideal for unpredictable access where some files become hot again months later, as it optimizes storage costs without manual intervention or retrieval latency.

Exam trap

The trap here is that candidates may choose S3 Glacier Flexible Retrieval (Option C) thinking it is the cheapest archival option, but they overlook the requirement for 'no retrieval delays' and the unpredictable access pattern that makes Intelligent-Tiering's automatic tiering the correct choice.

How to eliminate wrong answers

Option B is wrong because manual monthly review and object copying is labor-intensive, error-prone, and cannot react to unpredictable access patterns in real time, leading to either higher costs or retrieval delays. Option C is wrong because S3 Glacier Flexible Retrieval has retrieval delays (minutes to hours) and is not suitable for files that may become hot again unpredictably, as it would introduce unacceptable latency. Option D is wrong because EFS One Zone is a file system, not an object storage service, and is designed for low-latency shared access within a single AZ, not for cost-optimized archival of analytics files with unpredictable retrieval.

Practice this question →

MCQmedium

A batch analytics job has unpredictable DynamoDB traffic with long idle periods and occasional spikes. Which capacity mode should minimize operational overhead and avoid paying for idle provisioned capacity? The design must avoid adding custom operational scripts.

A.DynamoDB on-demand capacity mode

B.Reserved capacity for maximum daily traffic

C.Provisioned capacity set for peak traffic

D.Global tables in every Region

AnswerA

On-demand capacity mode enables DynamoDB to automatically scale to match your workload's actual traffic, charging per read and write request (pay-per-request) rather than for provisioned capacity. For a batch analytics job with unpredictable traffic, this eliminates manual capacity planning, avoids throttling during sudden spikes, and ensures you only pay for the requests actually processed, making it the most cost-effective and operationally simple choice.

Why this answer

DynamoDB on-demand capacity mode automatically scales to handle unpredictable traffic spikes and idle periods without requiring any capacity planning or management. It charges only for the reads and writes you perform, eliminating the cost of idle provisioned capacity and avoiding the need for custom scripts to adjust capacity.

Exam trap

The trap here is that candidates may confuse 'reserved capacity' (a pricing discount for provisioned capacity) with a capacity mode, or assume that provisioned capacity set for peak traffic is cost-effective, ignoring the cost of idle periods.

How to eliminate wrong answers

Option B is wrong because reserved capacity is a pricing model for provisioned capacity, not a capacity mode; it requires you to commit to a specific throughput level and does not eliminate idle costs. Option C is wrong because setting provisioned capacity for peak traffic would result in paying for unused capacity during long idle periods, increasing costs and requiring manual or scripted adjustments. Option D is wrong because global tables replicate data across Regions for disaster recovery or low-latency access, not for managing capacity or cost optimization; they add complexity and cost without addressing idle capacity.

Practice this question →

MCQmedium

A test environment stores logs in S3. Logs are queried for 30 days, rarely accessed for one year, and then retained for compliance. What should reduce storage cost? The architecture review board prefers a managed AWS-native control.

A.Keep all logs in S3 Standard indefinitely

B.Move all logs immediately to S3 Glacier Deep Archive

C.S3 lifecycle policy that transitions objects to lower-cost storage classes over time

D.Use EBS snapshots for the logs

AnswerC

An S3 lifecycle policy automates object transitions between storage classes based on age, so you can keep recent logs in S3 Standard for fast querying and gradually move them to S3 Standard-IA, Glacier Flexible Retrieval, or Glacier Deep Archive as they age. For example, transition logs older than 30 days to Standard-IA, then to Glacier after 90 days, and finally expire them after a defined retention period. This matches storage cost to actual access patterns without manual intervention, and you retain the ability to query recent data instantly while old data is archived cheaply.

Why this answer

S3 Lifecycle policies allow you to automate the transition of objects from S3 Standard to lower-cost storage classes like S3 Standard-IA (after 30 days) and then to S3 Glacier Deep Archive (after one year) for long-term compliance. This matches the access pattern of frequent queries for 30 days, rare access for a year, and then retention-only, minimizing storage costs without manual intervention.

Exam trap

The trap here is that candidates may choose Option B (immediate move to Glacier Deep Archive) thinking it maximizes cost savings, but they overlook the requirement for 30 days of queryable access, which Glacier Deep Archive cannot support due to its multi-hour retrieval times.

How to eliminate wrong answers

Option A is wrong because keeping all logs in S3 Standard indefinitely incurs the highest storage cost, ignoring the infrequent access and long-term retention requirements. Option B is wrong because moving all logs immediately to S3 Glacier Deep Archive eliminates the ability to query them for 30 days, as retrieval times are hours and not suitable for active queries. Option D is wrong because EBS snapshots are designed for block-level backups of EC2 instances, not for storing log files; they are not a cost-effective or managed-native solution for S3 log storage and would introduce unnecessary complexity and cost.

Practice this question →

MCQeasy

A company runs a batch processing job on Amazon EC2 instances that runs for 4 hours every night. The job can be interrupted and restarted from a checkpoint. The company wants to minimize compute costs for this job. Which solution is MOST cost-effective?

A.Run the job on On-Demand Instances.

B.Use Dedicated Hosts for the instances.

C.Run the job on Spot Instances.

D.Purchase a 1-year All Upfront Reserved Instance for the instances.

AnswerC

Spot Instances offer the largest discounts on EC2 compute, often up to 90% off On-Demand, and are ideal for interruptible, stateless, or checkpointed workloads. Since the batch job runs for a short duration nightly and can resume from checkpoints, interruptions are tolerable. Using Spot Instances directly reduces compute costs substantially without requiring upfront commitments or long-term contracts, making it the most cost-effective option.

Why this answer

Spot Instances are the most cost-effective choice for interruptible, checkpointed batch workloads because they leverage spare EC2 capacity at a steep discount. The job runs for a short, predictable duration nightly and can resume after interruptions, which perfectly matches Spot's interruption model. Reserved Instances and Dedicated Hosts involve commitments or high fixed costs that are wasteful for intermittent usage, and On-Demand is more expensive than Spot.

Exam trap

The trap here is assuming that Reserved Instances always lower costs, when their benefit only materializes with steady, high-utilization workloads rather than short nightly batch jobs.

Practice this question →

MCQmedium

A risk simulation workload uses CloudWatch Logs heavily. Retaining all debug logs forever is increasing costs. What should be configured?

A.CloudWatch Logs retention policies per log group

B.AWS Config aggregation

C.CloudWatch detailed monitoring on all instances

D.Route 53 health checks

AnswerA

CloudWatch Logs retention policies per log group directly address the cost constraint by automatically expiring debug logs after a defined period, such as seven days. Retention is set at the log-group level, so each workload's logs can be tuned independently, eliminating indefinite storage charges without altering application logging behaviour.

Why this answer

CloudWatch Logs retention policies allow you to set per-log-group expiration rules (e.g., 30 days, 90 days) to automatically delete old log events, directly reducing storage costs for debug logs that are no longer needed. This is the most cost-effective and targeted solution for managing log lifecycle without affecting other monitoring or configuration services.

Exam trap

The trap here is that candidates may confuse log retention with monitoring frequency or configuration management, mistakenly thinking that reducing metric collection (detailed monitoring) or using Config aggregation will lower log storage costs.

How to eliminate wrong answers

Option B is wrong because AWS Config aggregation is used to collect and centrally view configuration and compliance data from multiple accounts/regions, not to manage log retention or storage costs. Option C is wrong because CloudWatch detailed monitoring on all instances increases metric frequency (1-minute intervals) and incurs additional costs, doing nothing to control log retention or delete old debug logs. Option D is wrong because Route 53 health checks monitor endpoint availability and DNS routing, not log storage or retention policies.

Practice this question →

Multi-Selecthard

A company runs a web application on AWS and wants to reduce costs. The application uses an Application Load Balancer (ALB) to distribute traffic to Amazon EC2 instances in an Auto Scaling group. The company observes that the EC2 instances are underutilized during off-peak hours. They want to optimize costs without affecting performance during peak hours. Which two actions should they take? (Choose two.)

Select 2 answers

A.Enable Application Load Balancer access logs and analyze them to identify cost-saving opportunities.

B.Configure the Auto Scaling group to use a mixed instances policy with a percentage of On-Demand and Spot Instances.

C.Use Spot Instances for all EC2 instances in the Auto Scaling group.

D.Implement scheduled scaling for the Auto Scaling group to reduce capacity during off-peak hours.

E.Reduce the size of the ALB to a smaller load balancer type.

AnswersB, D

A mixed instances policy allows you to combine On-Demand and Spot Instances, providing cost savings from Spot while maintaining a baseline of On-Demand for reliability. This approach can reduce costs without sacrificing performance, as the Auto Scaling group can maintain a minimum On-Demand capacity and use Spot for additional scalable capacity. It is a best practice for cost optimization in Auto Scaling groups.

Why this answer

Scheduled scaling reduces capacity during predictable off-peak periods, directly cutting EC2 costs. A mixed instances policy with On-Demand and Spot balances cost savings with reliability, ensuring performance during peaks. Together, these actions optimize costs without impacting performance.

Other options either do not directly save costs, introduce risk, or are not feasible.

Exam trap

The trap here is assuming that using Spot Instances for all capacity is a straightforward cost-saving measure, but it can jeopardize availability for a web application that must maintain performance; a mixed policy is safer and still cost-effective.

Practice this question →

MCQmedium

A team stores application logs in an S3 bucket. They keep logs for 18 months for compliance. Access patterns: logs are heavily accessed during the first 30 days, rarely accessed between days 31 and 180, and almost never accessed after day 180. They currently store everything in S3 Standard and want to reduce storage cost without violating the 18-month retention requirement. What should they implement?

A.Leave logs in S3 Standard for 18 months and add a tag for internal reporting

B.Create an S3 lifecycle policy to transition logs to Standard-IA after 30 days and to Glacier Deep Archive after 180 days

C.Immediately move all logs to Glacier Instant Retrieval and expire after 18 months

D.Enable versioning and rely on object lifecycle expiration to reduce costs; do not change storage classes

AnswerB

This is correct because it matches storage cost to actual access frequency: logs are typically accessed heavily in the first 30 days, so S3 Standard is appropriate, after which Standard-IA reduces storage cost while still allowing rapid access. At 180 days, the logs are unlikely to be needed for active operations, so Glacier Deep Archive provides the lowest-cost storage while still satisfying the 18-month retention requirement. The lifecycle transitions honor S3's minimum storage duration constraints (30 days and 180 days), so no early-deletion fees are incurred.

Why this answer

An S3 lifecycle policy can automatically transition objects from S3 Standard to S3 Standard-IA after 30 days (matching the heavy-access period) and then to S3 Glacier Deep Archive after 180 days (matching the near-zero-access period). This minimizes storage costs while retaining logs for the required 18 months, as Glacier Deep Archive offers the lowest storage cost for long-term archival data.

Exam trap

The trap here is that candidates may choose Option C, mistakenly thinking Glacier Instant Retrieval is the cheapest archival class, but it is actually more expensive than Glacier Deep Archive for data that is almost never accessed, and the immediate transition ignores the cost savings from using Standard-IA during the first 30 days.

How to eliminate wrong answers

Option A is wrong because leaving logs in S3 Standard for 18 months incurs the highest storage cost, and adding a tag does not reduce cost or change the storage class. Option C is wrong because immediately moving all logs to S3 Glacier Instant Retrieval is more expensive than using Standard-IA for the first 30 days and does not align with the access pattern; also, Glacier Instant Retrieval is designed for data accessed quarterly, not for data that is almost never accessed after 180 days. Option D is wrong because enabling versioning increases storage costs by retaining multiple versions of objects, and object lifecycle expiration alone does not change storage classes to lower-cost tiers; it only deletes objects, which would violate the 18-month retention requirement if set to expire earlier.

Practice this question →

Multi-Selectmedium

A company is migrating its on-premises workloads to AWS and wants to optimize costs. Which three strategies should the company implement to achieve a cost-optimized architecture? (Choose three.)

Select 3 answers

.Use Reserved Instances or Savings Plans for predictable workloads to reduce costs compared to On-Demand pricing.

.Provision additional EC2 instances to handle peak load at all times, ensuring maximum performance.

.Implement auto scaling to match capacity with demand, avoiding over-provisioning and reducing waste.

.Use Spot Instances for fault-tolerant, flexible workloads to achieve significant cost savings.

.Store all data in Amazon S3 Standard storage class to avoid any data retrieval costs.

.Deploy all resources in a single Availability Zone to minimize data transfer costs.

Why this answer

Reserved Instances or Savings Plans provide significant discounts (up to 72%) over On-Demand pricing for predictable workloads by committing to a specific usage term (1 or 3 years). This directly reduces compute costs for steady-state applications, making it a core cost-optimization strategy.

Exam trap

The trap here is that candidates often confuse 'maximizing performance' with 'cost optimization' and select the option to provision extra instances for peak load, failing to recognize that auto scaling and right-sizing are the correct approaches to balance cost and performance.

Practice this question →

MCQmedium

A media processing workflow uses CloudWatch Logs heavily. Retaining all debug logs forever is increasing costs. What should be configured?

A.Route 53 health checks

B.CloudWatch Logs retention policies per log group

C.CloudWatch detailed monitoring on all instances

D.AWS Config aggregation

AnswerB

CloudWatch Logs retention policies are applied per log group and define the exact number of days that log events are kept before they are automatically deleted. By default, logs are set to 'Never Expire,' so configuring a retention period, such as 30 or 90 days, directly reduces log storage costs and helps meet compliance guidelines. This is the correct approach because it specifically automates the deletion of older logs without any external processes.

Why this answer

CloudWatch Logs retention policies per log group allow you to set an expiration time (e.g., 30 days) after which log events are automatically deleted. This directly reduces storage costs by preventing debug logs from accumulating indefinitely, without affecting other monitoring or routing functions.

Exam trap

The trap here is that candidates may confuse cost optimization with monitoring frequency or compliance aggregation, but the question specifically targets log storage costs, which only retention policies directly address.

How to eliminate wrong answers

Option A is wrong because Route 53 health checks are used for DNS failover and endpoint monitoring, not for managing log retention or cost optimization. Option C is wrong because CloudWatch detailed monitoring increases metric frequency (1-minute intervals) and incurs additional costs, which does not address log retention or cost reduction. Option D is wrong because AWS Config aggregation centralizes configuration snapshots and compliance rules across accounts/regions, but it does not control log group retention or deletion.

Practice this question →

MCQmedium

A company runs an application on EC2 instances in private subnets. The instances must access Amazon S3, and the team currently routes all outbound traffic to the internet through a NAT Gateway. Monthly NAT Gateway charges increased significantly, even though the application only needs to call S3 (not access other public internet services). Which change will most directly reduce NAT Gateway charges while keeping S3 access working?

A.Create a gateway VPC endpoint for S3 and update the private route tables so S3 traffic uses the endpoint instead of the NAT Gateway.

B.Enable S3 Transfer Acceleration on the bucket to reduce the number of S3 calls that go through the NAT Gateway.

C.Switch the EC2 instances to public subnets so S3 calls can use direct internet routing without NAT.

D.Increase the NAT Gateway TCP idle timeout so fewer connections are billed separately for S3 traffic.

AnswerA

A gateway VPC endpoint for S3 keeps S3 traffic within the AWS network. After you add the S3 gateway endpoint and update the private subnet route tables for the S3 prefix list to target the endpoint, S3 API calls from the private subnets no longer traverse the NAT Gateway. This directly reduces both NAT Gateway per-hour charges and NAT data-processing charges associated with S3 traffic. If the application truly only needs S3, you can remove the NAT route for those S3 destinations and rely on the endpoint for S3 connectivity.

Why this answer

A gateway VPC endpoint for S3 allows instances in private subnets to access S3 over the AWS network without traversing the internet. By updating the private route tables to direct S3 traffic to the endpoint, the NAT Gateway is bypassed, eliminating the per-GB data processing charges and hourly NAT Gateway fees for that traffic. This directly reduces costs while maintaining secure, private access to S3.

Exam trap

The trap here is that candidates may think S3 Transfer Acceleration or increasing NAT Gateway timeouts will reduce costs, but they fail to recognize that a gateway VPC endpoint eliminates the NAT Gateway entirely for S3 traffic, directly addressing the cost issue without compromising security.

How to eliminate wrong answers

Option B is wrong because S3 Transfer Acceleration speeds up uploads over long distances using AWS edge locations, but it does not reduce the amount of traffic going through the NAT Gateway; it actually adds additional costs per GB transferred and still requires internet routing. Option C is wrong because moving EC2 instances to public subnets exposes them directly to the internet, violating the requirement for private subnets and introducing security risks; it also does not reduce NAT Gateway charges since the NAT Gateway is no longer used, but the question asks for a change that reduces NAT Gateway charges while keeping S3 access working, not for a security redesign. Option D is wrong because increasing the TCP idle timeout does not reduce NAT Gateway charges; it may actually increase costs by keeping connections open longer, and NAT Gateway billing is based on data processing and hourly usage, not per-connection billing.

Practice this question →

MCQeasy

A company stores millions of small, rarely accessed backup objects in Amazon S3 Standard. The objects must remain immediately retrievable within milliseconds and be retained for at least five years, but the company wants to reduce storage cost. Which action should the company take?

A.Convert the bucket to S3 One Zone-IA to save on storage and retrieval.

B.Add a lifecycle rule to transition the objects to S3 Standard-IA after 30 days.

C.Add a lifecycle rule to transition the objects to S3 Glacier Deep Archive after 30 days.

D.Enable S3 Intelligent-Tiering and rely on it to move objects automatically.

AnswerB

S3 Standard-IA offers lower per-gigabyte storage pricing than S3 Standard while still providing millisecond latency and immediate access. It is intended for long-lived, infrequently accessed data, so it fits the requirement to keep objects instantly retrievable for five years while cutting storage cost. A lifecycle rule automates the transition.

Why this answer

S3 Standard-IA keeps objects immediately accessible with millisecond latency while charging less per gigabyte than S3 Standard, which matches the requirement to retain rarely accessed backups for five years without retrieval delays. A lifecycle rule can transition the objects automatically after 30 days. Glacier Deep Archive is cheaper but too slow, Intelligent-Tiering adds monitoring fees on small objects, and One Zone-IA sacrifices AZ resilience.

Exam trap

The trap here is chasing the absolute cheapest storage class and overlooking that archival tiers cannot deliver millisecond retrieval.

Practice this question →

MCQhard

A SaaS provider runs a multi-tenant application on Amazon RDS for PostgreSQL. The database is 2 TB and experiences steady read-heavy traffic during business hours. The provider wants to offload read traffic to reduce load on the primary instance and lower cost compared to scaling up the primary. The application can tolerate slightly stale reads for reporting queries. Which solution is MOST cost-effective?

A.Enable Multi-AZ deployment and route reporting queries to the standby instance.

B.Migrate the database to Amazon DynamoDB with on-demand capacity mode.

C.Create a read replica and route reporting queries to it.

D.Increase the size of the primary RDS instance to a larger instance class.

AnswerC

A read replica is a separate RDS instance that receives asynchronous replication from the primary. It offloads read-only reporting queries, reducing load on the primary and allowing the primary to remain at its current size. Because the application tolerates slightly stale reads, asynchronous replication lag is acceptable. The read replica can be sized independently and stopped or scaled down when not needed, making it more cost-effective than scaling up the primary.

Why this answer

A read replica offloads read-only reporting queries from the primary instance, reducing contention and allowing the primary to remain appropriately sized. Because asynchronous replication introduces slight lag, the application's tolerance for stale reads makes this acceptable. This approach is more cost-effective than scaling up the primary or enabling Multi-AZ, which does not provide readable standby capacity.

Exam trap

The trap here is assuming that a Multi-AZ standby instance can be used to serve read traffic, when it is inaccessible for normal operations.

Practice this question →

MCQmedium

A marketing site stores logs in S3. Logs are queried for 30 days, rarely accessed for one year, and then retained for compliance. What should reduce storage cost?

A.S3 lifecycle policy that transitions objects to lower-cost storage classes over time

B.Keep all logs in S3 Standard indefinitely

C.Use EBS snapshots for the logs

D.Move all logs immediately to S3 Glacier Deep Archive

AnswerA

An S3 lifecycle policy automates object transitions based on age, aligning storage cost with actual access patterns. Since logs are queried only for 30 days, rules can move older logs to S3 Standard-IA after 30 days, then to S3 Glacier Instant Retrieval or S3 Glacier Flexible Retrieval, and eventually to S3 Glacier Deep Archive for archival. This approach minimizes storage cost while keeping recent logs immediately accessible, and it requires no manual intervention. Lifecycle rules are evaluated daily per object, making them the ideal cost optimization mechanism for time-decaying log data.

Why this answer

An S3 Lifecycle policy automates the transition of objects from S3 Standard (frequently accessed) to lower-cost storage classes like S3 Standard-IA (infrequent access) after 30 days, then to S3 Glacier Deep Archive for long-term compliance retention. This matches the access pattern: frequent queries for 30 days, rare access for a year, then archival storage, minimizing cost without manual intervention.

Exam trap

The trap here is that candidates might choose immediate archiving (Option D) to minimize storage cost, overlooking the 30-day query requirement and the retrieval latency/cost of Glacier Deep Archive, or mistakenly think EBS snapshots (Option C) are a valid alternative for log storage.

How to eliminate wrong answers

Option B is wrong because keeping all logs in S3 Standard indefinitely incurs the highest per-GB storage cost, ignoring the significant cost savings from transitioning to lower-cost tiers for rarely accessed and archived data. Option C is wrong because EBS snapshots are block-level backups for EC2 volumes, not designed for object storage of logs; using them would require an EC2 instance to manage the logs, adding compute and management overhead. Option D is wrong because immediately moving all logs to S3 Glacier Deep Archive would incur retrieval costs and delays (hours) for the 30-day query period, violating the requirement for frequent queries during that time.

Practice this question →

MCQmedium

A marketing team runs a report-generation process that must execute once per day at 02:00 UTC. It usually completes in 10315 minutes, but sometimes takes up to 45 minutes due to varying data volumes. They currently run the workload on an EC2 instance that is always on, which wastes money during off-hours. The team wants to minimize operational overhead and pay mainly for actual execution time. What is the best architecture choice?

A.Use a scheduled Amazon EC2 Auto Scaling group that keeps a minimum of one instance running at all times.

B.Use an EventBridge schedule to run the report as an Amazon ECS task on AWS Fargate and write results to S3.

C.Use AWS Lambda triggered by an EventBridge schedule at 02:00 UTC and write results to S3.

D.Use an EMR cluster provisioned daily with manual teardown to ensure the instance is always available before 02:00.

AnswerB

Fargate runs the ECS task only when EventBridge triggers the schedule, so billing covers actual task runtime rather than idle hours. It removes server patching and capacity management, and the 45-minute maximum fits comfortably within a single scheduled task run.

Why this answer

Amazon ECS on AWS Fargate is the best choice because it eliminates the need to manage servers, scales automatically, and charges only for the vCPU and memory resources consumed during task execution. The EventBridge schedule triggers the Fargate task at 02:00 UTC, and the report is written to S3, which provides durable, cost-effective storage. This architecture minimizes operational overhead and cost by avoiding an always-on EC2 instance.

Exam trap

The trap here is that candidates may choose AWS Lambda without considering its 15-minute execution timeout, which cannot handle the 45-minute maximum runtime of this report-generation process.

Why the other options are wrong

This option keeps an instance running at all times, which wastes money during off-hours and does not minimize operational overhead or pay mainly for actual execution time.

AWS Lambda has a maximum execution timeout of 15 minutes, but the report-generation process can take up to 45 minutes, so Lambda cannot handle the entire workload.

Provisioning an EMR cluster daily with manual teardown introduces significant operational overhead, which contradicts the requirement to minimize operational overhead. Additionally, EMR is designed for big data processing (e.g., Spark, Hive) and is overkill for a simple report-generation task, leading to higher costs and complexity.

Practice this question →

MCQeasy

You need to run batch jobs on EC2. The jobs can tolerate interruptions: if an instance is terminated, the job can restart from checkpoints. To reduce compute cost as much as possible, what is the best choice?

A.EC2 On-Demand Instances to avoid interruptions

B.EC2 Spot Instances with checkpoint-based interruption handling

C.Savings Plans to guarantee capacity for the entire year

D.Reserved Instances with no interruption handling

AnswerB

Spot Instances are priced lower because AWS can reclaim capacity. When your workload can be interrupted and later restarted from checkpoints, the interruption model is compatible with Spot, making it the most cost-optimized option among the choices.

Why this answer

Spot Instances offer significant cost savings (up to 90% compared to On-Demand) but can be reclaimed by AWS with a two-minute warning. Since the batch jobs can tolerate interruptions and restart from checkpoints, Spot Instances are the most cost-effective choice. This aligns with the requirement to reduce compute cost as much as possible while handling interruptions gracefully.

Exam trap

The trap here is that candidates often choose On-Demand or Reserved Instances because they fear interruptions, but the question explicitly states the jobs can tolerate interruptions, so the most cost-effective option is Spot Instances, not a more expensive but stable alternative.

Why the other options are wrong

On-Demand Instances are more expensive than Spot Instances and do not offer cost savings. Since the job can tolerate interruptions via checkpoints, Spot Instances provide the lowest cost.

Savings Plans do not provide interruption handling or cost reduction for batch jobs that can tolerate interruptions; they offer discounted rates in exchange for a commitment but do not address the need for the lowest cost with interruption tolerance.

Reserved Instances require a 1- or 3-year commitment and do not inherently handle interruptions; they are designed for steady-state workloads, not fault-tolerant batch jobs where cost reduction is the priority.

Practice this question →

MCQeasy

A company stores several petabytes of archived regulatory records in Amazon S3. The records must be retained for seven years and are almost never accessed, but if an auditor requests a record, it must be retrievable within 12 hours. The company wants the lowest storage cost that still meets the retrieval requirement. Which S3 storage class should the solutions architect choose?

A.S3 Glacier Deep Archive

B.S3 Standard-Infrequent Access

C.S3 Glacier Flexible Retrieval

D.S3 One Zone-Infrequent Access

AnswerA

S3 Glacier Deep Archive is the lowest-cost S3 storage class and is designed for long-term retention of data accessed rarely, with a standard retrieval time of 12 hours and a bulk retrieval option of 48 hours. Because the auditor requirement allows up to 12 hours, Deep Archive satisfies the retrieval window while minimizing storage cost for petabytes held over seven years.

Why this answer

The lowest-cost storage class that still returns data within the allowed 12-hour window is S3 Glacier Deep Archive, whose standard retrieval completes within 12 hours. Glacier Flexible Retrieval and the Infrequent Access classes cost more per gigabyte, and paying for faster retrieval or millisecond access provides no benefit when the retrieval requirement is so permissive.

Exam trap

The trap here is choosing a faster retrieval class out of caution, when the stated 12-hour window is exactly what Glacier Deep Archive's standard retrieval is designed to satisfy.

Practice this question →

MCQmedium

A test environment runs on x86 EC2 instances and uses open-source software with no architecture-specific licensing restriction. What should be evaluated to reduce compute cost? The design must avoid adding custom operational scripts.

A.Cross-Region data replication for all data

B.AWS Graviton-based instances after performance testing

C.io2 Block Express volumes for all instances

D.Dedicated Hosts by default

AnswerB

AWS Graviton processors use Arm64 architecture, delivering better price-performance than comparable x86 instances. Since the software is open-source with no architecture-specific licensing restriction, and no custom operational scripts are added, migrating after performance testing satisfies the cost-reduction requirement without introducing operational overhead.

Why this answer

AWS Graviton-based instances (ARM architecture) offer up to 40% better price-performance compared to x86 instances for many workloads. Since the environment uses open-source software with no architecture-specific licensing restrictions, migrating to Graviton after performance testing can significantly reduce compute costs without requiring custom operational scripts, as AWS provides native support for ARM-based instances.

Exam trap

The trap here is that candidates may confuse cost optimization with performance improvement or licensing requirements, leading them to select Dedicated Hosts or high-performance storage options that actually increase costs.

How to eliminate wrong answers

Option A is wrong because cross-region data replication increases data transfer and storage costs, and it does not directly address compute cost reduction. Option C is wrong because io2 Block Express volumes are high-performance, high-cost EBS volumes designed for I/O-intensive workloads, not for reducing compute costs, and they would increase storage costs unnecessarily. Option D is wrong because Dedicated Hosts incur additional per-host charges and are used for licensing or compliance requirements, not for cost optimization; they would increase compute costs rather than reduce them.

Practice this question →

100

MCQeasy

An S3 bucket stores application logs. After 30 days, the team rarely accesses the logs, but compliance requires keeping them for 18 months. Which setup most directly reduces storage cost while maintaining compliance?

A.Configure an S3 Lifecycle policy to transition objects to a colder storage class after 30 days and expire (delete) them after 18 months.

B.Enable S3 Versioning and rely on deleting old versions after 30 days to reduce storage costs while keeping the latest data.

C.Move the bucket to a different AWS region farther from the users to reduce the likelihood of accidental reads and thereby lower storage costs.

D.Switch all objects to S3 Glacier Instant Retrieval immediately, regardless of object age, to minimize storage charges.

AnswerA

This lifecycle policy is the right approach because it automatically transitions 30-day-old log objects to a lower-cost storage class — such as S3 Standard-IA or S3 Glacier Instant Retrieval — which directly matches the noted shift in access pattern after the first 30 days. The separate expiration action after 18 months enforces the compliance requirement to retain logs for exactly that period and then delete them, preventing both premature deletion and runaway storage growth. Lifecycle transitions are managed by S3, so the team does not need custom code to move or expire objects.

Why this answer

S3 Lifecycle policies allow you to automatically transition objects to cheaper storage classes (e.g., S3 Standard-IA or S3 Glacier Deep Archive) after 30 days, reducing storage costs for rarely accessed logs. The policy also sets an expiration action to delete objects after 18 months, meeting the compliance requirement without manual intervention.

Exam trap

The trap here is that candidates may think moving to a different region or using versioning reduces costs, but the core concept is that S3 Lifecycle policies directly automate cost optimization by transitioning to colder storage classes and expiring data, which is the most direct and compliant approach.

How to eliminate wrong answers

Option B is wrong because enabling S3 Versioning and deleting old versions does not address the need to keep logs for 18 months; it only manages versions, not the primary objects, and can increase costs due to storing multiple versions. Option C is wrong because moving the bucket to a different region does not reduce storage costs; it may increase data transfer costs and does not change the storage class or lifecycle management. Option D is wrong because switching all objects to S3 Glacier Instant Retrieval immediately, regardless of age, would likely increase costs for frequently accessed logs in the first 30 days, as this storage class has higher retrieval costs and is not optimal for data that is still being accessed.

Practice this question →

101

Multi-Selectmedium

A company is running a production web application on Amazon EC2 instances behind an Application Load Balancer (ALB). The workload has predictable traffic spikes during business hours and low traffic at night. The current architecture uses On-Demand EC2 instances, leading to high costs. The company wants to reduce costs without sacrificing availability or performance. Which three of the following strategies would help achieve this goal? (Choose three.)

Select 3 answers

.Purchase Reserved Instances for the baseline capacity that runs 24/7.

.Add Spot Instances for the entire workload during peak hours.

.Use Auto Scaling with a mixed instances policy that includes On-Demand and Spot Instances.

.Migrate to AWS Lambda for all web application traffic.

.Implement a scheduled scaling action to increase capacity before business hours and decrease after.

.Consolidate all instances into a single larger instance to reduce overhead.

Why this answer

Purchasing Reserved Instances for the baseline 24/7 capacity provides a significant discount (up to 72%) compared to On-Demand pricing, directly reducing costs for the always-running portion of the workload. This strategy is correct because it matches the predictable, steady-state traffic component without sacrificing availability or performance.

Exam trap

The trap here is that candidates may think Spot Instances can be used for the entire workload during peak hours, but they overlook the interruption risk and the requirement for the workload to be fault-tolerant, which a production web application behind an ALB typically is not without careful design.

Practice this question →

102

MCQhard

A media processing workflow in private subnets downloads large amounts of data from S3 through a NAT gateway. NAT data processing charges are high. What should the architect use to reduce cost? The design must avoid adding custom operational scripts.

A.S3 Object Lambda

B.AWS Shield Advanced

C.Gateway VPC endpoint for Amazon S3

D.A larger NAT gateway

AnswerC

A gateway VPC endpoint for Amazon S3 is a free resource that you attach to a subnet's route table, enabling instances to reach S3 via private IP addresses. Traffic to S3 through a gateway endpoint does not traverse an internet gateway or NAT gateway, thereby eliminating the NAT data processing charge. It is the recommended and most cost-effective way to access S3 from private subnets when no internet connectivity is required.

Why this answer

A Gateway VPC endpoint for Amazon S3 allows instances in private subnets to access S3 directly over the AWS network without traversing a NAT gateway. This eliminates NAT data processing charges because traffic stays within the AWS backbone, reducing costs significantly for large data downloads.

Exam trap

The trap here is that candidates often confuse Gateway VPC endpoints with Interface VPC endpoints, assuming both incur costs, or mistakenly think NAT gateways are required for all private subnet outbound traffic, missing the S3-specific optimization.

How to eliminate wrong answers

Option A is wrong because S3 Object Lambda is used to transform data on the fly during retrieval, not to reduce data transfer costs or bypass NAT gateways. Option B is wrong because AWS Shield Advanced provides DDoS protection, not cost optimization for S3 data transfer. Option D is wrong because a larger NAT gateway would increase, not reduce, costs due to higher hourly and data processing charges.

Practice this question →

103

MCQmedium

A dev sandbox has unpredictable DynamoDB traffic with long idle periods and occasional spikes. Which capacity mode should minimize operational overhead and avoid paying for idle provisioned capacity?

A.Reserved capacity for maximum daily traffic

B.Provisioned capacity set for peak traffic

C.DynamoDB on-demand capacity mode

D.Global tables in every Region

AnswerC

DynamoDB on-demand capacity mode charges you only for the actual read and write requests your application makes, with no minimum capacity and no need to forecast traffic patterns. It instantly accommodates spikes from unpredictable developer workloads, and when the table is idle, you pay nothing beyond storage costs. This directly solves the problem of paying for unused capacity during long idle periods, which is exactly why on-demand is the correct choice for this dev sandbox.

Why this answer

DynamoDB on-demand capacity mode (Option C) is ideal for unpredictable workloads with long idle periods and occasional spikes because it automatically scales to handle traffic without requiring any capacity planning. You pay only for the reads and writes you actually perform, eliminating the cost of idle provisioned capacity and the operational overhead of managing scaling.

Exam trap

The trap here is that candidates confuse 'reserved capacity' (an EC2/RDS concept) with DynamoDB capacity modes, or think that provisioned capacity with auto-scaling is always cheaper, ignoring the cost of idle capacity during long idle periods.

How to eliminate wrong answers

Option A is wrong because Reserved capacity is not a DynamoDB capacity mode; it is a pricing model for EC2 or RDS, and DynamoDB does not offer reserved capacity. Option B is wrong because Provisioned capacity set for peak traffic would incur costs for idle capacity during long idle periods, and you would still need to manually adjust or use auto-scaling to handle spikes, increasing operational overhead. Option D is wrong because Global tables are a replication feature for multi-Region active-active setups, not a capacity mode, and they do not address cost or overhead from idle capacity or traffic spikes.

Practice this question →

104

MCQmedium

A production internal reporting portal runs continuously on EC2 with predictable usage for the next three years. The team wants a discount while retaining some instance-family flexibility. What should they buy? The design must avoid adding custom operational scripts.

A.Spot Instances only

B.Dedicated Instances

C.Compute Savings Plan

D.S3 Intelligent-Tiering

AnswerC

A Compute Savings Plan offers significant discounted rates in exchange for a commitment to a consistent amount of compute usage (e.g., $/hour) over a 1- or 3-year term. It automatically covers any EC2 instance family, size, or Region, as well as Fargate and Lambda, providing flexibility if the reporting portal's instance mix changes over time. This makes it the ideal solution for a continuously running production workload because it delivers up to a 66% discount versus On-Demand without locking you into specific instance specs.

Why this answer

Compute Savings Plans offer the lowest prices on EC2 instance usage (up to 66% off On-Demand) in exchange for a 1- or 3-year commitment, while allowing flexibility across instance families, sizes, OS, and regions. This matches the requirement for a discount on predictable, continuous usage without locking into a specific instance type, and requires no custom scripts.

Exam trap

The trap here is that candidates confuse Savings Plans with Reserved Instances, assuming they require instance-family lock-in, or they incorrectly apply storage services (S3 Intelligent-Tiering) to compute cost optimization.

How to eliminate wrong answers

Option A is wrong because Spot Instances are not suitable for a continuously running production portal; they can be interrupted with a 2-minute warning, making them unreliable for steady-state workloads. Option B is wrong because Dedicated Instances provide physical isolation at a higher cost and do not offer a discount mechanism; they are for compliance or licensing needs, not cost savings. Option D is wrong because S3 Intelligent-Tiering is an object storage class for data with changing access patterns, not applicable to EC2 compute instances.

Practice this question →

105

MCQmedium

A latency-sensitive API is implemented with AWS Lambda. The team enabled provisioned concurrency to avoid cold starts, setting provisioned concurrency to 50 because marketing campaigns occasionally cause spikes. However, during most weekdays the API receives little traffic (near zero), and the team is seeing high monthly Lambda costs from idle provisioned capacity. What is the best cost-optimized strategy that still meets the requirement of fast initial responses during traffic spikes?

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

B.Use Application Auto Scaling scheduled actions to increase provisioned concurrency on the Lambda alias before campaign windows and reduce it to a minimal baseline afterward.

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

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

AnswerB

Application Auto Scaling scheduled actions let you define time-based policies on a Lambda alias, so provisioned concurrency is raised to a high value just before the campaign starts and lowered to a minimal baseline once it ends. During the campaign, requests are served by pre-initialized execution environments, eliminating the cold-start latency that would otherwise be noticeable. Because provisioned concurrency is billed while allocated even when idle, the schedule ensures you only pay for warm capacity during the actual spike window, not during all other hours.

Why this answer

It uses Application Auto Scaling scheduled actions to dynamically adjust provisioned concurrency, scaling up to 50 before marketing campaigns and reducing to a minimal baseline (e.g., 1-5) during low-traffic weekdays. This eliminates idle capacity costs while ensuring fast initial responses during spikes, as provisioned concurrency keeps Lambda environments warm and ready to handle requests without cold starts.

Exam trap

The trap here is that candidates may assume provisioned concurrency must be set to a static high value to handle spikes, ignoring AWS's native Auto Scaling capabilities that can dynamically adjust capacity based on schedule or metrics, thus missing the cost-optimization aspect of the question.

How to eliminate wrong answers

Option A is wrong because increasing provisioned concurrency to 100 would double the idle capacity cost during low-traffic periods, exacerbating the cost issue without addressing the root problem of over-provisioning. Option C is wrong because turning off provisioned concurrency permanently would cause cold starts on every invocation during traffic spikes, violating the latency-sensitive requirement; client-side retries do not mask the initial latency of a cold start (typically 1-5 seconds for Lambda). Option D is wrong because replacing Lambda with a single always-on EC2 instance sized for peak demand would incur higher costs (24/7 compute) and eliminate the serverless benefits of automatic scaling and pay-per-use, while still risking performance degradation if the single instance is overwhelmed.

Practice this question →

106

Multi-Selecthard

A product catalog system uses a relational database for orders and a simple key-value profile store for shopping carts. Traffic is unpredictable, and the company wants to avoid paying for large idle database instances. Which two choices are best? Select two.

Select 2 answers

A.Use Aurora Serverless v2 for the relational order system.

B.Use DynamoDB on-demand capacity for the shopping-cart profile store.

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

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

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

AnswersA, B

Aurora Serverless v2 scales capacity automatically in fine-grained increments based on actual load, so the relational order system pays only for consumed capacity during unpredictable traffic. This directly satisfies the requirement to avoid paying for large idle database instances without application rewrites.

Why this answer

A is correct because Aurora Serverless v2 automatically scales database capacity in fine-grained ACUs up and down based on actual load, so the relational order system only consumes (and bills for) the capacity it needs during unpredictable traffic, avoiding large idle provisioned instances. B is correct because DynamoDB on-demand capacity mode charges per request and instantly accommodates unpredictable traffic spikes without provisioning or managing capacity, which fits the key-value shopping-cart profile store. C is wrong because large provisioned RDS instances plus read replicas still pay for idle capacity and read replicas do not address write-side traffic variability.

D is wrong because DynamoDB provisioned capacity with a fixed minimum requires capacity planning and either throttles or wastes money under unpredictable traffic. E is wrong because replacing the relational order system with a wide-column store does not reduce SQL licensing (Aurora is not licensed per-core like commercial engines) and abandons the relational model the orders workload requires.

Exam trap

The trap here is that candidates may think provisioned capacity with a minimum is acceptable for unpredictable traffic, but the question explicitly requires avoiding paying for idle capacity, so on-demand or serverless options are the only correct choices.

Practice this question →

107

Multi-Selectmedium

A company runs a web application on Amazon EC2 instances in multiple Availability Zones. The application uses an Application Load Balancer and an Auto Scaling group. The company wants to reduce cost while maintaining high availability. The workload is steady and predictable, and the instances run continuously. Which two actions will reduce cost? (Choose two.)

Select 2 answers

A.Move the application to a single Availability Zone to reduce data transfer charges.

B.Right-size the instances based on CloudWatch metrics to eliminate over-provisioned capacity.

C.Enable termination protection on all instances to prevent accidental deletion.

D.Replace the Application Load Balancer with a Network Load Balancer to reduce hourly charges.

E.Purchase Compute Savings Plans to cover the steady-state usage.

AnswersB, E

Right-sizing analyzes utilization metrics such as CPU, memory, and network to identify instances that are larger than needed. Moving to a smaller instance type reduces the hourly rate while still meeting performance requirements. For a steady workload, this is a reliable way to cut cost without sacrificing availability, provided the new size is validated under load.

Why this answer

For a steady, continuously running workload, the two most effective cost levers are purchasing commitments and right-sizing. Compute Savings Plans reduce the effective rate for the baseline usage, and right-sizing removes capacity that is not needed. High-availability features and load balancer choices should be preserved unless they are proven to be the primary cost driver.

Exam trap

The trap here is treating availability features or load balancer types as cost optimizations, when the real savings for steady workloads come from commitments and right-sizing.

Practice this question →

108

MCQmedium

A static web application uses CloudFront with an S3 origin for assets (JavaScript, CSS, images). After deploying a new frontend build, the CloudFront cache hit ratio dropped significantly because the S3 origin receives many repeated requests for the same assets. The team notices that requests now include the Authorization header in asset requests. Which change is most likely to restore cache efficiency and reduce origin request costs?

A.Keep the Authorization header but increase the cache TTL to 1 year to reduce revalidation frequency.

B.Update the CloudFront cache policy so that Authorization is excluded from the cache key for static asset paths.

C.Remove CloudFront and serve assets directly from the S3 website endpoint to reduce CloudFront charges.

D.Switch the S3 origin from private access to public access so CloudFront can cache assets more effectively.

AnswerB

When Authorization is part of the cache key, each unique token can create separate cache entries, lowering the cache hit ratio and increasing origin requests. Excluding Authorization from the cache key (and typically from the origin request policy for static assets) allows caching to be based on the URL path/query string, improving hit ratio and reducing S3 origin load.

Why this answer

The drop in cache hit ratio is caused by the Authorization header being included in asset requests, which makes each request unique from CloudFront's perspective, preventing cache reuse. By updating the CloudFront cache policy to exclude the Authorization header from the cache key for static asset paths, CloudFront can treat identical asset requests as cache hits, restoring cache efficiency and reducing origin load.

Exam trap

The trap here is that candidates may assume increasing TTL or making the origin public solves caching issues, but the real problem is the cache key variation caused by the Authorization header, which must be explicitly excluded from the cache policy for static content.

How to eliminate wrong answers

Option A is wrong because increasing the TTL to 1 year does not address the root cause—the Authorization header still varies the cache key, so requests will continue to miss cache and revalidate unnecessarily. Option C is wrong because removing CloudFront and serving assets directly from the S3 website endpoint would eliminate caching entirely, increasing origin request costs and latency, not reducing them. Option D is wrong because switching the S3 origin from private to public access does not affect CloudFront's ability to cache; the cache key issue with the Authorization header remains, and public access introduces security risks without solving the problem.

Practice this question →

109

MCQmedium

A dev sandbox has unpredictable DynamoDB traffic with long idle periods and occasional spikes. Which capacity mode should minimize operational overhead and avoid paying for idle provisioned capacity? The design must avoid adding custom operational scripts.

A.Reserved capacity for maximum daily traffic

B.Provisioned capacity set for peak traffic

C.DynamoDB on-demand capacity mode

D.Global tables in every Region

AnswerC

On-demand capacity mode bills per actual read and write request, using per-million request units, and automatically scales from zero to whatever the workload demands without capacity planning or throttling caused by forecasting errors. Idle sessions cost nothing beyond storage, and sudden traffic bursts are absorbed without needing to adjust provisioned units. For a sandbox with unpredictable traffic and long idle phases, on-demand avoids overpaying for unused capacity while providing exactly the elasticity this workload requires.

Why this answer

DynamoDB on-demand capacity mode is ideal for unpredictable workloads with long idle periods and occasional spikes because it automatically scales to handle traffic without requiring any capacity planning or provisioning. You pay only for the reads and writes you actually perform, eliminating the cost of idle provisioned capacity and the operational overhead of managing scaling scripts or alarms.

Exam trap

The trap here is that candidates may confuse 'reserved capacity' with DynamoDB's reserved capacity pricing model (which is actually a commitment discount for provisioned mode) or assume that provisioned capacity with auto-scaling is sufficient, but auto-scaling still requires setting minimum and maximum values and can incur costs for idle provisioned capacity during low-traffic periods.

How to eliminate wrong answers

Option A is wrong because Reserved capacity is not a DynamoDB pricing model; it applies to services like EC2 RIs or Aurora, and even if interpreted as provisioned capacity, it would require estimating peak traffic and paying for idle time. Option B is wrong because Provisioned capacity set for peak traffic would incur costs for unused capacity during idle periods and would require manual scaling or custom scripts to adjust capacity, violating the requirement to avoid custom operational scripts. Option D is wrong because Global tables replicate data across multiple Regions for disaster recovery or low-latency global access, which adds complexity and cost without addressing the core issue of unpredictable traffic and idle capacity waste.

Practice this question →

110

MCQmedium

A company serves versioned images from S3 through CloudFront. After a release, CloudFront origin fetches increased sharply and the monthly CloudFront bill went up. They reviewed CloudFront logs and found that many requests include a query string parameter `reqId` that is unique per request (for example, `...?v=2026-04-01&reqId=...`). The team currently forwards all query strings to the cache key. What change is most likely to reduce origin fetches and cost while keeping the versioned images correct?

A.Update the CloudFront cache policy to ignore `reqId` and include only the stable `v` query string parameter in the cache key.

B.Lower the CloudFront minimum TTL to 0 seconds so cached objects revalidate more often, reducing origin fetch volume.

C.Set the S3 bucket to use compression and enable S3 Transfer Acceleration to reduce origin fetch charges.

D.Disable forwarding of the query string to the origin, but keep using the full query string (including `reqId`) in the cache key.

AnswerA

Because `reqId` is unique per request, including it in the cache key prevents cache reuse (each request maps to a different cache entry), resulting in frequent origin fetches. Excluding `reqId` and keeping only `v` allows many requests for the same version to share cached objects, reducing origin traffic and cost while preserving correct version behavior.

Why this answer

The `reqId` query string parameter is unique per request, which forces CloudFront to treat each request as a distinct cache object when all query strings are forwarded to the cache key. By configuring the cache policy to include only the stable `v` parameter (the version identifier) and ignore `reqId`, CloudFront can serve cached responses for all requests with the same `v` value, drastically reducing origin fetches and lowering costs. This approach preserves correct versioned image delivery because the `v` parameter still differentiates between image versions.

Exam trap

The trap here is that candidates may think forwarding all query strings is harmless or that lowering TTL helps reduce origin fetches, but the real issue is cache key fragmentation caused by unique parameters like `reqId`.

How to eliminate wrong answers

Option B is wrong because lowering the minimum TTL to 0 seconds would cause CloudFront to revalidate cached objects more frequently, increasing origin fetches and costs, which is the opposite of the desired outcome. Option C is wrong because enabling S3 Transfer Acceleration and compression reduces data transfer latency and size but does not address the root cause of excessive origin fetches caused by unique query strings in the cache key. Option D is wrong because disabling forwarding of the query string to the origin while keeping the full query string (including `reqId`) in the cache key would still create unique cache objects for each `reqId`, failing to reduce origin fetches.

Practice this question →

111

MCQmedium

A media processing workflow uses CloudWatch Logs heavily. Retaining all debug logs forever is increasing costs. What should be configured? The design must avoid adding custom operational scripts.

A.Route 53 health checks

B.CloudWatch Logs retention policies per log group

C.CloudWatch detailed monitoring on all instances

D.AWS Config aggregation

AnswerB

CloudWatch Logs retention policies are configured per log group and automatically delete log events older than the specified interval (e.g., 30 days to 10 years). For a media processing workflow generating heavy log traffic, setting an appropriate retention period directly reduces storage cost and ensures compliance with data-retention requirements. Without a policy, logs default to "Never Expire" and accrue cost indefinitely.

Why this answer

CloudWatch Logs retention policies allow you to set a time-based expiration (e.g., 30 days) on log groups, automatically deleting old log events. This directly reduces storage costs without requiring custom scripts, as the retention policy is a native CloudWatch Logs feature configured per log group.

Exam trap

The trap here is that candidates may confuse CloudWatch Logs retention policies with CloudWatch metrics retention or detailed monitoring, thinking that reducing metric granularity will lower log storage costs, when in fact log retention is a separate, per-log-group setting.

How to eliminate wrong answers

Option A is wrong because Route 53 health checks monitor endpoint availability and DNS routing, not log retention or cost optimization. Option C is wrong because CloudWatch detailed monitoring increases metric frequency (1-minute intervals) and incurs additional costs, but does not manage log retention or deletion. Option D is wrong because AWS Config aggregation centralizes resource configuration snapshots and compliance rules, not log lifecycle management.

Practice this question →

112

MCQmedium

A risk simulation workload uses CloudWatch Logs heavily. Retaining all debug logs forever is increasing costs. What should be configured? The design must avoid adding custom operational scripts.

A.CloudWatch Logs retention policies per log group

B.AWS Config aggregation

C.CloudWatch detailed monitoring on all instances

D.Route 53 health checks

AnswerA

By default, CloudWatch Logs retains log events indefinitely, so a risk simulation workload generating heavy log volume will accumulate storage costs without limit. Configuring a retention policy per log group—such as 30 or 90 days—automatically expires and deletes log events after the specified period, controlling costs and meeting data lifecycle requirements. This is the correct, direct way to manage log storage for CloudWatch Logs.

Why this answer

CloudWatch Logs retention policies allow you to set per-log-group expiration rules (e.g., 30 days, 90 days) to automatically delete old log events, directly reducing storage costs without custom scripts. Since the workload uses CloudWatch Logs heavily and retains debug logs forever, configuring a retention policy on each log group is the simplest, most cost-effective solution that requires no operational overhead.

Exam trap

The trap here is that candidates may confuse cost optimization features (like retention policies) with monitoring or compliance tools (like AWS Config or detailed monitoring), assuming that any AWS service that 'monitors' can also reduce log storage costs.

How to eliminate wrong answers

Option B is wrong because AWS Config aggregation is used to consolidate configuration and compliance data from multiple accounts/regions, not to manage log retention or cost. Option C is wrong because CloudWatch detailed monitoring on EC2 instances collects metrics at 1-minute intervals (vs. 5-minute basic), which increases costs and does not affect log retention or deletion. Option D is wrong because Route 53 health checks monitor endpoint availability and DNS routing, not log storage or lifecycle management.

Practice this question →

113

Multi-Selecthard

A log archive has old unattached EBS volumes and many stale snapshots. Which two actions reduce storage cost without affecting running instances?

Select 2 answers

A.Stop all EC2 instances in the account

B.Disable CloudTrail logging

C.Delete unattached EBS volumes after verifying they are no longer needed

D.Apply snapshot lifecycle policies to expire obsolete snapshots

AnswersC, D

Unattached EBS volumes continue to be billed for their provisioned capacity and IOPS even when no instance is using them; deletion is the only way to eliminate those charges. Before deleting, you must verify that the volume is not needed for data recovery, future instance launches, or as a source for new snapshots. In a log archive scenario, these volumes are prime candidates for deletion because they represent pure waste, and this action directly addresses the cost of the unattached volumes listed in the scenario.

Why this answer

Unattached EBS volumes incur storage costs even when not in use, as EBS pricing is based on provisioned capacity per GB-month. Deleting them after verifying they are no longer needed eliminates this cost without affecting running instances, since attached volumes are untouched. This directly addresses the question's requirement to reduce storage costs without impacting running workloads.

Exam trap

AWS often tests the misconception that stopping instances or disabling services like CloudTrail reduces storage costs, but the trap here is that only direct actions on the storage resources themselves (deleting volumes and expiring snapshots) affect EBS and snapshot billing.

Practice this question →

114

MCQmedium

A company hosts an application on EC2 instances in private subnets. The instances must (1) read objects from Amazon S3 and (2) retrieve secrets from AWS Secrets Manager. The team currently sends all outbound traffic through a NAT gateway to reach both services. They want to reduce monthly cost while keeping traffic private (no internet egress) and without changing application logic. Which change is the most cost-effective?

A.Create a Gateway VPC endpoint for S3 and an Interface VPC endpoint for Secrets Manager, and ensure the subnet route tables / endpoint routing directs those service calls to the endpoints instead of the NAT gateway.

B.Keep the NAT gateway, but add AWS WAF rules to block non-service outbound requests to reduce NAT usage.

C.Disable IPv4 on the VPC subnets and rely on IPv6-only egress to reduce NAT gateway costs.

D.Replace the NAT gateway with a VPC firewall appliance instance to proxy outbound calls and reduce NAT fees.

AnswerA

This is the most cost-effective change because it removes the need to traverse the NAT gateway for those AWS service calls. S3 uses a Gateway VPC endpoint (route-table-based) for traffic to the S3 prefix list, so requests to S3 stay on the AWS network. Secrets Manager uses an Interface VPC endpoint (ENIs with private DNS), so requests to Secrets Manager stay private within the VPC/VPC endpoint network path. Because the application still calls the same AWS APIs, there is no logic change, and NAT data-processing charges drop to near zero for S3/Secrets Manager traffic.

Why this answer

Gateway VPC Endpoints for S3 and Interface VPC Endpoints for Secrets Manager allow private connectivity to these AWS services without traversing the internet or a NAT gateway. This eliminates NAT gateway hourly charges and data processing fees, reducing costs while keeping traffic within the AWS network. The application logic remains unchanged as the endpoints are accessed via the same DNS names, with route tables directing traffic to the endpoints instead of the NAT gateway.

Exam trap

The trap here is that candidates may assume NAT gateways are the only way to provide private subnet internet access, overlooking that VPC endpoints can provide private, cost-effective connectivity to specific AWS services without internet egress.

How to eliminate wrong answers

Option B is wrong because AWS WAF is a web application firewall for HTTP/HTTPS traffic, not a mechanism to reduce NAT gateway costs; it does not eliminate the NAT gateway's hourly and per-GB data processing fees. Option C is wrong because disabling IPv4 and relying on IPv6-only egress would require the application to use IPv6 addresses, which changes the application logic and may not be supported by all services; additionally, NAT gateways are not used for IPv6 traffic (egress-only internet gateways are used), so this does not address the cost of the NAT gateway for IPv4 traffic. Option D is wrong because replacing the NAT gateway with a VPC firewall appliance instance still incurs instance costs and management overhead, and it does not eliminate the need for internet egress to reach S3 and Secrets Manager unless endpoints are used; it is not more cost-effective than using VPC endpoints.

Practice this question →

115

MCQeasy

A company keeps daily database backups in an S3 bucket. They may restore from backups during the first 30 days if there is an issue. After 30 days, backups are rarely restored, but must be retained for 2 years. Which lifecycle strategy most cost-effectively meets these requirements?

A.Delete backups after 30 days to avoid storage costs, since restores are rare.

B.Keep all backups in S3 Standard for the entire 2-year retention period.

C.Use an S3 lifecycle policy to keep backups in S3 Standard for 30 days, then transition them to S3 Glacier Deep Archive for the remainder of the 2-year retention period.

D.Move backups to S3 Glacier Deep Archive immediately after creation, even for the first 30 days.

AnswerC

This is correct because an S3 Lifecycle policy can automate the transition of objects after a specified number of days. Storing backups in S3 Standard for the first 30 days ensures rapid restoration during the period when failures are most likely to be detected, then transitioning to S3 Glacier Deep Archive for the remaining ~23 months meets the 2-year retention requirement at drastically lower storage cost. Lifecycle transitions are metadata operations, so they incur no retrieval charge, making this the most cost-effective and compliant approach.

Why this answer

It balances cost and compliance: backups are kept in S3 Standard for the first 30 days when restores are frequent, ensuring low-latency access, then transitioned to S3 Glacier Deep Archive for the remaining retention period. S3 Glacier Deep Archive offers the lowest storage cost (approximately $0.00099/GB/month) for long-term retention, and the lifecycle policy automates the transition without manual intervention. This approach minimizes storage costs while meeting the 2-year retention requirement.

Exam trap

The trap here is that candidates may assume immediate deletion (Option A) or immediate archiving (Option D) are acceptable, failing to recognize the dual requirement of frequent access in the first 30 days and long-term retention at minimal cost, which the lifecycle policy elegantly addresses.

Why the other options are wrong

This option fails to meet the requirement that backups must be retained for 2 years, as it deletes them after only 30 days.

Keeping all backups in S3 Standard for 2 years incurs high storage costs for data that is rarely accessed after 30 days, making it not cost-effective.

Moving backups to Glacier Deep Archive immediately after creation would incur retrieval costs and delays for restores during the first 30 days, when restores are common, making it less cost-effective and operationally unsuitable.

Practice this question →

116

MCQeasy

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?

A.Evaluate a smaller EC2 instance type (via the Auto Scaling launch template/configuration) for the group and validate performance metrics after the change.

B.Increase desired capacity to 2x so utilization increases and instances become “more efficient.”

C.Disable Auto Scaling so the group never scales down to preserve baseline performance.

D.Switch the workload to Spot instances immediately to avoid On-Demand charges, regardless of interruption risk.

AnswerA

Right-sizing involves analyzing historical utilization metrics (e.g., CloudWatch CPU, memory) to select a less expensive instance type while still satisfying workload requirements. Changing the Auto Scaling group's launch template to a smaller instance type, then monitoring metrics such as CPU credit balance, latency, and throughput, confirms the new size can handle peak demand. This directly lowers per-instance cost without altering the number of instances needed, providing cost savings while preserving availability and performance characteristics.

Why this answer

The application is over-provisioned: CPU utilization averages only 8% with no memory pressure and stable response times. By selecting a smaller EC2 instance type in the Auto Scaling launch template or configuration, you directly reduce the per-instance cost while maintaining adequate performance. This is the most straightforward cost optimization step without modifying the application code or architecture.

Exam trap

The trap here is that candidates may think increasing capacity (Option B) improves efficiency, but in reality, adding more instances to an already underutilized workload only increases cost without any performance benefit.

How to eliminate wrong answers

Option B is wrong because increasing desired capacity to 2x would add more instances, increasing total cost while utilization per instance would drop even further, making the system less efficient, not more. Option C is wrong because disabling Auto Scaling removes the ability to scale down during low demand, which would lock in higher costs and prevent the group from right-sizing to actual load. Option D is wrong because switching to Spot instances immediately without testing or implementing interruption-handling mechanisms (e.g., graceful shutdown, checkpointing) risks application availability and stability, which is not acceptable when the goal is to lower cost without changing the application.

Practice this question →

117

MCQmedium

A production log archive runs continuously on EC2 with predictable usage for the next three years. The team wants a discount while retaining some instance-family flexibility. What should they buy? The design must avoid adding custom operational scripts.

A.S3 Intelligent-Tiering

B.Dedicated Instances

C.Compute Savings Plan

D.Spot Instances only

AnswerC

A Compute Savings Plan commits a specific hourly dollar amount for a one- or three-year term in exchange for up to 72% savings over On-Demand, and it automatically applies to any EC2 instance family, size, OS, or Region, plus Fargate and Lambda. A continuously running production log archive is a steady, predictable workload, so committing to a Compute Savings Plan locks in lower unit costs while preserving the flexibility to resize or change instance types later. This makes it the most suitable option for reducing EC2 spend on an always-on baseline.

Why this answer

The Compute Savings Plan (C) offers the largest discount (up to 66%) in exchange for a commitment to a consistent amount of compute usage (measured in $/hour) for a 1- or 3-year term, while still allowing flexibility across instance families, sizes, OS, tenancy, and regions. This matches the predictable three-year workload and the requirement for instance-family flexibility without custom scripts.

Exam trap

The trap here is that candidates confuse Savings Plans with Reserved Instances, assuming that any commitment requires locking into a specific instance family, but Compute Savings Plans explicitly provide family flexibility while still delivering a significant discount.

How to eliminate wrong answers

Option A is wrong because S3 Intelligent-Tiering is an object storage class for data with changing access patterns, not a compute pricing model for EC2 instances. Option B is wrong because Dedicated Instances provide physical isolation at a higher cost and do not offer a discount or instance-family flexibility; they are for compliance or licensing needs. Option D is wrong because Spot Instances offer deep discounts but can be interrupted with a 2-minute warning, making them unsuitable for a production log archive that must run continuously without disruption.

Practice this question →

118

MCQhard

A.S3 Intelligent-Tiering

B.Manual monthly review and object copying

C.S3 Glacier Flexible Retrieval for all files

D.EFS One Zone for analytics files

AnswerA

S3 Intelligent-Tiering is the optimal choice because it automatically monitors access patterns per object and moves data to lower-cost tiers (Infrequent Access, Archive Instant Retrieval) while keeping retrieval latency in milliseconds. It charges a small monthly monitoring fee but avoids retrieval fees and does not require lifecycle rules or retrieval delays, making it ideal for analytics files that may be accessed hot, then cool, and occasionally need immediate access.

Why this answer

S3 Intelligent-Tiering is the correct choice because it automatically moves objects between access tiers (frequent, infrequent, and archive instant retrieval) based on changing access patterns, without any retrieval delays for hot objects. This matches the unpredictable access pattern where files may become hot again months later, and it is a fully managed AWS-native solution that optimizes storage costs automatically.

Exam trap

The trap here is that candidates may choose S3 Glacier Flexible Retrieval (Option C) thinking it is the cheapest for all files, but they overlook the retrieval delay requirement and the fact that files may become hot again, which Intelligent-Tiering handles seamlessly without any retrieval latency.

How to eliminate wrong answers

Option B is wrong because manual monthly review and object copying is not automated, introduces operational overhead, and risks human error or delays, failing the 'automatic' and 'managed AWS-native' requirements. Option C is wrong because S3 Glacier Flexible Retrieval has retrieval delays (minutes to hours) for all files, which violates the 'no retrieval delays' requirement for files that become hot again. Option D is wrong because EFS One Zone is a file system, not an object storage service, and it is not designed for cost optimization of unpredictable access patterns; it also lacks the automatic tiering capability and is not the right service for analytics files that are accessed via S3 APIs.

Practice this question →

119

MCQeasy

A company stores 500 TB of archival data in Amazon S3. The data is accessed only for compliance audits, which occur once every two years. Retrieval times of up to 12 hours are acceptable. The company wants the lowest storage cost. Which S3 storage class should be used?

A.S3 One Zone-Infrequent Access (S3 One Zone-IA)

B.S3 Intelligent-Tiering

C.S3 Glacier Deep Archive

D.S3 Standard-Infrequent Access (S3 Standard-IA)

AnswerC

S3 Glacier Deep Archive is the lowest-cost storage class for long-term retention, designed for data accessed less than once per year. It supports retrieval within 12 hours, meeting the acceptable retrieval time. For compliance data accessed only every two years, it provides the most cost-effective solution.

Why this answer

S3 Glacier Deep Archive is specifically designed for long-term retention of data that is rarely accessed, offering the lowest storage cost among S3 classes. It supports retrieval within 12 hours, which matches the acceptable retrieval time. For compliance data accessed every two years, it provides the most economical solution without unnecessary retrieval speed or monitoring overhead.

Exam trap

The trap here is choosing S3 Intelligent-Tiering for automatic cost optimization, but it adds monitoring fees and may not be the absolute lowest cost for data that is predictably cold.

Practice this question →

120

MCQmedium

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?

A.Switch the instances to Spot Instances and use interruption handling because it is the largest discount.

B.Purchase a Compute Savings Plan for the expected steady hourly usage in that Region.

C.Purchase a Standard Reserved Instance tied to a single specific instance type for the next 3 years.

D.Keep On-Demand and rely on Auto Scaling to reduce capacity when utilization is low.

AnswerB

Compute Savings Plans offer lower hourly rates in exchange for a 1- or 3-year commitment, but the discount applies to any EC2 instance family/type/size in the chosen Region (even Fargate/Lambda). Because the recommendation engine runs 24/7, committing to the expected steady hourly usage captures the discount while preserving the ability to change instance families or sizes as needs evolve. Unlike Standard RIs, you're not locked into a specific instance type, so you get both cost savings and operational flexibility.

Why this answer

B is correct because a Compute Savings Plan offers the lowest cost for steady-state workloads without locking to a specific instance type, providing up to 66% discount compared to On-Demand while allowing flexibility to change instance families, sizes, OS, or tenancy within a Region. This matches the requirement for cost savings and flexibility during planned optimizations.

Exam trap

The trap here is that candidates often choose Spot Instances for cost savings without considering the interruption-intolerant requirement, or they select Standard Reserved Instances for the highest discount without recognizing the rigidity penalty for planned instance family changes.

Why the other options are wrong

The workload is interruption-intolerant, so Spot Instances are unsuitable because they can be terminated with little notice, risking service disruption.

A Standard Reserved Instance locks to a specific instance type, which conflicts with the requirement to change instance families and sizes during planned optimizations.

The workload is steady and interruption-intolerant, so Auto Scaling to reduce capacity when utilization is low would not provide the lowest cost for the steady baseline usage, and On-Demand pricing is more expensive than a Compute Savings Plan for predictable workloads.

Practice this question →

121

MCQeasy

A website serves versioned JavaScript and CSS files through CloudFront, but origin fetches are still high and the CloudFront bill increased. Developers confirm that URLs include a version in the filename (for example, app.1.4.2.js). What CloudFront behavior/configuration is most likely to reduce origin fetches and associated costs?

A.Set long cache headers (for example, Cache-Control: max-age and immutable) on those versioned assets so CloudFront caches them longer.

B.Disable compression to reduce CPU time spent at the edge and therefore reduce total cost.

C.Lower the cache policy TTLs so clients always get the newest assets quickly.

D.Remove version identifiers from filenames so CloudFront caches fewer unique objects.

AnswerA

Versioned filenames (e.g., app-1a2b3c.js) enable CloudFront to treat each URL as immutable. Setting Cache-Control: max-age=31536000, immutable on the origin tells CloudFront and browsers to cache the object for a full year without revalidation. Because every new release uses a new URL, stale content is never served, and future requests hit CloudFront's edge cache instead of going to the origin, improving cache hit ratio and reducing transfer cost.

Why this answer

Setting long cache headers like `Cache-Control: max-age=31536000, immutable` on versioned assets tells CloudFront to cache these objects at edge locations for an extended period. Since the filename changes with each new version, CloudFront treats each version as a unique object and will not re-fetch the old version from the origin, dramatically reducing origin fetches and associated costs.

Exam trap

The trap here is that candidates may think lowering TTLs or removing versioning helps with freshness or cost, but the key insight is that versioned filenames already solve cache invalidation, so extending cache duration is the cost-optimized approach.

How to eliminate wrong answers

Option B is wrong because disabling compression does not reduce CPU time at the edge in a meaningful way for cost reduction; CloudFront charges for data transfer and requests, not CPU, and compression actually reduces data transfer costs. Option C is wrong because lowering cache policy TTLs would cause CloudFront to re-fetch objects from the origin more frequently, increasing origin fetches and costs, which is the opposite of the desired outcome. Option D is wrong because removing version identifiers would cause CloudFront to treat all updates as the same object, leading to cache invalidation issues and potentially higher origin fetches when clients request the latest version without a cache busting mechanism.

Practice this question →

122

MCQhard

A company runs EC2 workloads including web servers (m5.large), batch jobs (c5.xlarge), and a data processing service that will migrate from r5 to r6i instances within 6 months. The company wants to commit to 1 year to reduce costs but needs flexibility for the planned instance family migration. Which purchasing option provides the GREATEST savings while accommodating the change?

A.Standard Reserved Instances for each instance type with a 1-year term

B.Compute Savings Plans with a 1-year term commitment

C.EC2 Instance Savings Plans for the r5 instance family with a 1-year term

D.Convertible Reserved Instances for all instance types with a 1-year term

AnswerB

Compute Savings Plans offer up to 66% savings compared to On-Demand and apply automatically to any EC2 instance family, including the transition from r5 to r6i, with no reconfiguration or exchange needed. The hourly commitment is flexible across instance sizes and operating systems, so the migration does not disrupt your discount. This makes it the only option that fully supports an instance family migration without manual intervention or wasted commitments.

Why this answer

Compute Savings Plans automatically apply to any EC2 instance regardless of family, size, region, OS, or tenancy — including both r5 and r6i. When the data processing service migrates from r5 to r6i, the Compute Savings Plan continues to apply without any action required.

EC2 Instance Savings Plans lock to a specific instance family in a specific region. When the workload migrates from r5 to r6i, the EC2 Instance Savings Plan for r5 no longer applies — leaving the r6i workload billed at On-Demand rates.

Exam trap

EC2 Instance Savings Plans offer a deeper discount (up to 72%) but are locked to a specific instance family and region. Compute Savings Plans sacrifice ~2-5% discount compared to EC2 Instance Savings Plans but cover all families, sizes, regions, and Lambda/Fargate. When a family migration is planned, Compute Savings Plans are the correct choice — EC2 Instance Savings Plans would not cover the new r6i family.

Why the other options are wrong

Standard RIs are locked to a specific instance type, size, and region. When the r5 workload migrates to r6i, the r5 RI continues billing but no longer matches the running instances — creating waste and uncovered On-Demand charges.

EC2 Instance Savings Plans lock to a specific instance family (e.g., r5) in a specific region. When the workload migrates to r6i, the Savings Plan no longer covers the new instances — they are charged at On-Demand rates.

Convertible RIs allow exchanging for different families, which could handle the r5→r6i migration. However, the exchange process is manual, requires purchasing new RIs of equal or greater value, and Compute Savings Plans provide the same flexibility automatically.

Practice this question →

123

MCQhard

A dev sandbox 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?

A.Disabling route tables

B.Replacing every NAT gateway with an internet gateway attached to private subnets

C.Moving all workloads to public subnets

D.Whether one NAT gateway per AZ is sufficient for the required private subnets

AnswerD

The correct cost-first question is whether one NAT gateway per AZ is sufficient for the required private subnets. Each NAT gateway incurs an hourly charge, so having two NAT gateways in the same AZ is redundant because they provide no additional resilience—AWS already makes a single NAT gateway highly available within its AZ. For a dev sandbox that may only use a single AZ or does not demand multi-AZ high availability, one NAT gateway is enough to serve all private subnets in that AZ. This optimization directly reduces the number of NAT gateways billed, while still meeting the actual connectivity and resilience needs if positioned correctly per AZ.

Why this answer

The question states that only one private subnet per AZ needs outbound internet access, so using two NAT gateways per AZ is likely over-provisioned and costly. The architect should first review whether one NAT gateway per AZ is sufficient, as NAT gateways are billed per hour and per gigabyte of data processed, and reducing from two to one per AZ can cut costs without sacrificing availability. This aligns with the cost-optimized design principle of right-sizing resources to actual demand.

Exam trap

The trap here is that candidates may assume more NAT gateways always improve availability or performance, but the question tests cost optimization by recognizing that one per AZ is often enough for low-traffic private subnets, and the first step is to verify sufficiency before making changes.

How to eliminate wrong answers

Option A is wrong because disabling route tables would break all routing for the subnets, not just optimize costs, and is not a valid review step for reducing NAT gateway count. Option B is wrong because internet gateways cannot be attached to private subnets; they are used for public subnets and do not provide outbound-only internet access for private resources. Option C is wrong because moving workloads to public subnets would expose them directly to the internet, violating security best practices and the sandbox's likely need for private, isolated environments.

Practice this question →

124

MCQmedium

A service runs in private subnets. It must call AWS APIs (for example, S3 and Secrets Manager). The team currently sends all outbound traffic through a NAT Gateway, and NAT charges have become a major cost driver. The workload must not traverse the public internet. What change most directly reduces NAT Gateway cost while maintaining private connectivity to those AWS services?

A.Continue using the NAT Gateway but reduce CloudWatch log retention to 1 day.

B.Replace the NAT Gateway route with VPC endpoints: use a Gateway VPC endpoint for S3 and an Interface VPC endpoint for Secrets Manager.

C.Launch a bastion host in a public subnet and force private instances to use SSH tunneling for API calls.

D.Switch to public subnets and attach security groups with the same rules to limit inbound access.

AnswerB

VPC endpoints provide private connectivity to AWS services without sending traffic through the internet or through NAT. A Gateway endpoint is used for S3, and an Interface endpoint is used for services like Secrets Manager. Traffic to those services stays within the AWS network, reducing or eliminating NAT charges for those API calls.

Why this answer

VPC endpoints allow private connectivity to AWS services without traversing the internet or a NAT Gateway. A Gateway VPC endpoint for S3 uses route table entries to reach S3 privately, and an Interface VPC endpoint for Secrets Manager uses an elastic network interface with a private IP. This eliminates NAT Gateway data processing charges entirely while keeping traffic within the AWS network.

Exam trap

The trap here is that candidates may think NAT Gateway is the only way to provide outbound connectivity, overlooking that VPC endpoints can provide private, cost-effective access to AWS services without internet routing.

How to eliminate wrong answers

Option A is wrong because reducing CloudWatch log retention does not affect NAT Gateway data processing costs, which are based on volume of traffic passing through the gateway, not log storage. Option C is wrong because forcing private instances to use SSH tunneling through a bastion host would still require outbound internet access for API calls, and SSH tunneling adds complexity, latency, and security risks without eliminating NAT costs. Option D is wrong because switching to public subnets would expose instances to the internet, violating the requirement that the workload must not traverse the public internet, and it would not reduce costs related to NAT Gateway.

Practice this question →

125

MCQmedium

A log archive serves infrequently accessed user documents that must be available immediately when requested. Which S3 storage class is likely the best cost fit? The design must avoid adding custom operational scripts.

A.Instance store volumes

B.S3 Standard-IA or S3 One Zone-IA depending on resilience requirements

C.S3 Standard for all objects

D.S3 Glacier Deep Archive

AnswerB

S3 Standard-IA and One Zone-IA both provide immediate millisecond retrieval with lower storage pricing than S3 Standard, matching infrequently accessed documents needing instant availability. Choosing between them depends on resilience: One Zone-IA sacrifices multi-AZ durability, and neither requires custom operational scripts.

Why this answer

S3 Standard-IA or S3 One Zone-IA is the best cost fit because the workload involves infrequently accessed documents that require immediate retrieval. These storage classes offer lower storage costs than S3 Standard while maintaining low-latency access (milliseconds), and they avoid custom operational scripts since retrieval is automatic via standard S3 GET requests. The choice between Standard-IA and One Zone-IA depends on whether the data requires multi-AZ resilience or can tolerate a single-AZ failure.

Exam trap

AWS often tests the misconception that 'infrequently accessed' automatically means Glacier or Deep Archive, but the key differentiator is the 'immediate availability' requirement, which eliminates any cold storage class with retrieval delays.

How to eliminate wrong answers

Option A is wrong because instance store volumes are ephemeral block storage attached to EC2 instances, not a durable S3 storage class, and they lose data on instance stop/termination, making them unsuitable for long-term log archives. Option C is wrong because S3 Standard is designed for frequently accessed data with higher storage costs, making it cost-inefficient for infrequently accessed documents, even though it provides immediate availability. Option D is wrong because S3 Glacier Deep Archive has retrieval times of 12-48 hours (not immediate), which violates the requirement for documents to be available immediately when requested.

Practice this question →

126

Multi-Selecthard

A startup has three sandbox accounts and one production account. The CTO wants lower cost and operational overhead while keeping central purchasing and spend visibility. Which two actions are best? Select two.

Select 2 answers

A.Enable consolidated billing under AWS Organizations so discounts and shared purchasing apply across accounts.

B.Move each sandbox to its own payer account to isolate spend from the rest.

C.Use managed services such as Amazon RDS or Amazon S3 instead of self-managed EC2-based databases and file servers where practical.

D.Buy Dedicated Hosts for sandbox workloads to get a lower blended rate.

E.Disable AWS Budgets because consolidated billing already solves visibility.

AnswersA, C

Consolidated billing under AWS Organizations pools usage across all four accounts, so volume discounts and Savings Plans apply to aggregate spend rather than per-account totals. This directly satisfies the CTO's lower-cost and central-purchasing requirements, while the management account retains unified spend visibility without extra tooling.

Why this answer

Option A is correct because AWS Organizations consolidated billing places all four accounts under a single payer account, which aggregates usage for volume discounts (such as S3 tiered pricing and Reserved Instance/Savings Plans sharing), centralizes purchasing, and provides a single bill for spend visibility — exactly matching the CTO's goals of lower cost, less overhead, and central purchasing. Option C is correct because replacing self-managed EC2-based databases and file servers with managed services like Amazon RDS and Amazon S3 reduces operational overhead (patching, backups, scaling handled by AWS) and typically lowers total cost, aligning with the startup's desire to minimize operational burden. Option B is wrong because separate payer accounts fragment billing, forfeit volume discounts and RI/SP sharing, and increase overhead rather than reduce it.

Option D is wrong because Dedicated Hosts are a premium-priced option intended for licensing/compliance needs, not a cost-saving measure for sandbox workloads. Option E is wrong because AWS Budgets is a free cost-visibility and alerting tool; disabling it removes the very spend visibility the CTO wants, and consolidated billing alone does not provide budget alerts or thresholds.

Exam trap

The trap here is that candidates might think Dedicated Hosts (Option D) reduce costs for sandbox workloads, but they actually increase costs due to per-host billing and are intended for specific licensing scenarios, not general cost optimization.

Why the other options are wrong

Moving each sandbox to its own payer account increases operational overhead and reduces cost visibility, contradicting the goal of lowering cost and overhead while maintaining central purchasing and spend visibility.

Dedicated Hosts increase cost and operational overhead, contradicting the goal of lowering cost and overhead. They are not needed for sandbox workloads and do not provide a lower blended rate compared to Reserved Instances or Savings Plans under consolidated billing.

Disabling AWS Budgets removes spend visibility, which the CTO explicitly wants to maintain. Consolidated billing does not automatically provide visibility; budgets and alerts are still needed.

Practice this question →

127

MCQmedium

A internal reporting portal serves infrequently accessed user documents that must be available immediately when requested. Which S3 storage class is likely the best cost fit? The architecture review board prefers a managed AWS-native control.

A.Instance store volumes

B.S3 Glacier Deep Archive

C.S3 Standard for all objects

D.S3 Standard-IA or S3 One Zone-IA depending on resilience requirements

AnswerD

S3 Standard-IA and S3 One Zone-IA both deliver the same millisecond data access as S3 Standard while charging lower storage fees for data that is infrequently retrieved. Standard-IA stores data redundantly across multiple Availability Zones, providing high resilience, whereas One Zone-IA stores data only within a single AZ, reducing cost further but risking loss if that AZ fails. For an internal reporting portal with sparse usage, choose Standard-IA when durability and availability are critical, or One Zone-IA if the data can be regenerated and lower cost is prioritized.

Why this answer

S3 Standard-IA or S3 One Zone-IA is the best cost fit because the data is infrequently accessed but requires immediate availability when requested. These storage classes offer lower storage costs than S3 Standard while providing millisecond first-byte latency, meeting the 'immediately available' requirement. The choice between Standard-IA and One Zone-IA depends on the resilience needs (e.g., multi-AZ vs. single-AZ durability).

Exam trap

The trap here is that candidates often confuse 'infrequently accessed' with 'archival' and incorrectly choose S3 Glacier Deep Archive, overlooking the critical requirement for immediate availability on request.

How to eliminate wrong answers

Option A is wrong because instance store volumes are ephemeral, tied to a specific EC2 instance, and not a managed AWS-native control for object storage; they lose data on instance stop/termination and are not suitable for durable document storage. Option B is wrong because S3 Glacier Deep Archive has retrieval times of 12 hours or more (expedited retrieval is not available), which violates the 'immediately available when requested' requirement. Option C is wrong because S3 Standard is designed for frequently accessed data and would incur higher storage costs than necessary for infrequently accessed documents, making it not cost-optimal.

Practice this question →

128

Multi-Selectmedium

A company runs a stateless web application on a fleet of six On-Demand EC2 instances behind an Application Load Balancer. The instances are spread across three Availability Zones in a single AWS Region and run 24/7. The workload is steady and predictable, and the company wants to reduce compute costs without changing the application architecture or reducing availability. The company is willing to commit to a one-year term. Which two actions will reduce the EC2 compute cost for this workload? (Choose two.)

Select 2 answers

A.Purchase a one-year Standard Reserved Instance for each of the six running instances in the same instance family and Region.

B.Enable detailed monitoring on all instances and configure an Auto Scaling target tracking policy at 40% CPU.

C.Replace the On-Demand instances with Spot Instances and let the Auto Scaling group replace any interrupted capacity.

D.Purchase a one-year Compute Savings Plan covering the expected steady-state compute usage.

E.Move the instances into a placement group and enable cluster networking between them.

AnswersA, D

Standard Reserved Instances for a specific instance family and Region provide a significant discount compared to On-Demand for steady-state usage and are a valid way to reduce cost when the instance family is stable. Because the fleet is constant and the term matches the company's one-year willingness to commit, this achieves the cost reduction without altering the architecture or availability.

Why this answer

For steady, predictable, always-on compute, commitment-based discounts are the correct lever. Compute Savings Plans and Standard Reserved Instances both convert On-Demand hourly pricing into a lower committed rate for a one-year term, satisfying the cost goal while preserving the multi-AZ, always-available design. Spot capacity and monitoring changes do not meet the availability requirement or do not change the compute rate.

Exam trap

The trap here is assuming that any discount mechanism is interchangeable, when the requirement to keep availability high across three Availability Zones rules out interruption-prone capacity even though it is cheaper.

Practice this question →

129

MCQmedium

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?

A.Increase the instance size to reduce CPU throttling risk

B.Perform right sizing by downsizing to a smaller instance family/size and validate SLAs

C.Switch the group to Spot Instances to reduce cost without changing instance sizing

D.Buy Reserved Instances with a long term commitment before making any sizing changes

AnswerB

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.

Why this answer

The current instance type is over-provisioned, as sustained CPU utilization is only 6% with no memory pressure and all SLAs are met. Right-sizing to a smaller instance family or size directly reduces compute cost while maintaining performance, making it the lowest-risk, cost-optimization action. This aligns with the AWS Well-Architected Framework's cost optimization pillar, which recommends matching instance capacity to actual workload requirements.

Exam trap

The trap here is that candidates may assume Spot Instances are always the cheapest option, but they ignore the risk of interruption for a continuously running workload where SLAs must be met, making right-sizing the safer and more appropriate first step.

How to eliminate wrong answers

Option A is wrong because increasing instance size would raise costs and is unnecessary given the low CPU utilization and no performance issues. Option C is wrong because switching to Spot Instances introduces the risk of interruption, which is not minimal risk for a continuously running background worker that must meet SLAs. Option D is wrong because buying Reserved Instances before right-sizing locks in a commitment for an over-provisioned instance type, increasing cost without addressing the root cause of waste.

Practice this question →

130

MCQmedium

A test environment has EC2 instances that are oversized based on CPU, memory, and network utilisation. Which AWS service should identify rightsizing recommendations? The architecture review board prefers a managed AWS-native control.

A.AWS DataSync

B.AWS Shield

C.AWS Artifact

D.AWS Compute Optimizer

AnswerD

AWS Compute Optimizer uses machine learning to analyze historical utilization metrics from CloudWatch, including CPU, memory, network, and storage, to identify whether EC2 instances are oversized, undersized, or optimally sized. It then produces instance type recommendations with a performance risk score, directly answering the question of whether the test environment's instances are oversized. Its findings are actionable, enabling cost savings without sacrificing workload performance.

Why this answer

AWS Compute Optimizer is a managed service that uses machine learning to analyze historical utilization metrics (CPU, memory, network, and storage) and provides rightsizing recommendations for EC2 instances. It identifies over-provisioned resources and suggests instance types that better match workload requirements, directly addressing the oversized EC2 instances in the test environment.

Exam trap

The trap here is that candidates may confuse AWS Compute Optimizer with other monitoring or cost tools (like AWS Trusted Advisor or Cost Explorer), but the question specifically asks for a managed AWS-native service that identifies rightsizing recommendations, which is Compute Optimizer's primary function.

How to eliminate wrong answers

Option A is wrong because AWS DataSync is a data transfer service for moving large datasets between on-premises storage and AWS services (e.g., S3, EFS), not a tool for analyzing EC2 utilization or providing rightsizing recommendations. Option B is wrong because AWS Shield is a managed DDoS protection service that safeguards applications against distributed denial-of-service attacks, unrelated to cost optimization or instance sizing. Option C is wrong because AWS Artifact is a self-service portal for downloading AWS compliance reports and agreements (e.g., SOC, PCI), not a service for monitoring or recommending EC2 instance changes.

Practice this question →

131

MCQeasy

An internal team runs a report-generation job once per day. It typically finishes in a few minutes, and even on its slowest days it still completes in under 15 minutes. The team wants to reduce operational overhead and pay primarily for actual runtime instead of keeping servers running 24/7. Which AWS approach best matches these goals?

A.Deploy the job on EC2 instances and keep them running continuously for the daily schedule.

B.Use AWS Lambda triggered by a schedule (for example, EventBridge) to run the report at the required time.

C.Run the job in an RDS database using stored procedures scheduled by the database engine.

D.Use an Auto Scaling group with a fixed minimum size of one instance and disable scaling.

AnswerB

Lambda runs only when EventBridge invokes it on schedule, so billing reflects invocation duration rather than idle server hours. The job finishes well within Lambda's 15-minute limit, so the runtime ceiling is not exceeded and operational overhead drops.

Why this answer

AWS Lambda, triggered by Amazon EventBridge (CloudWatch Events), is ideal for short-lived, infrequent jobs like this daily report. It eliminates idle server costs by running only when invoked, and the 15-minute execution timeout comfortably covers the job's maximum runtime. This serverless approach directly reduces operational overhead and aligns with a pay-per-use cost model.

Exam trap

The trap here is that candidates may assume EC2 or Auto Scaling is needed for any scheduled job, overlooking that Lambda's 15-minute timeout and serverless pricing perfectly suit short, infrequent tasks, while the 'pay primarily for actual runtime' requirement explicitly points away from always-on compute.

Why the other options are wrong

Keeping EC2 instances running 24/7 incurs costs for idle time, contradicting the goal of paying primarily for actual runtime when the job completes in under 15 minutes daily.

Running the job as stored procedures in RDS would still require a running database instance 24/7, incurring costs for idle time, and does not align with the goal of paying primarily for actual runtime.

An Auto Scaling group with a fixed minimum size of one instance keeps an EC2 instance running 24/7, which incurs costs for idle time and does not reduce operational overhead or pay-per-use runtime.

Practice this question →

132

MCQmedium

A internal reporting portal serves infrequently accessed user documents that must be available immediately when requested. Which S3 storage class is likely the best cost fit? The design must avoid adding custom operational scripts.

A.Instance store volumes

B.S3 Glacier Deep Archive

C.S3 Standard for all objects

D.S3 Standard-IA or S3 One Zone-IA depending on resilience requirements

AnswerD

S3 Standard-IA is the correct default because it retains S3's 11 nines of durability and millisecond retrieval while reducing storage cost for infrequently accessed data. S3 One Zone-IA lowers the cost further by storing the data in a single Availability Zone, which trades away resilience against an AZ failure; this is acceptable if the documents are easily reproducible or stored elsewhere. The choice between them depends on resilience requirements: choose Standard-IA if the documents must survive a data center loss, or One Zone-IA if cost reduction is more important than that resilience, making this combined answer technically precise.

Why this answer

S3 Standard-IA or S3 One Zone-IA is the best cost fit because the data is infrequently accessed but requires immediate availability when requested. These storage classes offer lower storage costs than S3 Standard while providing low-latency retrieval (milliseconds), avoiding the retrieval delays or operational overhead of archival tiers. The choice between Standard-IA and One Zone-IA depends on resilience needs: Standard-IA stores data across multiple AZs, while One Zone-IA stores data in a single AZ at a lower cost.

Exam trap

The trap here is that candidates often choose S3 Glacier Deep Archive for infrequently accessed data without considering the immediate availability requirement, or they default to S3 Standard assuming all infrequent access needs archival storage, missing the cost-optimized middle ground of Standard-IA or One Zone-IA.

How to eliminate wrong answers

Option A is wrong because instance store volumes are ephemeral block storage attached to EC2 instances, not a durable S3 storage class, and they lose data when the instance stops or terminates, making them unsuitable for long-term document storage. Option B is wrong because S3 Glacier Deep Archive has retrieval times of 12-48 hours, which violates the requirement that documents must be available immediately when requested. Option C is wrong because S3 Standard is designed for frequently accessed data and would incur higher storage costs than necessary for infrequently accessed documents, making it not the best cost fit.

Practice this question →

133

MCQhard

A dev sandbox 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? The design must avoid adding custom operational scripts.

A.Disabling route tables

B.Replacing every NAT gateway with an internet gateway attached to private subnets

C.Moving all workloads to public subnets

D.Whether one NAT gateway per AZ is sufficient for the required private subnets

AnswerD

Consolidating to one NAT gateway per AZ still provides outbound access for each AZ's private subnet while removing three redundant gateways. This satisfies the stem's constraint of avoiding custom operational scripts, since NAT gateway placement is a native configuration change rather than scripted failover logic.

Why this answer

The question asks what the architect should review first to optimize costs while maintaining functionality. Using two NAT gateways per AZ when only one private subnet per AZ needs outbound internet access is redundant; a single NAT gateway per AZ can handle the traffic for all private subnets in that AZ. The design must avoid custom operational scripts, so the simplest review is to check if one NAT gateway per AZ is sufficient, which would reduce costs without breaking connectivity.

Exam trap

The trap here is that candidates may assume more NAT gateways are always better for high availability, but the question asks for a cost-optimization review first, and the current setup is over-provisioned for the stated requirement.

How to eliminate wrong answers

Option A is wrong because disabling route tables would break all routing, not just optimize NAT gateway usage, and it would require custom scripts to restore functionality, violating the design constraint. Option B is wrong because internet gateways cannot be attached to private subnets; they are used for public subnets and would expose instances directly to the internet, breaking the private subnet isolation requirement. Option C is wrong because moving all workloads to public subnets would expose them to the internet, which is not suitable for a dev sandbox that likely requires private subnets for security, and it does not address the NAT gateway cost issue.

Practice this question →

134

Multi-Selectmedium

A startup runs two EC2-based workloads in the same AWS Region. Its customer-facing API is always on, and its nightly video transcoding fleet can restart jobs from checkpoints if an instance is interrupted. The finance team wants the lowest monthly compute cost without changing the application design. Which two actions should the team take? Select two.

Select 2 answers

A.Purchase an All Upfront Reserved Instance for the transcoding fleet only.

B.Buy a Compute Savings Plan to cover the always-on API baseline usage.

C.Run the transcoding fleet on Spot Instances because interrupted jobs can resume from checkpoints.

D.Increase the API instance size so CPU utilization stays below 30 percent.

E.Move the API tier to Dedicated Hosts to improve isolation and lower spend.

AnswersB, C

A Compute Savings Plan applies discounted rates to eligible EC2 usage across instance families, sizes, tenancy and Regions, so it covers the API's steady always-on baseline without locking the fleet to a specific instance type. That satisfies the finance team's lowest-cost requirement while preserving the existing application design.

Why this answer

A Compute Savings Plan offers the lowest cost for steady-state workloads like the always-on API, providing up to 66% savings over On-Demand in exchange for a 1- or 3-year commitment. It applies to any EC2 instance family within a Region, making it flexible and cost-effective for the baseline usage. Option C is correct because Spot Instances can be up to 90% cheaper than On-Demand and are ideal for fault-tolerant workloads like the transcoding fleet, which can resume from checkpoints if interrupted.

Exam trap

The trap here is that candidates often assume Reserved Instances are always the cheapest option, but for interruptible workloads like transcoding, Spot Instances provide far greater savings, and a Savings Plan better covers the steady-state API usage without locking into a specific instance family.

Why the other options are wrong

The transcoding fleet can handle interruptions, so Spot Instances are cheaper than Reserved Instances. Purchasing All Upfront Reserved Instances for the transcoding fleet would lock in higher costs unnecessarily.

Increasing instance size to keep CPU below 30% wastes compute capacity and increases cost, contradicting the goal of lowest monthly compute cost. The question explicitly states not to change application design, and this action changes the instance type.

Dedicated Hosts increase cost due to per-host billing and do not lower spend; they are used for licensing or compliance, not cost savings. The question asks for lowest compute cost, so this option is counterproductive.

Practice this question →

135

MCQmedium

A marketing site runs on x86 EC2 instances and uses open-source software with no architecture-specific licensing restriction. What should be evaluated to reduce compute cost? The architecture review board prefers a managed AWS-native control.

A.Cross-Region data replication for all data

B.io2 Block Express volumes for all instances

C.AWS Graviton-based instances after performance testing

D.Dedicated Hosts by default

AnswerC

AWS Graviton instances run on custom Arm-based processors and, for many workloads, deliver up to 40% better price performance than comparable x86 instances, especially for web servers running open-source software that is already compiled for ARM. The recommended approach is to performance-test the application on Graviton first—because it's a different architecture and some native libraries must be recompiled—then use instance types like m7g or t4g for production, which can cut compute cost without sacrificing throughput.

Why this answer

AWS Graviton-based instances use ARM-based custom processors that offer up to 40% better price-performance compared to comparable x86 instances for many workloads. Since the marketing site runs open-source software with no architecture-specific licensing restrictions, migrating to Graviton after performance testing can significantly reduce compute costs while leveraging a managed AWS-native control (e.g., EC2 Auto Scaling groups with Graviton instance types).

Exam trap

The trap here is that candidates may assume Dedicated Hosts (Option D) are cost-effective for all workloads, but they actually increase costs due to per-host billing and are only justified for specific licensing or compliance needs, not general compute cost reduction.

How to eliminate wrong answers

Option A is wrong because cross-Region data replication increases data transfer and storage costs, and it does not directly reduce compute costs; it is a data durability and disaster recovery feature, not a compute optimization. Option B is wrong because io2 Block Express volumes are high-performance EBS volumes designed for latency-sensitive workloads, not for reducing compute costs; they increase storage costs and do not address compute instance pricing. Option D is wrong because Dedicated Hosts incur additional hourly charges for physical server isolation and are typically used for licensing or compliance requirements, not for cost reduction; they increase costs compared to shared tenancy instances.

Practice this question →

136

MCQeasy

An EC2 workload runs in one region on a single instance type. For the last month, CloudWatch metrics show average CPU utilization of 12% and no sustained memory pressure. The team wants to reduce cost while maintaining the current performance level. What is the best first step?

A.Use AWS Compute Optimizer to get recommendations for instance type and size changes.

B.Increase the instance size to reduce the risk of performance regression.

C.Switch to Spot Instances immediately to reduce cost regardless of utilization.

D.Disable detailed monitoring to lower CloudWatch charges.

AnswerA

AWS Compute Optimizer analyzes historical metrics (such as CPU and memory utilization) and recommends instance type and size changes to improve cost-effectiveness while targeting performance. Given sustained low CPU and no sustained memory pressure, this is the most direct first step to identify a smaller/fewer-overprovisioned instance configuration that can maintain performance.

Why this answer

AWS Compute Optimizer analyzes historical utilization metrics (CPU, memory, I/O) and provides actionable recommendations for right-sizing instances. Given the average CPU utilization of only 12% and no memory pressure, Compute Optimizer will likely recommend a smaller instance type or family that matches the workload's actual resource needs, reducing cost without affecting performance.

Exam trap

The trap here is that candidates may think increasing instance size (Option B) is a safe 'performance buffer' move, but the question explicitly asks to reduce cost while maintaining current performance, making right-sizing via Compute Optimizer the logical first step.

How to eliminate wrong answers

Option B is wrong because increasing instance size would raise costs unnecessarily when utilization is already low, and it does not address the goal of cost reduction. Option C is wrong because switching to Spot Instances without first analyzing workload suitability risks interruption and potential performance degradation; Spot Instances are not a guaranteed cost-reduction strategy for all workloads. Option D is wrong because disabling detailed monitoring (1-minute metrics) saves only a trivial amount and does not address the primary cost driver—compute instance charges—while losing granular visibility needed for right-sizing decisions.

Practice this question →

137

MCQhard

A company runs an Amazon DynamoDB table that stores session data for a consumer application. The table is 800 GB and receives highly variable read and write traffic with sharp, unpredictable peaks during marketing campaigns. The team currently provisions 20,000 read capacity units and 10,000 write capacity units and frequently sees throttling during peaks and wasted capacity between them. A solutions architect must reduce cost and eliminate throttling with the least operational effort. Which solution meets these requirements?

A.Increase provisioned capacity to 60,000 read capacity units and 30,000 write capacity units and enable auto scaling.

B.Add a DynamoDB Accelerator (DAX) cluster in front of the table and keep the current provisioned capacity.

C.Enable DynamoDB auto scaling with a target utilization of 70% for both read and write capacity.

D.Switch the table to on-demand capacity mode.

AnswerD

On-demand mode instantly accommodates whatever traffic arrives, so unpredictable campaign peaks no longer cause throttling, and you pay only for the read and write request units actually consumed. There is no capacity planning or scaling configuration to manage, which satisfies the least-operational-effort requirement while removing charges for idle provisioned capacity between peaks.

Why this answer

The traffic pattern is spiky and unpredictable, which is exactly where provisioned capacity with reactive auto scaling falls short and where on-demand mode excels. On-demand billing charges per request unit consumed, scales instantly to any traffic level, and removes the need to tune capacity, so it both eliminates throttling and avoids paying for idle provisioned throughput between campaigns.

Exam trap

The trap here is treating auto scaling as equivalent to on-demand capacity; auto scaling is reactive and metric-driven, so it can lag behind sudden spikes and still leave a provisioned baseline that is billed around the clock.

Practice this question →

138

MCQeasy

A startup expects steady compute usage around the clock for the next year. They want to reduce costs compared to On-Demand pricing, without tightly planning specific instance types. Which option best matches their goal?

A.Purchase a Compute Savings Plan to receive discounted rates for a usage amount over a 1-year term.

B.Purchase a Reserved Instance that must be tied to exactly one specific instance size (no flexibility to switch instance families).

C.Only use Spot Instances and set the workload to stop immediately if capacity is interrupted.

D.Rely on On-Demand pricing and add more alarms to detect when costs spike.

AnswerA

Compute Savings Plans provide discounted EC2 usage (and related compute usage) versus On-Demand for a committed amount per hour. They are not limited to a single instance type, so the team can change instance families while staying within the committed usage.

Why this answer

A Compute Savings Plan offers the lowest prices on EC2 compute usage (including Fargate and Lambda) in exchange for a commitment to a consistent amount of compute (measured in $/hour) over a 1-year or 3-year term. This matches the startup's steady, predictable usage and provides up to 66% savings over On-Demand, while allowing flexibility to change instance families, sizes, regions, or even switch to containers without renegotiating the plan.

Exam trap

The trap here is that candidates often confuse Compute Savings Plans with Reserved Instances, assuming both lock you to a specific instance type, but Compute Savings Plans provide full flexibility across instance families, sizes, and even compute services.

How to eliminate wrong answers

Option B is wrong because a Reserved Instance (Standard or Convertible) is tied to a specific instance family and often a specific size within that family, which contradicts the requirement for flexibility across instance types. Option C is wrong because Spot Instances can be interrupted with only a 2-minute warning, making them unsuitable for steady, around-the-clock compute workloads that cannot tolerate interruptions. Option D is wrong because relying solely on On-Demand pricing with alarms does not reduce costs; alarms only notify of cost spikes but do not provide any discount mechanism.

Practice this question →

139

MCQmedium

A batch analytics job has unpredictable DynamoDB traffic with long idle periods and occasional spikes. Which capacity mode should minimize operational overhead and avoid paying for idle provisioned capacity? The architecture review board prefers a managed AWS-native control.

A.DynamoDB on-demand capacity mode

B.Reserved capacity for maximum daily traffic

C.Provisioned capacity set for peak traffic

D.Global tables in every Region

AnswerA

DynamoDB on-demand capacity mode automatically scales read/write capacity to match actual traffic, so you never have to estimate peaks or pre-commit throughput. You pay only for the requests you actually make, which is ideal for unpredictable, spiky workloads because sudden bursts are absorbed without throttling or manual intervention. This mode eliminates both the risk of under-provisioning and the over-provisioning cost waste of fixed capacity plans, making it the most cost-effective and operationally simple choice for this scenario.

Why this answer

DynamoDB on-demand capacity mode automatically scales to handle unpredictable traffic spikes and idle periods, charging only for the reads/writes you perform. This eliminates the need to provision capacity, reducing operational overhead and avoiding costs for idle provisioned capacity, aligning with the architecture review board's preference for a managed AWS-native control.

Exam trap

The trap here is that candidates may confuse 'reserved capacity' or 'provisioned capacity' as cost-effective for spikes, but they fail to recognize that on-demand is the only mode that eliminates idle cost and operational overhead for unpredictable workloads.

How to eliminate wrong answers

Option B is wrong because reserved capacity requires upfront commitment to a specific traffic level, which doesn't suit unpredictable spikes and idle periods, and would still incur costs for unused capacity. Option C is wrong because provisioned capacity set for peak traffic would over-provision during idle periods, leading to paying for unused capacity and increased operational overhead to manage scaling. Option D is wrong because global tables are a replication feature for multi-Region data access, not a capacity mode, and they do not address cost optimization for unpredictable traffic or idle periods.

Practice this question →

140

MCQmedium

A test environment stores logs in S3. Logs are queried for 30 days, rarely accessed for one year, and then retained for compliance. What should reduce storage cost? The design must avoid adding custom operational scripts.

A.Keep all logs in S3 Standard indefinitely

B.Move all logs immediately to S3 Glacier Deep Archive

C.S3 lifecycle policy that transitions objects to lower-cost storage classes over time

D.Use EBS snapshots for the logs

AnswerC

An S3 lifecycle policy automatically transitions objects between storage classes on defined schedules and expires them, matching the 30-day query, one-year infrequent, then compliance-retention pattern. It is configuration-driven, so no custom operational scripts are added, satisfying that constraint.

Why this answer

S3 lifecycle policies automate the transition of objects between storage classes based on age, allowing logs to move from S3 Standard (for frequent querying) to S3 Standard-IA or S3 One Zone-IA (for rare access), and eventually to S3 Glacier Deep Archive (for long-term compliance retention). This reduces storage cost without custom scripts, aligning with the requirement to avoid operational overhead.

Exam trap

The trap here is that candidates may choose Option B (immediate move to Glacier Deep Archive) thinking it minimizes cost, but they overlook the 30-day query requirement, which makes S3 Standard necessary for fast retrieval, and fail to recognize that lifecycle policies provide a graduated, automated approach.

How to eliminate wrong answers

Option A is wrong because keeping all logs in S3 Standard indefinitely incurs the highest storage cost, ignoring the cost savings from transitioning to lower-cost classes for rarely accessed and compliance-retained data. Option B is wrong because moving all logs immediately to S3 Glacier Deep Archive prevents the 30-day querying requirement, as retrieval times are hours and costs are high for frequent access, violating the design need for queryability. Option D is wrong because EBS snapshots are block-level backups for EC2 instances, not designed for log storage in S3, and would introduce unnecessary complexity and cost without addressing the tiered access pattern.

Practice this question →

141

Multi-Selecthard

A log archive has old unattached EBS volumes and many stale snapshots. Which two actions reduce storage cost without affecting running instances? The design must avoid adding custom operational scripts.

Select 2 answers

A.Stop all EC2 instances in the account

B.Disable CloudTrail logging

C.Delete unattached EBS volumes after verifying they are no longer needed

D.Apply snapshot lifecycle policies to expire obsolete snapshots

AnswersC, D

Unattached EBS volumes in the 'available' state still incur full storage charges because EBS billing is based on provisioned capacity, not on whether the volume is attached to an instance. Before deleting, you should verify the volume is no longer needed (e.g., it is not the boot volume of a stopped instance or referenced in a launch template). You can also create a final snapshot for backup, but deleting the volume itself is what stops recurring costs.

Why this answer

Deleting unattached EBS volumes eliminates storage costs for volumes that are not in use, and since they are not attached to any running instance, this action does not affect running instances. Option D is correct because applying snapshot lifecycle policies automates the deletion of obsolete snapshots, reducing storage costs without requiring custom scripts or impacting running instances.

Exam trap

The trap here is that candidates may confuse stopping instances (which does not delete volumes or snapshots) with deleting resources, or think disabling CloudTrail reduces storage costs, when in fact CloudTrail logs are stored in S3, not EBS, and have separate cost implications.

Practice this question →

142

MCQmedium

A media company uploads raw video thumbnails to an S3 bucket every hour. The application needs these thumbnails for active browsing for the first 7 days. After day 7, access becomes rare. Requirements: - Objects must remain available in S3 for at least 180 days total. - After day 7, the team can tolerate retrieval latency in the range of minutes to hours. - They want to minimize storage cost while keeping the ability to read objects (no application changes required). Which storage strategy is the most cost-optimized fit?

A.Use a bucket-level lifecycle rule to transition objects to S3 Standard-IA on day 7 and then expire them after day 180.

B.Use a lifecycle rule to transition objects to S3 Glacier Flexible Retrieval after day 7 and expire them after day 180.

C.Keep all objects in S3 Standard for 180 days, and enable S3 Intelligent-Tiering only if the bucket’s access frequency is above a threshold.

D.Use a lifecycle rule to transition objects to S3 Glacier Instant Retrieval after day 7 and expire them after day 180.

AnswerB

Glacier Flexible Retrieval is designed for infrequent access and supports restore times compatible with minutes to hours. Transitioning after day 7 reduces storage cost for the long period where access is rare, while expiring at day 180 satisfies the 180-day retention requirement. The application can still use S3 GetObject; retrieval simply takes longer due to the archival tier.

Why this answer

S3 Glacier Flexible Retrieval provides retrieval times from minutes to hours, which matches the tolerance for rare access after day 7, and offers the lowest storage cost among the options for data that is rarely accessed. A lifecycle rule transitions objects from S3 Standard (used for the first 7 days of active browsing) to Glacier Flexible Retrieval on day 7, then expires them after day 180, meeting the 180-day retention requirement without application changes.

Exam trap

The trap here is that candidates often choose S3 Glacier Instant Retrieval (Option D) because of the word 'Instant,' overlooking that the requirement explicitly tolerates minutes-to-hours latency, making the cheaper Glacier Flexible Retrieval the better cost-optimized choice.

How to eliminate wrong answers

Option A is wrong because S3 Standard-IA is designed for infrequent access but still incurs higher storage costs than Glacier Flexible Retrieval for data that is accessed rarely (minutes-to-hours latency is acceptable), and it does not provide the lowest cost for this use case. Option C is wrong because keeping all objects in S3 Standard for 180 days is significantly more expensive than transitioning to a colder storage class, and S3 Intelligent-Tiering is not cost-optimized for a predictable access pattern (active for 7 days, then rarely accessed) as it adds monitoring costs and may not move objects to the cheapest tier quickly enough. Option D is wrong because S3 Glacier Instant Retrieval is designed for millisecond retrieval, which is unnecessary and more expensive than Glacier Flexible Retrieval when minutes-to-hours latency is acceptable, thus not the most cost-optimized choice.

Practice this question →

143

Multi-Selecthard

Multiple teams share one AWS Organization. Finance wants chargeback by project, alerts before overspend, and monthly views by account without manually opening each account. Which three actions best fit? Select three.

Select 3 answers

A.Enforce cost allocation tags on resources and activate them for billing reports.

B.Use AWS Budgets to create alerts and budget actions for each project.

C.Use Cost Explorer or Cost and Usage Reports to analyze spend by account, tag, and service.

D.Put every team in a separate AWS account and ignore tagging.

E.Use CloudTrail trails to estimate spend by resource because it records API calls.

AnswersA, B, C

Enforcing cost allocation tags and activating them for billing reports creates the project dimension Finance needs for chargeback, since AWS only surfaces tag-level costs once tags are activated in Billing. This directly satisfies the stem's requirement to attribute shared-account spend by project rather than by account alone.

Why this answer

Option A is correct because enforcing and activating cost allocation tags (e.g., project tags) is the prerequisite for attributing AWS charges to projects in billing data, enabling accurate chargeback. Option B is correct because AWS Budgets supports cost budgets scoped by tag, account, or service, and can trigger SNS alerts and budget actions (such as applying SCPs or stopping instances) before overspend occurs. Option C is correct because Cost Explorer and Cost and Usage Reports (CUR) provide the consolidated, multi-account analysis by account, tag, and service that Finance needs without manually opening each account, especially when integrated with AWS Organizations.

Option D is not appropriate because merely isolating teams into separate accounts without tagging does not provide project-level chargeback or the required tag-based views. Option E is incorrect because CloudTrail records API activity for auditing, not resource costs, and cannot estimate spend by resource.

Exam trap

The trap here is that candidates may confuse CloudTrail (which records API calls) with AWS Cost Explorer or CUR (which provide actual cost data), leading them to incorrectly select option E for cost estimation.

Why the other options are wrong

Putting teams in separate accounts without tagging prevents chargeback by project and requires manual account access for monthly views, failing to meet the requirements for cost allocation and automated reporting.

CloudTrail records API calls for auditing, not cost allocation. It does not provide cost or usage data by resource, tag, or project, so it cannot support chargeback, alerts, or monthly views by account.

Practice this question →

144

Multi-Selecthard

A retailer runs a reporting-heavy relational app on Amazon RDS MySQL. Peak dashboard traffic lasts only three hours each day, but the database is sized for the peak all day. The business wants lower cost without rewriting the application. Which three actions are best? Select three.

Select 3 answers

A.Right-size the writer based on actual utilization instead of peak guesses.

B.Add read replicas and direct dashboard traffic away from the writer.

C.Evaluate Aurora MySQL if the current replica-heavy design would be cheaper there.

D.Migrate to DynamoDB immediately because every relational workload is more expensive.

E.Increase provisioned IOPS permanently so the monthly bill drops.

AnswersA, B, C

Right-sizing the writer to actual utilisation rather than peak guesses reduces instance cost while preserving the existing MySQL application. It directly addresses the stem's constraint that the database is over-provisioned for all-day peak, requiring no application rewrite.

Why this answer

Option A is correct because right-sizing the writer instance to match actual CPU, memory, and IOPS utilization rather than peak-day guesses directly reduces the largest cost component of an RDS MySQL deployment without changing the application. Option B is correct because adding read replicas and routing dashboard (read-only) queries to them offloads the writer, letting the writer be smaller and cheaper while still serving peak reporting traffic. Option C is correct because evaluating Aurora MySQL is a valid cost-optimization step: Aurora's distributed storage and replica model can be cheaper for replica-heavy read workloads, and it remains MySQL-compatible so no application rewrite is needed.

Option D is wrong because DynamoDB is a NoSQL service that would require rewriting the relational application, which the business explicitly wants to avoid. Option E is wrong because permanently increasing provisioned IOPS raises, not lowers, the monthly bill.

Exam trap

The trap here is that candidates assume DynamoDB is always cheaper for any workload, ignoring the need for application rewrites and the relational reporting requirements, while also overlooking that increasing IOPS always raises costs rather than lowering them.

Practice this question →

145

MCQeasy

A team stores application logs in Amazon CloudWatch Logs. They enabled long retention and detailed dashboards, resulting in higher-than-expected monthly spend. Compliance requires retaining logs for 90 days, but operations only needs aggregated views. Which change most directly reduces CloudWatch Logs cost while meeting the requirement?

A.Set the CloudWatch Logs log group retention period to 90 days for the relevant log groups.

B.Disable VPC flow logs so the applications stop producing logs automatically.

C.Increase the logging level to DEBUG to reduce the number of log events by batching them.

D.Turn off CloudWatch alarms so logs stop being ingested into CloudWatch Logs.

AnswerA

CloudWatch Logs storage charges are calculated per GB per month, and log groups default to never expiring unless you configure a retention policy. Setting the retention period to 90 days on the specific log groups the applications write to causes CloudWatch Logs to automatically delete log events older than 90 days, which progressively reduces the stored volume and therefore the monthly storage cost while still preserving the required 90 days of logs. This directly addresses the storage cost driver: how long data is retained.

Why this answer

Setting the CloudWatch Logs log group retention period to 90 days directly reduces storage costs by automatically expiring logs after the compliance-required duration. This eliminates the cost of storing logs beyond 90 days, which was the primary driver of the higher-than-expected spend, while still retaining the data for the mandated period and allowing aggregated views via dashboards.

Exam trap

The trap here is that candidates may confuse log retention settings with log ingestion controls, mistakenly thinking that disabling alarms or changing log levels will reduce costs, when in fact the most direct and compliant cost-saving measure is to adjust the retention period.

How to eliminate wrong answers

Option B is wrong because disabling VPC Flow Logs stops the production of network-level logs, but the question states the team stores 'application logs' in CloudWatch Logs, not VPC Flow Logs; this action would not address the cost of existing application log ingestion and retention, and it would break compliance if those logs are required. Option C is wrong because increasing the logging level to DEBUG actually generates more log events per operation, not fewer, and batching does not reduce the number of events; it would increase costs due to higher ingestion volume. Option D is wrong because turning off CloudWatch alarms does not stop log ingestion; alarms are separate from log data ingestion and retention, so logs would continue to be ingested and stored, incurring the same costs.

Practice this question →

146

Multi-Selectmedium

A company runs a media transcoding service on Amazon EC2 instances behind an Application Load Balancer. The workload is steady at 60% CPU utilization from 08:00 to 18:00 local time on weekdays and drops to under 5% overnight and on weekends. A solutions architect must reduce compute costs without changing the application code or degrading transcoding throughput during peak hours. (Choose two.)

Select 2 answers

A.Replace all On-Demand instances with Spot Instances in a single Availability Zone.

B.Move the transcoding workload to a larger instance type so fewer instances are needed at peak.

C.Enable detailed CloudWatch monitoring at one-minute resolution for every instance in the group.

D.Configure a scheduled scaling action on the Auto Scaling group to reduce desired capacity outside the 08:00-18:00 weekday window.

E.Purchase a 1-year Compute Savings Plan covering the baseline instance usage that runs every day.

AnswersD, E

Because demand is highly predictable by time of day, a scheduled scaling action can lower the minimum and desired capacity during nights and weekends so the group stops paying for idle instances. This matches capacity to the known traffic pattern and works alongside a commitment-based discount that covers only the always-on baseline.

Why this answer

The workload has two distinct cost components: an always-on baseline and a predictable daily peak. A Compute Savings Plan discounts the continuous baseline usage across any instance family or Region, while scheduled scaling trims the fleet during the known low-traffic windows. Together they reduce spend without touching application code, preserving peak throughput, and avoiding the interruption risk that Spot would introduce.

Exam trap

The trap here is assuming that any commitment-based discount must cover the entire fleet, when in fact the optimal design commits only to the always-on baseline and lets scheduled scaling handle the variable portion.

Practice this question →

147

Multi-Selecthard

A log archive has old unattached EBS volumes and many stale snapshots. Which two actions reduce storage cost without affecting running instances? The architecture review board prefers a managed AWS-native control.

Select 2 answers

A.Stop all EC2 instances in the account

B.Disable CloudTrail logging

C.Delete unattached EBS volumes after verifying they are no longer needed

D.Apply snapshot lifecycle policies to expire obsolete snapshots

AnswersC, D

Unattached EBS volumes are billed as block storage regardless of whether they are mounted to a running instance. After confirming the volume is not needed for future use or as a boot source, deleting it releases the allocated storage and immediately stops accruing charges. For safety, you can first take a final snapshot, then delete the volume to preserve data recovery options without ongoing volume costs—this directly eliminates the recurring per-GiB-month expense for orphaned volumes.

Why this answer

Deleting unattached EBS volumes eliminates storage costs for volumes that are not in use, and since they are not attached to any running instance, this action does not affect running instances. Option D is correct because applying snapshot lifecycle policies (e.g., using Amazon Data Lifecycle Manager) automates the expiration of obsolete snapshots, reducing storage costs without impacting running instances. Both actions are managed AWS-native controls, aligning with the architecture review board's preference.

Exam trap

The trap here is that candidates may confuse stopping instances (which does not delete volumes) with deleting unattached volumes, or they may think disabling CloudTrail reduces storage costs, but CloudTrail logs are stored in S3 and are unrelated to EBS volume or snapshot storage charges.

Practice this question →

148

MCQmedium

A production log archive runs continuously on EC2 with predictable usage for the next three years. The team wants a discount while retaining some instance-family flexibility. What should they buy?

A.S3 Intelligent-Tiering

B.Dedicated Instances

C.Compute Savings Plan

D.Spot Instances only

AnswerC

A Compute Savings Plan commits to a fixed hourly spend for one or three years, applying discounted rates across EC2 instance families, sizes, and Regions, delivering the required discount while preserving the instance-family flexibility the team needs.

Why this answer

The Compute Savings Plan (C) is correct because it offers a discount (up to 66%) in exchange for a commitment to a consistent amount of compute usage (measured in $/hour) for a 1- or 3-year term, while allowing flexibility to change instance families, sizes, OS, tenancy, and even regions within EC2, Fargate, and Lambda. This matches the requirement of predictable usage for three years with instance-family flexibility, unlike Reserved Instances which lock to a specific instance family.

Exam trap

The trap here is that candidates often confuse Compute Savings Plans with Reserved Instances, assuming that any long-term discount requires locking into a specific instance family, but Compute Savings Plans provide both the discount and the flexibility to change instance families, which is the key differentiator tested in this question.

How to eliminate wrong answers

Option A is wrong because S3 Intelligent-Tiering is a storage class for objects in Amazon S3 that optimizes costs by moving data between access tiers based on changing access patterns; it has nothing to do with EC2 compute discounts or instance-family flexibility. Option B is wrong because Dedicated Instances are EC2 instances that run on hardware dedicated to a single customer, providing physical isolation but no discount or flexibility benefit; they are a billing/tenancy option, not a discount program. Option D is wrong because Spot Instances only offer significant discounts but are interruptible with a 2-minute termination notice, making them unsuitable for a production log archive that must run continuously for three years without interruption.

Practice this question →

149

MCQmedium

A media company runs a fleet of EC2 instances using Auto Scaling across multiple instance families (for example, m-series and c-series) in a single region. The business wants to commit to steady usage for one year to reduce cost, but the application team must retain flexibility to switch instance families and scale up/down as demand changes. They need the cost-reduction approach that best matches this flexibility. Which option is the best fit?

A.Purchase Standard Reserved Instances tied to a specific instance family and region, so the application can only run on the selected family.

B.Purchase Compute Savings Plans so the commitment applies regardless of instance family changes within the selected scope.

C.Purchase Spot Instances for all capacity and disable On-Demand fallback to guarantee the lowest cost.

D.Rely only on On-Demand and reduce cost by using a CloudFront-only approach for all dynamic content.

AnswerB

Compute Savings Plans provide discounted pricing in exchange for a 1-year or 3-year commitment, while allowing flexibility across instance families/attributes within the scope (for example, region/account and covered usage). This aligns with Auto Scaling that may shift between instance families while maintaining steady overall compute usage.

Why this answer

Compute Savings Plans provide the most flexibility because they apply to any EC2 instance family (including m-series and c-series) within a region, automatically adjusting to instance family changes and scaling. This matches the requirement to commit to steady usage for one year while retaining the ability to switch families and scale up/down, offering up to 66% savings over On-Demand without locking the application to a specific instance type.

Exam trap

The trap here is that candidates often confuse Reserved Instances (which lock to a specific family) with Savings Plans (which offer family flexibility), leading them to choose Option A despite the requirement for instance family switching.

How to eliminate wrong answers

Option A is wrong because Standard Reserved Instances are tied to a specific instance family (e.g., m5.large) and region, which would prevent the application from switching to a different instance family (e.g., c-series) without incurring additional On-Demand costs or modification fees. Option C is wrong because Spot Instances can be interrupted with a 2-minute warning, making them unsuitable as the sole capacity source for a production workload that requires reliability; disabling On-Demand fallback would risk application downtime during Spot reclaimations. Option D is wrong because CloudFront is a content delivery network that caches static and dynamic content at edge locations, but it does not reduce the cost of running EC2 instances for compute workloads; relying solely on On-Demand without a commitment discount would not achieve the desired cost reduction.

Practice this question →

150

Multi-Selecthard

A solutions architect is reviewing a workload that runs on a fleet of Amazon EC2 instances in a single AWS Region. The application serves a global user base, and the team wants to reduce both data transfer costs and latency for users in Europe and Asia. The application is stateless and stores assets in Amazon S3. The team is also evaluating how to pay for the compute layer over the next three years, as usage is expected to be steady. Which two actions will reduce cost in this scenario? (Choose two.)

Select 2 answers

A.Enable S3 Transfer Acceleration on the bucket and direct all user downloads through the accelerated endpoint.

B.Purchase a three-year Compute Savings Plan with a full upfront payment for the EC2 compute.

C.Deploy an Amazon CloudFront distribution with the S3 bucket as the origin to cache assets at edge locations.

D.Move the S3 bucket to a Region closer to the European users and replicate back to the original Region.

E.Convert the EC2 instances to Spot Instances to eliminate compute charges entirely.

AnswersB, C

A Compute Savings Plan commits to a consistent amount of compute usage in exchange for a discount of up to 66 percent compared with On-Demand, and the longer the term and the larger the upfront payment, the greater the discount. Because usage is expected to be steady for three years, this commitment matches the demand and lowers the effective hourly cost of the fleet.

Why this answer

The workload has two distinct cost drivers: global asset delivery and steady compute. Caching assets at CloudFront edge locations reduces origin egress and internet transfer while improving latency for distant users. For the compute layer, a three-year Compute Savings Plan matches the expected steady usage and applies a significant discount over On-Demand.

Together these address both transfer and compute costs without sacrificing availability.

Exam trap

The trap here is treating S3 Transfer Acceleration as a cost-saving feature, when it actually adds a per-gigabyte charge on top of normal transfer and is intended for upload speed, not cheap global read delivery.

Practice this question →