How should I use these Design Cost-Optimized Architectures practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

SAA-C03 · topic practice

Design Cost-Optimized Architectures practice questions

Q: Can I practise just Design Cost-Optimized Architectures questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Design Cost-Optimized Architectures domain.

Use this page to practise Design Cost-Optimized Architectures questions for this certification. Focus on how the exam tests design cost-optimized architectures in scenario format — understanding the why behind each answer builds more durable knowledge than memorising options.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Reviewed byJohnson Ajibi· MSc IT Security

20 questionsDomain: Design Cost-Optimized Architectures

Practice 10 questions Browse domain →

What the exam tests

What to know about Design Cost-Optimized Architectures

Design Cost-Optimized Architectures questions on this certification test your ability to deploy and manage design cost-optimized architectures concepts in scenario-based situations.

Core Design Cost-Optimized Architectures concepts and how they apply in real-world cloud scenarios.

How to deploy design cost-optimized architectures correctly and verify the outcome.

Troubleshooting design cost-optimized architectures issues by interpreting error output and system state.

Cloud best practices and Design Cost-Optimized Architectures design trade-offs tested by this certification.

Watch out for

Common Design Cost-Optimized Architectures exam traps

▸Selecting the most expensive service when a simpler managed option meets the requirement.
▸Forgetting that cloud resources must be explicitly secured — defaults are rarely secure.
▸Choosing a global service fix when the issue is region-specific.
▸Overlooking cost implications of cross-region data transfer in architecture questions.

Practice set

Design Cost-Optimized Architectures questions

20 questions · select your answer, then reveal the explanation

Question 1easymultiple choice

Read the full Design Cost-Optimized Architectures explanation →

You store application logs in an S3 bucket. After 30 days, the logs are rarely accessed, but you must retain them for 1 year for compliance. Which S3 feature is the best way to reduce storage cost while meeting the retention requirement?

Trap 1: Keep all logs in S3 Standard and rely on lower request rates to…

Request rate does not offset storage cost differences between storage classes. Keeping everything in S3 Standard is usually the most expensive option for long-term retention, even if objects are accessed rarely.

Trap 2: Copy logs to EBS snapshots each week and delete the original files

EBS snapshots are intended for backing up block storage (EBS volumes). They are not the best tool for application log retention in S3 and typically add unnecessary operational complexity and retention management overhead.

Trap 3: Use S3 replication to a second bucket in another region to reduce…

Replication is meant for redundancy and cross-region availability. It generally increases cost due to replication requests and storing data in another region; it does not reduce storage-class cost for the primary copy.

Study all Design Cost-Optimized Architectures common traps →

A
Create an S3 lifecycle rule to transition older objects to a colder storage class after 30 days, then expire after 1 year
S3 lifecycle policies can automatically transition objects to lower-cost storage classes based on age. Transitioning after 30 days reduces ongoing storage costs because the logs are rarely accessed, while expiring after 1 year ensures you still meet the compliance retention window.
B
Keep all logs in S3 Standard and rely on lower request rates to reduce cost
Why wrong: Request rate does not offset storage cost differences between storage classes. Keeping everything in S3 Standard is usually the most expensive option for long-term retention, even if objects are accessed rarely.
C
Copy logs to EBS snapshots each week and delete the original files
Why wrong: EBS snapshots are intended for backing up block storage (EBS volumes). They are not the best tool for application log retention in S3 and typically add unnecessary operational complexity and retention management overhead.
D
Use S3 replication to a second bucket in another region to reduce costs
Why wrong: Replication is meant for redundancy and cross-region availability. It generally increases cost due to replication requests and storing data in another region; it does not reduce storage-class cost for the primary copy.

Full breakdown with real-world context →

Question 2easymultiple choice

Read the full Design Cost-Optimized Architectures explanation →

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

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

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

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

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

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

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

Study all Design Cost-Optimized Architectures common traps →

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

Full breakdown with real-world context →

Question 3mediummulti select

Read the full Design Cost-Optimized Architectures explanation →

A marketing site serves versioned JavaScript and CSS files from Amazon S3 through CloudFront. The origin bill is rising because CloudFront keeps fetching the same files too often, and the application never changes a file at the same URL once it is published. Which two changes should you make? Select two.

Trap 1: Move the static assets to an EC2 web server behind an Application…

This adds infrastructure cost and operational overhead without addressing the root cause of the problem. The issue is poor cache efficiency, not the inability of S3 to serve the files.

Trap 2: Disable CloudFront caching so every request always reaches the…

Disabling caching would increase origin traffic and make the bill worse. The scenario specifically needs fewer origin fetches, so this is the opposite of the desired outcome.

Trap 3: Add more viewer-facing headers to the cache key so each browser…

Expanding the cache key usually lowers the hit rate because more requests become unique. That increases origin traffic and defeats the purpose of using CloudFront to reduce cost.

Study all Design Cost-Optimized Architectures common traps →

A
Set long-lived Cache-Control headers, such as a high max-age and immutable policy, on the versioned assets.
Versioned assets are ideal for long cache lifetimes because their URLs change when the content changes. Strong Cache-Control headers let CloudFront serve more requests from edge locations instead of repeatedly fetching the same files from S3.
B
Configure the CloudFront cache policy to avoid forwarding unnecessary query strings, headers, and cookies.
A smaller cache key improves the cache hit rate because more viewer requests map to the same cached object. Avoiding unnecessary request attributes also reduces origin fetches and lowers the bandwidth sent to the origin.
C
Move the static assets to an EC2 web server behind an Application Load Balancer.
Why wrong: This adds infrastructure cost and operational overhead without addressing the root cause of the problem. The issue is poor cache efficiency, not the inability of S3 to serve the files.
D
Disable CloudFront caching so every request always reaches the origin.
Why wrong: Disabling caching would increase origin traffic and make the bill worse. The scenario specifically needs fewer origin fetches, so this is the opposite of the desired outcome.
E
Add more viewer-facing headers to the cache key so each browser variation gets a unique cached object.
Why wrong: Expanding the cache key usually lowers the hit rate because more requests become unique. That increases origin traffic and defeats the purpose of using CloudFront to reduce cost.

Full breakdown with real-world context →

Question 4easymultiple choice

Read the full Design Cost-Optimized Architectures explanation →

An application serves static images through Amazon CloudFront. The team observes higher-than-expected origin fetches, which increases origin bandwidth costs. Which change most directly improves CloudFront cache reuse to reduce origin requests for the static content?

Trap 1: Disable caching for the distribution so every request goes back to…

Disabling caching prevents CloudFront from serving cached responses, which increases origin fetch frequency and typically increases cost and latency.

Trap 2: Configure CloudFront to forward all request headers and query…

Forwarding headers/query strings increases the number of distinct cache keys, which lowers cache hit ratio and increases the number of cache misses and origin fetches.

Trap 3: Move the S3 bucket to a different AWS Region, without changing…

Changing the bucket region may affect latency, but it does not directly change cache key behavior or cache TTL. If CloudFront caching behavior is unchanged, it typically will not most directly reduce origin fetches.

Study all Design Cost-Optimized Architectures common traps →

A
Set appropriate Cache-Control headers (or origin cache settings) so CloudFront caches responses longer
Cache headers and TTL determine how long objects are kept in CloudFront’s edge caches. Longer caching for static assets increases the cache hit ratio, reducing how often requests must go back to the origin.
B
Disable caching for the distribution so every request goes back to the origin
Why wrong: Disabling caching prevents CloudFront from serving cached responses, which increases origin fetch frequency and typically increases cost and latency.
C
Configure CloudFront to forward all request headers and query strings to the origin
Why wrong: Forwarding headers/query strings increases the number of distinct cache keys, which lowers cache hit ratio and increases the number of cache misses and origin fetches.
D
Move the S3 bucket to a different AWS Region, without changing CloudFront caching behavior
Why wrong: Changing the bucket region may affect latency, but it does not directly change cache key behavior or cache TTL. If CloudFront caching behavior is unchanged, it typically will not most directly reduce origin fetches.

Full breakdown with real-world context →

Question 5easymultiple choice

Read the full NAT/PAT explanation →

Your team runs a batch processing workload on EC2 that can tolerate interruptions. If an instance is terminated, the job can restart from checkpoints. To reduce compute costs, what is the most cost-optimized approach?

Trap 1: Use Dedicated Hosts to ensure capacity for the cheapest instance

Dedicated Hosts are primarily for controlling instance placement and meeting specific licensing/host requirements. They do not target the interruption-tolerant pricing model that makes Spot cost-optimized for interruptible batch workloads.

Trap 2: Use On-Demand instances and schedule extra runs to offset…

On-Demand is typically more expensive than Spot. Scheduling extra runs increases total compute time/usage, which can increase costs rather than reduce them, even if it helps handle interruptions.

Trap 3: Use Reserved Instances only, because they eliminate instance…

Reserved Instances discount On-Demand pricing but do not eliminate all termination/interruption scenarios and do not provide the same level of discounting as Spot for workloads that can handle interruptions. This does not leverage the interruption tolerance that would enable the most cost savings.

Study all Design Cost-Optimized Architectures common traps →

A
Use EC2 Spot Instances for the batch workers
Spot provides significantly lower pricing than On-Demand for interruptible workloads. Because the workload can restart from checkpoints, termination interruptions are acceptable and the application can recover efficiently, meeting both correctness and throughput requirements at a lower cost.
B
Use Dedicated Hosts to ensure capacity for the cheapest instance
Why wrong: Dedicated Hosts are primarily for controlling instance placement and meeting specific licensing/host requirements. They do not target the interruption-tolerant pricing model that makes Spot cost-optimized for interruptible batch workloads.
C
Use On-Demand instances and schedule extra runs to offset interruptions
Why wrong: On-Demand is typically more expensive than Spot. Scheduling extra runs increases total compute time/usage, which can increase costs rather than reduce them, even if it helps handle interruptions.
D
Use Reserved Instances only, because they eliminate instance termination events
Why wrong: Reserved Instances discount On-Demand pricing but do not eliminate all termination/interruption scenarios and do not provide the same level of discounting as Spot for workloads that can handle interruptions. This does not leverage the interruption tolerance that would enable the most cost savings.

Full breakdown with real-world context →

Question 6mediummulti select

Read the full Design Cost-Optimized Architectures explanation →

An internal rendering job runs on EC2 workers in an Auto Scaling group. Each job writes checkpoints every few minutes to S3 and can resume from the latest checkpoint after an interruption. The queue depth varies sharply, and the team wants the lowest possible compute cost. Which two changes should they make? Select two.

Trap 1: Purchase Dedicated Hosts so the fleet keeps physical servers…

Dedicated Hosts add isolation and license control, but they are typically far more expensive than flexible capacity options. They are not the best choice when the primary goal is minimizing cost.

Trap 2: Run the entire fleet on On-Demand Instances to avoid any…

On-Demand is simpler, but it costs more than Spot and does not address the requirement to minimize compute spend. The scenario already states the workload can recover from interruption.

Trap 3: Move the workers to AWS Outposts to keep compute close to the data.

Outposts is useful for hybrid locality or on-premises requirements, but it is not a cost-minimization choice for a cloud batch workload. It adds infrastructure commitment instead of lowering the bill.

Study all Design Cost-Optimized Architectures common traps →

A
Run the worker fleet on EC2 Spot Instances.
Spot Instances usually provide the lowest EC2 compute price and fit workloads that can tolerate interruption. Because the job checkpoints to S3, the application can resume after Spot interruptions without losing all progress.
B
Purchase Dedicated Hosts so the fleet keeps physical servers reserved for the workload.
Why wrong: Dedicated Hosts add isolation and license control, but they are typically far more expensive than flexible capacity options. They are not the best choice when the primary goal is minimizing cost.
C
Use a Mixed Instances Policy with several compatible instance types and Spot capacity-optimized allocation.
Diversifying instance types improves the chance that Auto Scaling can obtain cheap Spot capacity. A mixed policy also reduces the risk of a single instance type shortage stopping the job fleet.
D
Run the entire fleet on On-Demand Instances to avoid any interruption risk.
Why wrong: On-Demand is simpler, but it costs more than Spot and does not address the requirement to minimize compute spend. The scenario already states the workload can recover from interruption.
E
Move the workers to AWS Outposts to keep compute close to the data.
Why wrong: Outposts is useful for hybrid locality or on-premises requirements, but it is not a cost-minimization choice for a cloud batch workload. It adds infrastructure commitment instead of lowering the bill.

Full breakdown with real-world context →

Question 7easymultiple choice

Read the full Design Cost-Optimized Architectures explanation →

A company has a steady, predictable workload that must run continuously (24/7) in a single AWS Region. The team wants the lowest cost option available for this steady usage, but also expects they may choose different EC2 instance families in the future (without re-buying compute discounts). Which AWS purchase option best meets these goals?

Trap 1: On-Demand Instances only, because they automatically adjust to…

On-Demand Instances provide flexibility, but they do not offer discounted pricing through a commitment. For a predictable 24/7 workload, a commitment-based option (Savings Plans or Reserved Instances) is typically required to achieve the lowest cost.

Trap 2: Standard Reserved Instances tied to a single instance type and…

Standard Reserved Instances can be discounted, but they are much less flexible for changing instance families. If you switch to different instance types/families over time, you may not be covered by the original RI (or you would need exchanges that may reduce the economic benefit).

Trap 3: EC2 Spot Instances, because they are always cheaper than savings…

Spot Instances can be cheaper, but their price is variable and capacity can be reclaimed, causing interruptions. For a workload required to run continuously (24/7), Spot is generally not the best fit unless the architecture can tolerate termination and the business requirements allow interruption.

Study all Design Cost-Optimized Architectures common traps →

A
On-Demand Instances only, because they automatically adjust to future needs
Why wrong: On-Demand Instances provide flexibility, but they do not offer discounted pricing through a commitment. For a predictable 24/7 workload, a commitment-based option (Savings Plans or Reserved Instances) is typically required to achieve the lowest cost.
B
Compute Savings Plans, committed for a 1- to 3-year term in the Region
Compute Savings Plans provide discounted pricing in exchange for committing to a consistent hourly spend (scoped to a Region). They apply to EC2 usage and are flexible enough that you can change EC2 instance families over time while still receiving the Savings Plans discount within the commitment scope.
C
Standard Reserved Instances tied to a single instance type and Availability Zone
Why wrong: Standard Reserved Instances can be discounted, but they are much less flexible for changing instance families. If you switch to different instance types/families over time, you may not be covered by the original RI (or you would need exchanges that may reduce the economic benefit).
D
EC2 Spot Instances, because they are always cheaper than savings programs
Why wrong: Spot Instances can be cheaper, but their price is variable and capacity can be reclaimed, causing interruptions. For a workload required to run continuously (24/7), Spot is generally not the best fit unless the architecture can tolerate termination and the business requirements allow interruption.

Full breakdown with real-world context →

Question 8hardmatching

Read the full NAT/PAT explanation →

Match each data-retention scenario to the most cost-effective Amazon S3 storage class. Assume the retrieval pattern and access-latency requirement are the most important constraints.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Amazon S3 Standard

Amazon S3 Standard-IA

Amazon S3 Glacier Instant Retrieval

Amazon S3 Glacier Deep Archive

Question 9easymultiple choice

Read the full Design Cost-Optimized Architectures explanation →

A web service runs continuously on AWS 24/7. The team expects steady compute usage for the next 12–24 months, but may change instance families/sizes as performance tuning continues. Which purchase option best reduces cost while keeping flexibility to change instance types?

Trap 1: Buy EC2 On-Demand instances and rely on future Spot capacity for…

On-Demand pricing has no commitment-based discount, so a steady 24/7 workload generally remains costly. Relying on future Spot capacity does not match the predictable continuous demand and may also introduce interruptions unless the architecture is designed for them.

Trap 2: Buy Reserved Instances with a fixed instance type and region

Instance-specific Reserved Instances discount On-Demand but require matching the specified instance family/size and scope constraints. Frequent changes to instance families/sizes can reduce or prevent using the committed discount effectively.

Trap 3: Buy Spot Instances and stop scaling to avoid interruption risk

Spot provides lower pricing but can be interrupted when capacity is reclaimed. Stopping scaling does not remove interruption risk; it only changes how capacity is adjusted. For a 24/7 service, this can still cause outages unless substantial fault-tolerance is built.

Study all Design Cost-Optimized Architectures common traps →

A
Buy EC2 On-Demand instances and rely on future Spot capacity for discounts
Why wrong: On-Demand pricing has no commitment-based discount, so a steady 24/7 workload generally remains costly. Relying on future Spot capacity does not match the predictable continuous demand and may also introduce interruptions unless the architecture is designed for them.
B
Use Compute Savings Plans for the expected steady usage
Compute Savings Plans provide a discounted hourly rate in exchange for a commitment. They are the most flexible Savings Plans option and can apply across EC2 usage regardless of instance family or size changes, so the team can continue tuning instance types while still receiving discounted pricing for the committed usage.
C
Buy Reserved Instances with a fixed instance type and region
Why wrong: Instance-specific Reserved Instances discount On-Demand but require matching the specified instance family/size and scope constraints. Frequent changes to instance families/sizes can reduce or prevent using the committed discount effectively.
D
Buy Spot Instances and stop scaling to avoid interruption risk
Why wrong: Spot provides lower pricing but can be interrupted when capacity is reclaimed. Stopping scaling does not remove interruption risk; it only changes how capacity is adjusted. For a 24/7 service, this can still cause outages unless substantial fault-tolerance is built.

Full breakdown with real-world context →

Question 10hardmatching

Read the full Design Cost-Optimized Architectures explanation →

Match each workload to the AWS pricing option that most directly minimizes cost while still meeting the stated flexibility requirements. Use each option once.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Compute Savings Plan

Standard Reserved Instance

Spot Instances

On-Demand Instances

Question 11easymultiple choice

Read the full Design Cost-Optimized Architectures explanation →

A team stores application logs in Amazon S3. They need access to the logs only occasionally for troubleshooting (infrequent access), and they want to reduce storage cost automatically over time without manually moving objects. What should they implement?

Trap 1: An S3 lifecycle policy that deletes objects after 1 day to…

Deleting after 1 day would remove data before it can be used for occasional troubleshooting. Storage cost optimization must still respect retention and troubleshooting requirements; lifecycle rules should transition to cheaper classes rather than delete immediately unless deletion is explicitly acceptable.

Trap 2: An S3 lifecycle policy that keeps all objects in S3 Standard and…

Staying in S3 Standard does not address the cost driver (storage class pricing based on access frequency). “Compression at read time” is not an S3 lifecycle storage class optimization mechanism and would not directly lower S3 storage class charges as requested.

Trap 3: A policy that changes bucket encryption from SSE-S3 to SSE-KMS to…

Changing encryption type affects security and KMS key usage, not the fundamental S3 storage class pricing model. It is not a reliable method to reduce storage costs for infrequent access workloads.

Study all Design Cost-Optimized Architectures common traps →

A
An S3 lifecycle policy that transitions objects to a lower-cost storage class after a set number of days
S3 lifecycle policies can automatically transition objects based on age to storage classes priced for infrequent access (for example, Standard-IA or Glacier-based classes). This preserves the data for later troubleshooting while lowering storage cost as objects become older.
B
An S3 lifecycle policy that deletes objects after 1 day to eliminate storage costs
Why wrong: Deleting after 1 day would remove data before it can be used for occasional troubleshooting. Storage cost optimization must still respect retention and troubleshooting requirements; lifecycle rules should transition to cheaper classes rather than delete immediately unless deletion is explicitly acceptable.
C
An S3 lifecycle policy that keeps all objects in S3 Standard and only applies compression at read time
Why wrong: Staying in S3 Standard does not address the cost driver (storage class pricing based on access frequency). “Compression at read time” is not an S3 lifecycle storage class optimization mechanism and would not directly lower S3 storage class charges as requested.
D
A policy that changes bucket encryption from SSE-S3 to SSE-KMS to reduce storage cost
Why wrong: Changing encryption type affects security and KMS key usage, not the fundamental S3 storage class pricing model. It is not a reliable method to reduce storage costs for infrequent access workloads.

Full breakdown with real-world context →

Question 12easymultiple choice

Read the full Design Cost-Optimized Architectures explanation →

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?

Trap 1: Disable CloudFront caching so every request goes back to S3 for the…

Disabling caching forces CloudFront to treat every request as a miss and fetch from the origin each time. This increases origin fetch volume and typically increases both latency and origin bandwidth cost.

Trap 2: Route users directly to the S3 website endpoint to bypass CloudFront

Bypassing CloudFront removes edge caching and shifts traffic directly to S3. That typically increases latency and increases the amount of data transferred to the origin rather than reducing origin fetches.

Trap 3: Turn on a NAT Gateway for the CloudFront origin to reduce bandwidth…

NAT Gateways affect outbound traffic from instances in private subnets. CloudFront-to-origin caching behavior is not controlled by NAT Gateway settings, so this would not improve CloudFront cache hit rate or reduce origin fetches.

Study all Design Cost-Optimized Architectures common traps →

A
Configure CloudFront caching by setting appropriate cache-control headers and/or CloudFront cache policy/TTL values for the static objects
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.
B
Disable CloudFront caching so every request goes back to S3 for the latest image
Why wrong: Disabling caching forces CloudFront to treat every request as a miss and fetch from the origin each time. This increases origin fetch volume and typically increases both latency and origin bandwidth cost.
C
Route users directly to the S3 website endpoint to bypass CloudFront
Why wrong: Bypassing CloudFront removes edge caching and shifts traffic directly to S3. That typically increases latency and increases the amount of data transferred to the origin rather than reducing origin fetches.
D
Turn on a NAT Gateway for the CloudFront origin to reduce bandwidth charges
Why wrong: NAT Gateways affect outbound traffic from instances in private subnets. CloudFront-to-origin caching behavior is not controlled by NAT Gateway settings, so this would not improve CloudFront cache hit rate or reduce origin fetches.

Full breakdown with real-world context →

Question 13hardmatching

Read the full Design Cost-Optimized Architectures explanation →

Match each workload to the most cost-effective compute model or service choice. Focus on how often the workload runs, whether it is interruption-tolerant, and how much administration the team wants to avoid.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

AWS Lambda

Amazon ECS on AWS Fargate

EC2 Spot Instances

EC2 On-Demand Instances

Question 14mediummulti select

Read the full NAT/PAT explanation →

A service in private subnets downloads product images from Amazon S3 and stores job state in DynamoDB. A NAT Gateway is currently the only route to AWS services, and the monthly bill is dominated by NAT data processing charges. Which two changes will most directly reduce that cost? Select two.

Trap 1: Add an internet gateway and move the instances into public subnets.

This changes the routing model and security exposure, but it does not reduce the amount of traffic the application sends to AWS services. It also does nothing to remove NAT-related charges for private service access.

Trap 2: Replace the NAT Gateway with a Site-to-Site VPN connection.

A VPN is meant for connectivity to on-premises or external networks. It does not eliminate the need to reach S3 and DynamoDB privately, so it does not directly solve the NAT data-processing-cost problem.

Trap 3: Create an interface endpoint for S3 instead of a gateway endpoint.

An interface endpoint can work for some S3 use cases, but it adds hourly and data-processing charges. For the specific goal of lowering NAT charges for S3 access from private subnets, the S3 gateway endpoint is the lower-cost choice.

Study all Design Cost-Optimized Architectures common traps →

A
Create a gateway VPC endpoint for Amazon S3.
An S3 gateway endpoint routes S3 traffic over the AWS private network instead of through the NAT Gateway. That removes NAT data processing charges for the S3 downloads and is one of the most direct cost optimizations for private-subnet workloads.
B
Create a gateway VPC endpoint for Amazon DynamoDB.
DynamoDB also supports a gateway endpoint, which keeps table traffic off the NAT Gateway path. Using the endpoint avoids both NAT data processing fees and the need to hairpin private AWS API calls through internet egress.
C
Add an internet gateway and move the instances into public subnets.
Why wrong: This changes the routing model and security exposure, but it does not reduce the amount of traffic the application sends to AWS services. It also does nothing to remove NAT-related charges for private service access.
D
Replace the NAT Gateway with a Site-to-Site VPN connection.
Why wrong: A VPN is meant for connectivity to on-premises or external networks. It does not eliminate the need to reach S3 and DynamoDB privately, so it does not directly solve the NAT data-processing-cost problem.
E
Create an interface endpoint for S3 instead of a gateway endpoint.
Why wrong: An interface endpoint can work for some S3 use cases, but it adds hourly and data-processing charges. For the specific goal of lowering NAT charges for S3 access from private subnets, the S3 gateway endpoint is the lower-cost choice.

Full breakdown with real-world context →

Question 15hardmatching

Read the full Design Cost-Optimized Architectures explanation →

Match each private-networking or content-delivery scenario to the AWS feature that most directly reduces cost while meeting the connectivity requirement.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Gateway VPC endpoint

Interface VPC endpoint (AWS PrivateLink)

CloudFront with versioned objects and a long cache TTL

CloudFront Origin Shield

Question 16easymultiple choice

Read the full NAT/PAT explanation →

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?

Trap 1: EC2 On-Demand Instances to avoid interruptions

On-Demand avoids interruption risk, but the cost is typically higher than Spot. Because your design explicitly supports restart from checkpoints, you can accept interruptions to gain Spot’s pricing advantage.

Trap 2: Savings Plans to guarantee capacity for the entire year

Savings Plans provide discounted pricing based on usage commitment, but they do not guarantee Spot-like interruption behavior and they do not specifically address the interruption-tolerant execution model. Since your main lever for maximum savings here is accepting interruption for lower Spot pricing, Savings Plans are not the best fit.

Trap 3: Reserved Instances with no interruption handling

Reserved Instances reduce cost compared to On-Demand, but they still assume more stable capacity usage. They are not the best choice when interruptions are acceptable and you can directly use Spot’s lower interrupted pricing with checkpoint recovery.

Study all Design Cost-Optimized Architectures common traps →

A
EC2 On-Demand Instances to avoid interruptions
Why wrong: On-Demand avoids interruption risk, but the cost is typically higher than Spot. Because your design explicitly supports restart from checkpoints, you can accept interruptions to gain Spot’s pricing advantage.
B
EC2 Spot Instances with checkpoint-based interruption handling
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.
C
Savings Plans to guarantee capacity for the entire year
Why wrong: Savings Plans provide discounted pricing based on usage commitment, but they do not guarantee Spot-like interruption behavior and they do not specifically address the interruption-tolerant execution model. Since your main lever for maximum savings here is accepting interruption for lower Spot pricing, Savings Plans are not the best fit.
D
Reserved Instances with no interruption handling
Why wrong: Reserved Instances reduce cost compared to On-Demand, but they still assume more stable capacity usage. They are not the best choice when interruptions are acceptable and you can directly use Spot’s lower interrupted pricing with checkpoint recovery.

Full breakdown with real-world context →

Question 17mediummulti select

Read the full NAT/PAT explanation →

A containerized service runs in private subnets and retrieves secrets from AWS Secrets Manager and configuration parameters from AWS Systems Manager Parameter Store on startup. A NAT Gateway is currently used only for these AWS API calls, and the security team wants to eliminate that recurring charge. Which two endpoints should be added? Select two.

Trap 1: Create a gateway VPC endpoint for Amazon S3 instead.

An S3 gateway endpoint is useful when workloads need private access to S3, but this startup path is for Secrets Manager and Parameter Store. Adding S3 endpoints would not remove the NAT charges described in the scenario.

Trap 2: Add an Internet Gateway and send the traffic through public subnets.

That would expose the service to the internet and does not reduce outbound traffic cost. The requirement is to keep the workload private and remove the need for NAT while still reaching AWS services.

Trap 3: Replace the NAT Gateway with a NAT instance.

A NAT instance can sometimes reduce cost, but it still requires an egress path and adds patching, scaling, and availability management. It does not eliminate the AWS API traffic cost the way the right VPC endpoints do.

Study all Design Cost-Optimized Architectures common traps →

A
Create an interface VPC endpoint for AWS Secrets Manager.
Secrets Manager uses an interface endpoint in a private-subnet design. That keeps startup traffic off the NAT Gateway while still letting the service retrieve secrets privately over the AWS network.
B
Create an interface VPC endpoint for AWS Systems Manager.
Systems Manager provides the API path used by Parameter Store. Adding the interface endpoint removes those configuration lookups from the NAT path and directly lowers recurring NAT charges.
C
Create a gateway VPC endpoint for Amazon S3 instead.
Why wrong: An S3 gateway endpoint is useful when workloads need private access to S3, but this startup path is for Secrets Manager and Parameter Store. Adding S3 endpoints would not remove the NAT charges described in the scenario.
D
Add an Internet Gateway and send the traffic through public subnets.
Why wrong: That would expose the service to the internet and does not reduce outbound traffic cost. The requirement is to keep the workload private and remove the need for NAT while still reaching AWS services.
E
Replace the NAT Gateway with a NAT instance.
Why wrong: A NAT instance can sometimes reduce cost, but it still requires an egress path and adds patching, scaling, and availability management. It does not eliminate the AWS API traffic cost the way the right VPC endpoints do.

Full breakdown with real-world context →

Question 18mediummulti select

Read the full Design Cost-Optimized Architectures explanation →

A line-of-business application runs on EC2 instances 24/7 with predictable usage for the next year. The application will stay in the same Region, and the team does not want to manage capacity interruptions. Which two purchase options can reduce cost compared with pure On-Demand pricing? Select two.

Trap 1: Move the fleet to Spot Instances.

Spot Instances can be much cheaper, but they may be interrupted when spare capacity is reclaimed. That directly conflicts with the requirement to avoid capacity interruptions for a continuously running application.

Trap 2: Use Dedicated Hosts to reserve physical servers for the application.

Dedicated Hosts are typically chosen for licensing or isolation requirements, not for the lowest general-purpose compute price. They usually cost more than commitment-based pricing options for a normal steady-state workload.

Trap 3: Stay entirely on On-Demand Instances because they are already the…

On-Demand provides the highest flexibility, but it is not the lowest-cost model for predictable 24/7 usage. The scenario explicitly calls for reducing cost, which requires a commitment-based discount.

Study all Design Cost-Optimized Architectures common traps →

A
Buy Compute Savings Plans for the expected steady usage.
Compute Savings Plans reduce the hourly cost of predictable usage while preserving flexibility across supported compute services. They are a strong fit when the workload is steady and the team wants savings without interruption risk.
B
Purchase Standard Reserved Instances for the EC2 fleet.
Standard Reserved Instances are designed for steady EC2 usage in a specific Region and can significantly lower the effective hourly rate versus On-Demand. They align well with a one-year predictable workload that must remain continuously available.
C
Move the fleet to Spot Instances.
Why wrong: Spot Instances can be much cheaper, but they may be interrupted when spare capacity is reclaimed. That directly conflicts with the requirement to avoid capacity interruptions for a continuously running application.
D
Use Dedicated Hosts to reserve physical servers for the application.
Why wrong: Dedicated Hosts are typically chosen for licensing or isolation requirements, not for the lowest general-purpose compute price. They usually cost more than commitment-based pricing options for a normal steady-state workload.
E
Stay entirely on On-Demand Instances because they are already the cheapest option.
Why wrong: On-Demand provides the highest flexibility, but it is not the lowest-cost model for predictable 24/7 usage. The scenario explicitly calls for reducing cost, which requires a commitment-based discount.

Full breakdown with real-world context →

Question 19mediummulti select

Read the full Design Cost-Optimized Architectures explanation →

A compliance archive writes one log file per day to Amazon S3. The logs are almost never accessed after day 30, but if they are needed they must still be retrievable in milliseconds. They must be deleted automatically after one year. Which two lifecycle settings should you apply? Select two.

Trap 1: Transition the objects to S3 Standard-IA after 30 days.

Standard-IA is a valid infrequent-access class, but it is typically more expensive than Glacier Instant Retrieval for data that is rarely read. Since the question explicitly asks for the most cost-optimized choice while preserving immediate retrieval, this is not the best answer.

Trap 2: Keep the logs in S3 Standard indefinitely and delete them manually…

S3 Standard is unnecessary for data that becomes rarely accessed after 30 days, so it wastes storage cost over the remaining retention period. Manual deletion also weakens compliance controls and increases operational overhead.

Trap 3: Replicate the logs to another Region for cheaper archival storage.

Cross-Region replication adds storage and inter-Region data transfer cost. It does not reduce the cost of the retention policy described in the scenario and is not needed to meet the archive requirement.

Study all Design Cost-Optimized Architectures common traps →

A
Transition the objects to S3 Glacier Instant Retrieval after 30 days.
Glacier Instant Retrieval is designed for data that is rarely accessed but still needs millisecond retrieval. Because the logs remain in the archive for 11 more months, the 90-day minimum storage duration is not a problem, and the storage cost is lower than keeping them in a hotter class.
B
Expire the objects after 365 days.
Lifecycle expiration enforces the one-year retention requirement automatically and prevents paying for storage beyond the compliance window. It also removes the operational risk of manual deletion.
C
Transition the objects to S3 Standard-IA after 30 days.
Why wrong: Standard-IA is a valid infrequent-access class, but it is typically more expensive than Glacier Instant Retrieval for data that is rarely read. Since the question explicitly asks for the most cost-optimized choice while preserving immediate retrieval, this is not the best answer.
D
Keep the logs in S3 Standard indefinitely and delete them manually when needed.
Why wrong: S3 Standard is unnecessary for data that becomes rarely accessed after 30 days, so it wastes storage cost over the remaining retention period. Manual deletion also weakens compliance controls and increases operational overhead.
E
Replicate the logs to another Region for cheaper archival storage.
Why wrong: Cross-Region replication adds storage and inter-Region data transfer cost. It does not reduce the cost of the retention policy described in the scenario and is not needed to meet the archive requirement.

Full breakdown with real-world context →

Question 20easymultiple choice

Read the full NAT/PAT explanation →

A workload runs in private subnets. It must access AWS services such as Amazon S3, but the company wants to avoid using a NAT Gateway to reduce outbound networking costs. What is the best solution?

Trap 1: Attach Elastic IP addresses to instances in private subnets

Elastic IP addresses require public networking. They do not provide a NAT-less path to AWS service APIs from a purely private subnet, and they do not achieve the cost-avoidance goal described.

Trap 2: Install a NAT Gateway in every subnet to minimize routing hops

Adding more NAT Gateways increases cost rather than avoiding it. The requirement is specifically to eliminate NAT Gateway usage for accessing AWS services.

Trap 3: Open outbound internet access with a security group rule to reach…

Reaching AWS service endpoints via the internet typically reintroduces outbound connectivity (and associated data-transfer costs and security considerations). It also does not provide the NAT-avoidance behavior of VPC endpoints for private access to AWS services.

Study all Design Cost-Optimized Architectures common traps →

A
Create VPC endpoints for the required AWS services and route traffic to them
VPC endpoints provide private connectivity from your VPC to supported AWS services without traversing the public internet or a NAT Gateway. For example, you can use a gateway endpoint for S3 (and interface endpoints for other services where supported), which avoids NAT Gateway hourly and data-processing charges.
B
Attach Elastic IP addresses to instances in private subnets
Why wrong: Elastic IP addresses require public networking. They do not provide a NAT-less path to AWS service APIs from a purely private subnet, and they do not achieve the cost-avoidance goal described.
C
Install a NAT Gateway in every subnet to minimize routing hops
Why wrong: Adding more NAT Gateways increases cost rather than avoiding it. The requirement is specifically to eliminate NAT Gateway usage for accessing AWS services.
D
Open outbound internet access with a security group rule to reach service endpoints directly
Why wrong: Reaching AWS service endpoints via the internet typically reintroduces outbound connectivity (and associated data-transfer costs and security considerations). It also does not provide the NAT-avoidance behavior of VPC endpoints for private access to AWS services.

Full breakdown with real-world context →

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Design Cost-Optimized Architectures sessions

Start a Design Cost-Optimized Architectures only practice session

Every question in these sessions is drawn from the Design Cost-Optimized Architectures domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Design Cost-Optimized Architectures questions →Mixed SAA-C03 session

Frequently asked questions

What does the SAA-C03 exam test about Design Cost-Optimized Architectures?: Design Cost-Optimized Architectures questions on this certification test your ability to deploy and manage design cost-optimized architectures concepts in scenario-based situations.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Design Cost-Optimized Architectures questions in a focused session?: Yes — the session launcher on this page draws every question from the Design Cost-Optimized Architectures domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other SAA-C03 topics?: Use the topic links above to move to related areas, or go back to the SAA-C03 question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the SAA-C03 exam covers. They are not copied from any real exam or dump site.

Design Cost-Optimized Architectures only

10 questions 20 questions 30 questions 50 questions

Mixed SAA-C03 session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All SAA-C03 questions Design Cost-Optimized Architectures domain overview SAA-C03 exam guide

Exam traps to avoid

▸Selecting the most expensive service when a simpler managed option meets the requirement.
▸Forgetting that cloud resources must be explicitly secured — defaults are rarely secure.
▸Choosing a global service fix when the issue is region-specific.
▸Overlooking cost implications of cross-region data transfer in architecture questions.

Design Cost-Optimized Architectures practice questions

What to know about Design Cost-Optimized Architectures

Common Design Cost-Optimized Architectures exam traps

Design Cost-Optimized Architectures questions

You store application logs in an S3 bucket. After 30 days, the logs are rarely accessed, but you must retain them for 1 year for compliance. Which S3 feature is the best way to reduce storage cost while meeting the retention requirement?

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

An application serves static images through Amazon CloudFront. The team observes higher-than-expected origin fetches, which increases origin bandwidth costs. Which change most directly improves CloudFront cache reuse to reduce origin requests for the static content?

Your team runs a batch processing workload on EC2 that can tolerate interruptions. If an instance is terminated, the job can restart from checkpoints. To reduce compute costs, what is the most cost-optimized approach?

Match each data-retention scenario to the most cost-effective Amazon S3 storage class. Assume the retrieval pattern and access-latency requirement are the most important constraints.

A web service runs continuously on AWS 24/7. The team expects steady compute usage for the next 12–24 months, but may change instance families/sizes as performance tuning continues. Which purchase option best reduces cost while keeping flexibility to change instance types?

Match each workload to the AWS pricing option that most directly minimizes cost while still meeting the stated flexibility requirements. Use each option once.

A team stores application logs in Amazon S3. They need access to the logs only occasionally for troubleshooting (infrequent access), and they want to reduce storage cost automatically over time without manually moving objects. What should they implement?

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?

Match each workload to the most cost-effective compute model or service choice. Focus on how often the workload runs, whether it is interruption-tolerant, and how much administration the team wants to avoid.

A service in private subnets downloads product images from Amazon S3 and stores job state in DynamoDB. A NAT Gateway is currently the only route to AWS services, and the monthly bill is dominated by NAT data processing charges. Which two changes will most directly reduce that cost? Select two.

Match each private-networking or content-delivery scenario to the AWS feature that most directly reduces cost while meeting the connectivity requirement.

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 line-of-business application runs on EC2 instances 24/7 with predictable usage for the next year. The application will stay in the same Region, and the team does not want to manage capacity interruptions. Which two purchase options can reduce cost compared with pure On-Demand pricing? Select two.

A compliance archive writes one log file per day to Amazon S3. The logs are almost never accessed after day 30, but if they are needed they must still be retrievable in milliseconds. They must be deleted automatically after one year. Which two lifecycle settings should you apply? Select two.

A workload runs in private subnets. It must access AWS services such as Amazon S3, but the company wants to avoid using a NAT Gateway to reduce outbound networking costs. What is the best solution?

Track your progress over time

Start a Design Cost-Optimized Architectures only practice session

Related SAA-C03 topic practice pages

Design Secure Architectures practice questions

Design Resilient Architectures practice questions

Design High-Performing Architectures practice questions