AWS Certified Solutions Architect – Associate — All Questions

A fault-tolerant batch-processing job can be interrupted and resumed and runs at flexible times. Which EC2 purchasing option minimizes cost for this workload?

• a.A three-year Reserved Instance for steady 24/7 use
• b.EC2 Spot Instances✓
• c.A Dedicated Host
• d.On-Demand Instances

Spot Instances offer the deepest discount (up to about 90% off On-Demand) and are ideal for interruption-tolerant, flexible workloads like batch jobs. On-Demand costs the most for intermittent work, and Reserved Instances or Dedicated Hosts commit you to capacity better suited to steady-state, always-on usage.

Data is stored in S3 with unpredictable and changing access patterns, and the team wants to minimize cost without manually moving objects or writing lifecycle rules. Which storage class fits best?

• a.S3 Glacier Deep Archive
• b.S3 One Zone-Infrequent Access
• c.S3 Intelligent-Tiering✓
• d.S3 Standard for everything

S3 Intelligent-Tiering automatically moves objects between access tiers based on usage, optimizing cost when access patterns are unknown or changing, with no retrieval fees for the frequent and infrequent tiers. S3 Standard misses savings on cold data, Glacier Deep Archive adds retrieval latency unsuitable for unpredictable access, and One Zone-IA reduces resilience by storing in a single AZ.

A company must transfer 80 TB of data from an on-premises data center to S3, and its internet link would take months to upload that volume. Which option is most cost- and time-effective?

• a.Use S3 Transfer Acceleration over the same link
• b.Provision a permanent Direct Connect line just for this one-time migration
• c.Use AWS Snowball to physically ship the data to AWS✓
• d.Upload directly over the existing internet connection

AWS Snowball provides a physical, ruggedized device to move large datasets offline, which is faster and cheaper than saturating a slow internet link for a one-time 80 TB transfer. Direct internet upload and Transfer Acceleration are still bound by limited bandwidth. Provisioning Direct Connect for a single migration is costly and slow to set up relative to Snowball.

A company runs a predictable, steady baseline of compute across EC2 and Fargate and wants the best discount while retaining flexibility to change instance families and Regions. Which commitment model is most appropriate?

• a.Pay On-Demand rates continuously
• b.Standard Reserved Instances locked to one instance type
• c.Spot Instances for the steady baseline
• d.Compute Savings Plans with a one- or three-year hourly spend commitment✓

Compute Savings Plans offer discounts comparable to Reserved Instances in exchange for an hourly spend commitment, while flexibly applying across instance families, sizes, Regions, and even Fargate and Lambda. Standard RIs lock you to a specific instance type and Region, reducing flexibility. On-Demand forgoes savings, and Spot is unsuitable for a steady baseline that must not be interrupted.

Log files in S3 are accessed frequently for 30 days, rarely for the next 60 days, and must be retained but almost never read after 90 days. What minimizes storage cost automatically?

• a.Keep everything in S3 Standard forever
• b.An S3 lifecycle policy that transitions objects to Standard-IA, then to a Glacier storage class as they age✓
• c.Manually copy old files to another bucket each month
• d.Delete the logs after 30 days

A lifecycle policy automatically transitions objects to cheaper tiers (Standard-IA, then Glacier) as access frequency drops, minimizing cost without manual work while meeting retention. Keeping all data in Standard wastes money, manual copying is error-prone, and deleting the logs violates the retention requirement.

A production RDS database runs 24/7 at a steady size and is expected to for years. Which purchasing choice reduces its cost the most?

• a.Take hourly snapshots to reduce cost
• b.Run it On-Demand indefinitely
• c.Use Spot capacity for the database
• d.Purchase Reserved Instances, or an applicable Savings Plan, for the steady database usage✓

Reserved Instances (or an applicable Savings Plan) give a large discount versus On-Demand in exchange for a one- or three-year commitment, which matches steady, long-running database usage. On-Demand forgoes those savings, Spot is not available for RDS and would be unsuitable for an always-on database, and snapshots are for backup, not cost reduction of the running instance.

A company has a predictable baseline of compute spend but frequently changes instance families and also uses Fargate. It wants maximum discount while keeping flexibility. Which option is best?

• a.Spot Instances for the entire baseline
• b.Standard Reserved Instances tied to a specific instance type
• c.Compute Savings Plans based on an hourly dollar commitment✓
• d.On-Demand only

Compute Savings Plans apply a discount to a committed hourly spend across instance families, sizes, Regions, Fargate, and Lambda, giving flexibility with strong savings. Standard RIs lock to a specific instance type, On-Demand gives no discount, and Spot is unsuitable for a must-run baseline because instances can be reclaimed.

A stateless, fault-tolerant web fleet behind a load balancer wants to cut cost while tolerating occasional instance loss. Which approach balances savings and availability?

• a.Run entirely On-Demand for safety
• b.Use an Auto Scaling group with a mix of On-Demand and Spot Instances across multiple instance types✓
• c.Use a single Spot Instance
• d.Use only three-year Reserved Instances

A mixed-instances Auto Scaling group combining On-Demand (for a reliable baseline) with Spot (for cheap extra capacity across several instance types and AZs) cuts cost while tolerating Spot interruptions on a stateless fleet. All On-Demand forgoes savings, a single Spot instance is fragile, and pure long-term RIs remove the elasticity Spot provides.

Secondary copies of data that are infrequently accessed and can be easily regenerated if lost need to be stored as cheaply as possible in S3. Which storage class fits best?

• a.S3 Standard-Infrequent Access
• b.S3 Standard
• c.S3 One Zone-Infrequent Access✓
• d.S3 Glacier Deep Archive

S3 One Zone-IA stores infrequently accessed data in a single AZ at a lower price than Standard-IA, which is acceptable when the data is easily reproducible and does not need multi-AZ resilience. Standard and Standard-IA cost more for this reproducible data, and Glacier Deep Archive imposes long retrieval times unsuitable for occasional access.

Private instances send large volumes of traffic to S3 through a NAT gateway, and the NAT data-processing charges are high. How can these costs be reduced?

• a.Create an S3 gateway VPC endpoint so S3 traffic bypasses the NAT gateway at no per-GB endpoint charge✓
• b.Route S3 traffic through an internet gateway with public IPs
• c.Add more NAT gateways
• d.Increase the NAT gateway size

An S3 gateway VPC endpoint routes bucket traffic privately without going through the NAT gateway, eliminating NAT data-processing charges for that traffic since gateway endpoints have no hourly or per-GB cost. Larger or additional NAT gateways still incur processing charges, and public IPs would expose the instances while not necessarily reducing cost.

A company suspects many EC2 instances are larger than needed and wants data-driven recommendations to right-size them based on actual utilization. Which tool should it use?

• a.Amazon Inspector
• b.AWS Shield
• c.AWS Config
• d.AWS Compute Optimizer✓

AWS Compute Optimizer analyzes historical utilization metrics and recommends right-sizing for EC2 and other resources, helping eliminate overprovisioned capacity and cost. Shield is for DDoS protection, Inspector scans for vulnerabilities, and Config tracks configuration compliance, none of which provide right-sizing recommendations.

A business application is heavily used during work hours and nearly idle overnight and on weekends. How can compute cost be reduced while keeping capacity for peak times?

• a.Switch all instances to Spot regardless of usage
• b.Run peak capacity 24/7 to be safe
• c.Use Auto Scaling with scheduled and demand-based scaling to reduce capacity during off-peak hours✓
• d.Buy Reserved Instances for the full peak capacity

Auto Scaling with scheduled actions plus demand-based policies reduces the number of running instances overnight and on weekends and scales back up for business hours, paying only for needed capacity. Running peak capacity 24/7 wastes money, blanket Spot risks interruption for steady daytime load, and RIs sized for peak would sit idle off-peak.

A development and test database is used sporadically during the day and sits idle much of the time. Which option minimizes cost by scaling capacity with actual usage?

• a.A three-year Reserved Instance
• b.A large provisioned RDS instance running continuously
• c.Aurora Serverless, which scales capacity to demand and lowers cost during idle periods✓
• d.A self-managed fleet of EC2 database servers

Aurora Serverless scales database capacity to match demand and reduces cost during the frequent idle periods of a dev/test workload. A continuously running large instance or a three-year reservation pays for capacity that is mostly unused, and a self-managed EC2 fleet adds cost and operational overhead.

A popular download site serves the same large files to many users directly from S3, and data-transfer-out costs are high. How can egress cost and origin load be reduced?

• a.Enable S3 versioning
• b.Store the files in Glacier
• c.Move the files to a bigger EC2 instance
• d.Serve the files through Amazon CloudFront so repeated requests are served from cached edge content✓

CloudFront caches content at edge locations, so repeated downloads are served from the cache rather than the origin, reducing S3 data-transfer-out costs and origin load, often at lower per-GB pricing. A larger instance does not address transfer cost, Glacier is archival with retrieval delays, and versioning does not reduce egress.

Regulatory records must be kept for ten years, are essentially never retrieved, and retrieval times of several hours are acceptable. Which S3 storage class minimizes cost?

• a.S3 Glacier Deep Archive✓
• b.S3 Standard-Infrequent Access
• c.S3 Intelligent-Tiering
• d.S3 Standard

S3 Glacier Deep Archive offers the lowest storage price for long-term archives that are almost never accessed and where retrieval times of hours are acceptable, making it ideal for decade-long compliance retention. Standard and Standard-IA cost far more for rarely accessed data, and Intelligent-Tiering targets changing access patterns rather than deep, static archives.

Dozens of non-production EC2 instances are left running around the clock even though they are only needed during business hours. What is the simplest way to cut their cost?

• a.Automatically stop the instances outside business hours, for example with a scheduler, and start them when needed✓
• b.Buy three-year Reserved Instances for them
• c.Delete them and recreate them each morning by hand
• d.Convert them all to Spot Instances

Stopping non-production instances outside business hours on a schedule means you stop paying for compute while they are off, a simple and large saving for dev/test environments. Spot risks interruptions and still runs continuously, Reserved Instances pay for 24/7 capacity that is not needed, and manual recreation each day is error-prone and time-consuming.

A fault-tolerant image-rendering job can be interrupted and resumed at any time and runs whenever capacity is available. Which EC2 purchasing option minimizes cost for this flexible workload?

• a.A three-year Standard Reserved Instance committed to continuous use
• b.On-Demand Instances billed at the standard hourly rate
• c.EC2 Spot Instances✓
• d.A Dedicated Host reserved for compliance isolation

Spot Instances provide the deepest discount (up to about 90% off On-Demand) and suit interruption-tolerant, time-flexible jobs like rendering. On-Demand costs the most for intermittent work, and Reserved Instances or Dedicated Hosts commit to steady, always-on capacity that a flexible batch job does not require.

A company commits to a steady baseline of EC2 usage but wants the deepest possible discount and is willing to lock to a specific instance family and Region in one Availability Zone. Which purchasing option gives the largest discount for that commitment?

• a.Standard Reserved Instances for that specific instance family and Region✓
• b.On-Demand Instances with no commitment
• c.Spot Instances for the steady baseline
• d.Compute Savings Plans, which trade some discount for flexibility across families and Regions

Standard Reserved Instances offer the largest discount in exchange for committing to a specific instance family and Region, which fits a fixed, steady baseline. Compute Savings Plans trade some discount for flexibility, On-Demand gives no discount, and Spot is unsuitable for a must-run baseline that cannot be interrupted.

A company runs a predictable amount of compute but constantly changes instance families and also uses Fargate and Lambda. It wants strong savings while keeping this flexibility. Which commitment model fits best?

• a.Compute Savings Plans based on a committed hourly spend✓
• b.On-Demand pricing to preserve flexibility with no commitment
• c.Standard Reserved Instances locked to one instance family and Region
• d.Spot Instances for the entire predictable baseline

Compute Savings Plans apply a discount to a committed hourly spend across instance families, sizes, Regions, and even Fargate and Lambda, giving flexibility with strong savings. Standard RIs lock to one family and Region, On-Demand forgoes savings, and Spot cannot guarantee a must-run baseline.

A team wants Reserved Instance-level savings but only plans to stay on one specific instance family, and it wants a larger discount than Compute Savings Plans offer while still allowing size flexibility within that family. Which option fits?

• a.Spot Instances for the steady, must-run workload
• b.Compute Savings Plans, which offer broader flexibility but a somewhat smaller maximum discount
• c.EC2 Instance Savings Plans committed to a specific instance family in a Region✓
• d.On-Demand Instances with no commitment at all

EC2 Instance Savings Plans commit to a specific instance family in a Region for a discount comparable to Standard RIs while allowing size and OS flexibility within that family. Compute Savings Plans are more flexible but offer a somewhat smaller maximum discount, On-Demand gives none, and Spot cannot guarantee steady capacity.

A production RDS database runs steadily around the clock and is expected to for the next three years. Which choice reduces its cost the most?

• a.Purchase Reserved Instances, or an applicable Savings Plan, for the steady usage✓
• b.Take frequent snapshots to reduce the running cost of the instance
• c.Run it On-Demand indefinitely to avoid any commitment, so it is not the most appropriate option in this case
• d.Use Spot capacity to lower the database's hourly cost

Reserved Instances (or an applicable Savings Plan) provide a large discount versus On-Demand for steady, long-running database usage in exchange for a one- or three-year commitment. On-Demand forgoes savings, Spot is not offered for RDS and is unsuitable for an always-on database, and snapshots are backups, not a cost-reduction lever for the running instance.

A stateless, fault-tolerant web fleet behind a load balancer must cut cost while tolerating occasional instance loss. Which approach balances savings and availability best?

• a.Run the fleet on a single Spot Instance to minimize cost
• b.Run the entire fleet on three-year Reserved Instances to lock in savings
• c.Run the whole fleet On-Demand to avoid any interruption
• d.Use an Auto Scaling group mixing On-Demand for a baseline with Spot across several instance types✓

A mixed-instances Auto Scaling group combining On-Demand baseline capacity with Spot across multiple instance types and AZs cuts cost while tolerating Spot interruptions on a stateless fleet. All-RI removes elasticity, all-On-Demand forgoes savings, and a single Spot instance is fragile.

A team wants the cost benefits of Fargate for a batch workload that can tolerate interruptions, running tasks whenever spare capacity is available. Which option lowers the container compute cost the most?

• a.Running the tasks on always-on On-Demand Fargate to avoid any interruption
• b.Migrating the tasks to a fixed fleet of Reserved EC2 instances
• c.Fargate Spot for the interruption-tolerant batch tasks✓
• d.Running the tasks On-Demand and simply overprovisioning to finish faster

Fargate Spot runs interruption-tolerant tasks at a steep discount compared with standard Fargate, ideal for flexible batch work. On-Demand Fargate and Reserved EC2 fleets cost more for interruptible work, and overprovisioning On-Demand increases spend rather than reducing it.

A Linux microservices workload can be recompiled for ARM and runs steadily. The team wants to lower compute cost without sacrificing performance. Which change reduces cost most while maintaining throughput?

• a.Move the workload to the largest available x86 instances to finish work sooner
• b.Switch to burstable T-family instances for the constant workload
• c.Add GPU-accelerated instances to speed up the microservices
• d.Move the workload to AWS Graviton-based instances for better price-performance✓

Graviton (ARM) instances offer better price-performance than comparable x86 instances for many scale-out Linux workloads, lowering cost at equal or better throughput. Larger x86 instances raise cost, burstable instances throttle steady load, and GPUs add cost with no benefit to standard microservices.

S3 data is accessed frequently for the first 30 days, rarely for the next 60 days, and must be retained but almost never read after that. What minimizes storage cost automatically over the object lifetime?

• a.Manually move old objects to a separate bucket each month
• b.Apply an S3 Lifecycle policy transitioning objects to Standard-IA, then to a Glacier class as they age✓
• c.Delete objects after 30 days to avoid storage charges, which does not deliver what the scenario specifically requires
• d.Keep every object in S3 Standard permanently for simplicity

A lifecycle policy automatically transitions objects to cheaper tiers (Standard-IA, then Glacier) as access frequency drops, minimizing cost while meeting retention with no manual work. Keeping all data in Standard wastes money, deleting violates retention, and manual moves are error-prone and labor-intensive.

Objects in S3 have unknown and changing access patterns, and the team wants automatic cost optimization without retrieval fees for the frequent and infrequent tiers and without writing lifecycle rules. Which storage class fits best?

• a.S3 Intelligent-Tiering✓
• b.S3 Standard for every object regardless of how it is accessed
• c.S3 Glacier Deep Archive for all of the objects
• d.S3 One Zone-Infrequent Access for all of the objects

S3 Intelligent-Tiering automatically moves objects between access tiers based on usage with no retrieval fees for the frequent and infrequent tiers, optimizing cost when patterns are unknown or changing. Standard misses savings on cold data, Deep Archive adds retrieval latency, and One Zone-IA reduces resilience by storing in a single AZ.

Compliance records must be kept for ten years, are essentially never retrieved, and retrieval times of several hours are acceptable. Which S3 storage class minimizes storage cost?

• a.S3 Glacier Deep Archive✓
• b.S3 Standard for the entire retention period
• c.S3 Standard-Infrequent Access for the whole ten years
• d.S3 Intelligent-Tiering to adapt to the access pattern

S3 Glacier Deep Archive offers the lowest storage price for long-term archives that are almost never accessed and where multi-hour retrieval is acceptable, ideal for decade-long compliance retention. Standard and Standard-IA cost far more for rarely accessed data, and Intelligent-Tiering targets changing access rather than deep static archives.

Secondary copies of data are infrequently accessed but easily regenerated if lost, and the team wants the cheapest S3 option that still allows millisecond retrieval when needed. Which storage class fits best?

• a.S3 Standard, which costs more for this reproducible, rarely accessed data
• b.S3 One Zone-Infrequent Access✓
• c.S3 Standard-Infrequent Access stored redundantly across multiple AZs
• d.S3 Glacier Deep Archive, whose multi-hour retrieval is unnecessary here

S3 One Zone-IA stores infrequently accessed data in a single AZ at a lower price than Standard-IA, acceptable when data is reproducible and does not need multi-AZ resilience, while still offering millisecond retrieval. Standard and Standard-IA cost more, and Deep Archive imposes retrieval delays this use case does not require.

A business application is busy during work hours and nearly idle overnight and on weekends. How can compute cost be reduced while keeping capacity available for peak times?

• a.Purchase Reserved Instances sized for full peak capacity and run them continuously
• b.Run peak capacity around the clock to avoid any scaling complexity, making it unsuitable for the situation described here
• c.Use Auto Scaling with scheduled and demand-based policies to shrink capacity off-peak✓
• d.Switch every instance to Spot regardless of the steady daytime demand

Auto Scaling with scheduled actions plus demand-based policies reduces running instances overnight and on weekends and scales back up for business hours, so you pay mainly for needed capacity. Peak capacity 24/7 wastes money, blanket Spot risks interruption for steady daytime load, and peak-sized RIs sit idle off-peak.

Dozens of non-production EC2 instances run around the clock but are only needed during business hours. What is the simplest way to cut their cost significantly?

• a.Delete and recreate the instances by hand each morning
• b.Convert all of them to three-year Reserved Instances to lower the hourly rate
• c.Switch every instance to Spot while still running them continuously
• d.Automatically stop the instances outside business hours and start them when needed✓

Stopping non-production instances outside business hours on a schedule stops compute charges while they are off, a large and simple saving for dev/test. Reserved Instances pay for 24/7 capacity that is not needed, Spot still runs continuously and risks interruption, and manual recreation each day is error-prone.

A company suspects many EC2 instances are oversized and wants data-driven right-sizing recommendations based on actual CPU, memory, and network utilization. Which service should it use?

• a.AWS Shield, which protects against DDoS rather than analyzing utilization
• b.AWS Compute Optimizer✓
• c.Amazon Inspector, which scans workloads for software vulnerabilities
• d.AWS Config, which tracks configuration compliance rather than sizing

AWS Compute Optimizer analyzes historical utilization metrics and recommends right-sizing for EC2 and other resources, helping eliminate overprovisioned capacity. Shield is for DDoS, Inspector scans for vulnerabilities, and Config tracks configuration state, none of which produce right-sizing recommendations.

A finance team needs to explore historical AWS spend, break costs down by service and tag, and forecast future spending through an interactive interface. Which tool is designed for this analysis?

• a.AWS Cost Explorer✓
• b.AWS Config configuration history of resources
• c.AWS CloudTrail logs of API activity
• d.Amazon CloudWatch metrics dashboards for infrastructure performance

AWS Cost Explorer provides interactive visualization, breakdowns by service and tag, and forecasting of AWS spend, purpose-built for cost analysis. CloudWatch shows performance metrics, CloudTrail records API calls, and Config tracks configuration state, none of which analyze and forecast cost.

A team wants to be alerted, and optionally take action, when actual or forecasted spend exceeds a defined threshold each month. Which service should be configured?

• a.AWS Budgets with cost and usage thresholds and alerts✓
• b.AWS Trusted Advisor security checks on the account
• c.AWS CloudTrail delivering API logs to an S3 bucket
• d.Amazon CloudWatch alarms on EC2 CPU utilization metrics

AWS Budgets lets you set cost or usage thresholds and receive alerts (and trigger actions) when actual or forecasted spend crosses them, directly meeting the requirement. CloudWatch CPU alarms track performance, CloudTrail records API activity, and Trusted Advisor gives recommendations but is not the budget-threshold alerting service.

A company wants automated best-practice recommendations spanning cost optimization, such as idle load balancers, underused instances, and unattached resources, alongside security and performance checks. Which service provides these checks?

• a.Amazon Inspector, which focuses on vulnerability scanning
• b.Amazon Macie, which discovers and classifies sensitive data in S3
• c.AWS CloudTrail, which records API activity for auditing
• d.AWS Trusted Advisor✓

AWS Trusted Advisor inspects the account and recommends improvements across cost optimization, security, performance, fault tolerance, and service limits, including idle and underused resources. Inspector scans for vulnerabilities, CloudTrail records API calls, and Macie classifies sensitive data, none of which provide cross-domain cost checks.

A large organization needs the most detailed, line-item breakdown of AWS usage and cost delivered to S3 for ingestion into its own analytics tools. Which data source provides this granularity?

• a.The AWS Cost and Usage Report (CUR) delivered to S3✓
• b.AWS Trusted Advisor cost-optimization checks
• c.The AWS Billing console summary page viewed manually each month
• d.Amazon CloudWatch billing metrics for high-level totals

The AWS Cost and Usage Report provides the most granular, line-item cost and usage data delivered to S3 for querying with tools like Athena or QuickSight. The billing summary and CloudWatch billing metrics are high-level, and Trusted Advisor gives recommendations rather than detailed line-item exports.

A company must transfer 100 TB of data from an on-premises data center to Amazon S3, and its internet link would take months to upload that volume. Which option is most cost- and time-effective for the one-time move?

• a.Use S3 Transfer Acceleration over the same limited link
• b.Use AWS Snowball to ship the data physically to AWS✓
• c.Upload directly over the existing internet connection
• d.Provision a permanent Direct Connect line solely for this one-time migration

AWS Snowball moves large datasets offline on a physical device, which is faster and cheaper than saturating a slow link for a one-time 100 TB transfer. Direct internet upload and Transfer Acceleration remain bandwidth-bound, and provisioning Direct Connect for a single migration is costly and slow to set up relative to Snowball.

Private instances send large volumes of traffic to S3 through a NAT gateway, and NAT data-processing charges are high. How can these costs be reduced while keeping traffic private?

• a.Create an S3 gateway VPC endpoint so S3 traffic bypasses the NAT gateway at no per-gigabyte endpoint charge✓
• b.Increase the NAT gateway size to lower its per-gigabyte cost
• c.Add several more NAT gateways to spread the traffic
• d.Give the instances public IP addresses and route S3 traffic through the internet gateway

An S3 gateway VPC endpoint routes bucket traffic privately without traversing the NAT gateway, eliminating NAT data-processing charges since gateway endpoints have no hourly or per-gigabyte cost. Larger or additional NAT gateways still incur processing charges, and public IPs expose the instances to the internet.

A popular download site serves the same large files to many users directly from S3, and data-transfer-out charges are high. How can egress cost and origin load be reduced?

• a.Enable S3 Versioning so repeated downloads cost less, so it would not meet the objective stated in the question
• b.Serve the files through Amazon CloudFront so repeated requests are served from cached edge content✓
• c.Host the files on a larger EC2 instance to reduce egress charges
• d.Move the files to Amazon S3 Glacier to lower the transfer cost

CloudFront caches content at edge locations, so repeated downloads are served from cache rather than the origin, reducing S3 data-transfer-out cost and origin load, often at lower per-gigabyte pricing. Glacier is archival with retrieval delays, a larger instance does not address egress, and versioning does not reduce transfer cost.

A dev/test relational database is used sporadically during the day and sits idle much of the time. Which option minimizes cost by scaling capacity to actual usage?

• a.A large provisioned RDS instance kept running continuously, which is why it is not the recommended approach here
• b.A self-managed fleet of EC2 database servers running all day
• c.A three-year Reserved Instance sized for the busiest moment
• d.Aurora Serverless, which scales capacity to demand and lowers cost during idle periods✓

Aurora Serverless scales database capacity with demand and reduces cost during the frequent idle periods of a dev/test workload. A continuously running large instance or three-year reservation pays for mostly unused capacity, and a self-managed EC2 fleet adds cost and operational overhead.

A NoSQL table has spiky, unpredictable traffic with long idle stretches, and the team is paying for provisioned capacity that mostly sits unused. Which DynamoDB setting reduces cost while handling spikes without capacity planning?

• a.Increase provisioned capacity to a high fixed ceiling to avoid throttling
• b.Move the table to a large provisioned RDS instance instead
• c.Keep provisioned capacity fixed at the peak observed level at all times
• d.Switch the table to on-demand capacity mode so you pay per request✓

DynamoDB on-demand mode charges per request and handles unpredictable spikes without pre-provisioning, avoiding payment for idle provisioned capacity. Raising or pinning provisioned capacity to peak wastes money during idle periods, and moving to a large RDS instance abandons DynamoDB's scaling for a NoSQL workload.