Amazon AWS SAA-C03 Cost-Optimized Databases, Capacity, Serverless, Caching, Retention, and Migration Practice Test 1

 

Topic 19 Practice Test 1 covers Cost-Optimized Databases, Capacity, Serverless, Caching, Retention, and Migration for AWS SAA-C03. For broader exam preparation, review the AWS SAA-C03 Exam Dumps. Every option includes focused technical reasoning explaining both the AWS architecture concept and its fit to the scenario.

Question 1

An internal development application uses an Aurora PostgreSQL database only during weekday testing. It can tolerate roughly 15 seconds for the first connection after long idle periods. Which design most directly minimizes database compute charges during inactivity?

1. Aurora provisioned writer with one provisioned reader
2. RDS Proxy in front of a provisioned Aurora cluster
3. Aurora Global Database with a secondary Region
4. Aurora Serverless v2 with a 0-ACU minimum

Correct Answer(s)

 

D

Rationale

1. Provisioned Aurora instances continue to incur instance charges while running even if application traffic is idle; adding a reader increases rather than removes that compute footprint. The deciding constraint is weekday-only development use; idle periods are long; resume delay is acceptable. It solves a different problem and leaves the stated waste largely unchanged.
2. RDS Proxy pools database connections but does not turn provisioned database compute off; persistent proxy or application connections can also work against an auto-pause objective. The deciding constraint is weekday-only development use; idle periods are long; resume delay is acceptable. Under these constraints, it changes architecture without addressing the relevant billing dimension.
3. Global Database adds cross-Region infrastructure for disaster recovery and global reads; it is an availability architecture, not a way to eliminate compute charges for an idle development database. The deciding constraint is weekday-only development use; idle periods are long; resume delay is acceptable. That makes it a poor fit for the cost driver identified here.
4. With a supported engine version, Aurora Serverless v2 can auto-pause at zero ACUs after the configured idle interval, so instance capacity charges stop while paused and connections can trigger resume. The deciding constraint is weekday-only development use; idle periods are long; resume delay is acceptable. That is the relevant lever for this workload rather than adding capacity elsewhere.

 

Question 2

An Aurora MySQL workload has highly variable traffic throughout the day but cannot tolerate a full stop/start cycle. The team wants database capacity to grow and shrink with demand instead of sizing a fixed instance for the peak. Which choice best matches that cost objective?

1. Aurora Serverless v2 with a bounded ACU range
2. A larger fixed provisioned instance with storage autoscaling
3. A fixed db.r7g.4xlarge Aurora writer
4. A permanently running Aurora read replica of equal size

Correct Answer(s)

 

A

Rationale

1. Aurora Serverless v2 adjusts database capacity in ACUs within the configured range, letting compute follow workload demand while keeping the database available. The deciding constraint is variable production traffic; no long stop/start delay; avoid peak overprovisioning. It therefore aligns the paid resource with the usage pattern described in the scenario.
2. RDS storage autoscaling changes allocated storage when free space becomes low; it does not shrink or expand provisioned CPU and memory to follow request volume. The deciding constraint is variable production traffic; no long stop/start delay; avoid peak overprovisioning. The scenario does not require the capability this option primarily provides.
3. A fixed large writer is billed for the provisioned instance regardless of whether the traffic is at peak or trough, so it embeds peak headroom into ongoing cost. The deciding constraint is variable production traffic; no long stop/start delay; avoid peak overprovisioning. It therefore adds cost or complexity without satisfying the requested optimization.
4. A continuously running reader can improve read scaling or failover posture, but it adds another provisioned instance rather than making the primary compute footprint elastic. The deciding constraint is variable production traffic; no long stop/start delay; avoid peak overprovisioning. The workload characteristic in the prompt points to a different service mechanism.

 

Question 3

Cost Explorer shows that I/O charges account for 34% of an Aurora cluster’s total database spend. The workload will remain I/O intensive. Which storage configuration should the architect evaluate first to reduce and stabilize I/O-related cost?

1. Aurora Standard
2. RDS magnetic storage
3. Aurora I/O-Optimized
4. Provisioned IOPS storage on a separate RDS instance

Correct Answer(s)

 

C

Rationale

1. Aurora Standard charges separately for I/O requests and is generally the better price model when I/O spending is below the documented threshold rather than well above it. The deciding constraint is Aurora workload; I/O spend is 34% of total database cost; I/O intensity will persist. It does not exploit the specific tolerance or access pattern provided by the scenario.
2. Magnetic storage is an older RDS storage type and is not an Aurora cluster storage configuration; moving away from Aurora would also change the architecture without addressing the stated pricing choice. This option may be useful elsewhere, but not for the stated cost-and-usage combination.
3. Aurora I/O-Optimized removes separate charges for Aurora read and write I/O operations and is specifically positioned for workloads where I/O spending is a substantial share of total Aurora cost. This preserves the stated requirement while removing the specific source of avoidable spend.
4. Provisioned IOPS is an RDS storage-performance option, not the Aurora cluster storage configuration that removes per-operation Aurora I/O charges. The deciding constraint is Aurora workload; I/O spend is 34% of total database cost; I/O intensity will persist. The workload characteristic in the prompt points to a different service mechanism.

 

Question 4

An Aurora PostgreSQL cluster has light I/O usage, and I/O charges represent only 8% of its total Aurora database spend. Which storage configuration is normally the more cost-appropriate starting point?

1. Aurora I/O-Optimized
2. Aurora Standard
3. Amazon EBS io2 Block Express attached to Aurora
4. S3 Standard-IA as the Aurora database volume

Correct Answer(s)

 

B

Rationale

1. Aurora I/O-Optimized trades a different cluster pricing model for eliminating separate I/O operation charges; with only 8% I/O spend, that trade typically does not match the documented cost threshold. This affects another operational concern rather than the bill component named in the question.
2. Aurora Standard is designed for Aurora workloads with moderate I/O usage and is the usual cost choice when I/O spending is a small fraction of total database spend. The deciding constraint is Aurora cluster; I/O spend is 8% of total; no unusual I/O growth expected. The choice changes the cost driver named in the prompt without introducing an unrelated service.
3. Aurora does not use customer-attached EBS volumes for its distributed cluster storage, so io2 Block Express cannot replace the Aurora storage configuration in this design. The deciding constraint is Aurora cluster; I/O spend is 8% of total; no unusual I/O growth expected. It is not the AWS mechanism that controls the capacity or retention behavior at issue.
4. S3 storage classes are not selectable as Aurora cluster volumes; they serve object-storage workloads rather than the live relational database storage layer. The deciding constraint is Aurora cluster; I/O spend is 8% of total; no unusual I/O growth expected. The proposed change would preserve or increase the resource that is currently overprovisioned.

 

Question 5

A production RDS for PostgreSQL instance has run at a stable size continuously for two years, and demand is forecast to remain steady for another three years. Which purchasing approach most directly targets the recurring DB instance compute charge?

1. Enable storage autoscaling with a high maximum
2. Purchase an appropriately scoped RDS Reserved DB Instance
3. Move the database to Multi-AZ solely for billing
4. Increase automated backup retention

Correct Answer(s)

 

B

Rationale

1. Storage autoscaling protects against running out of database storage, but it does not provide a reservation discount on the DB instance hours that dominate this scenario. The deciding constraint is stable instance class; continuous production use; multi-year forecast. It does not alter the usage model responsible for the recurring cost in this case.
2. RDS Reserved DB Instances provide a billing discount on eligible instance usage when the organization can commit to a predictable long-running footprint. The deciding constraint is stable instance class; continuous production use; multi-year forecast. It fits the required availability and access behavior while targeting the billed resource directly.
3. Multi-AZ improves availability by maintaining standby capacity and generally increases infrastructure cost; it is not a purchasing discount for the existing compute footprint. The deciding constraint is stable instance class; continuous production use; multi-year forecast. The choice would be justified by a different resilience or performance requirement.
4. Backup retention affects backup-storage consumption and recovery history; it does not discount the hourly compute charge of a continuously running DB instance. The deciding constraint is stable instance class; continuous production use; multi-year forecast. The result would not align paid capacity with the measured demand described here.

 

Question 6

An RDS MySQL database grows unpredictably because customers upload metadata at an uneven rate. The team wants to avoid allocating a large storage volume on day one, while preventing routine low-space incidents. Which feature best addresses this requirement?

1. Purchase a Reserved DB Instance
2. Preallocate the engine maximum storage immediately
3. Add an RDS read replica in the same Availability Zone
4. RDS storage autoscaling with a bounded maximum

Correct Answer(s)

 

D

Rationale

1. A Reserved DB Instance can discount eligible compute usage, but it does not control how much database storage is allocated or automatically grow that storage. The deciding constraint is unpredictable storage growth; avoid large initial allocation; maintain headroom. The result would not align paid capacity with the measured demand described here.
2. Allocating the maximum possible storage immediately removes growth uncertainty but defeats the stated cost objective by paying for capacity well before the workload needs it. The deciding constraint is unpredictable storage growth; avoid large initial allocation; maintain headroom. The service behavior described here does not deliver the requested reduction in ongoing spend.
3. A read replica adds database compute for read scaling and does not automatically expand the source instance’s allocated storage when free space falls. The deciding constraint is unpredictable storage growth; avoid large initial allocation; maintain headroom. The requirement can be met without introducing this additional billed component.
4. RDS storage autoscaling increases allocated storage when free space stays low and uses a configured maximum threshold as a guardrail, avoiding large up-front storage allocation. The deciding constraint is unpredictable storage growth; avoid large initial allocation; maintain headroom. The scenario’s constraint makes this trade-off appropriate after validating workload measurements.

 

Question 7

A lightly loaded RDS development database is used for eight hours each weekday and is not needed overnight or on weekends. The team can reconnect after it starts. Which operational practice reduces instance-hour charges without deleting the database?

1. Scheduled stop/start of the RDS instance
2. Change the backup retention period to zero each night
3. Delete the DB subnet group every evening
4. Create an additional read replica and stop the primary

Correct Answer(s)

 

A

Rationale

1. RDS supports temporarily stopping eligible DB instances; while stopped, instance-hour charges cease even though storage and certain other charges continue. The deciding constraint is nonproduction database; predictable off-hours; storage may remain billed. This is the service-native mechanism intended for the cost pattern described here.
2. Backup retention controls recovery history and backup storage behavior; changing it does not stop the DB instance compute charge during idle hours. The deciding constraint is nonproduction database; predictable off-hours; storage may remain billed. That makes it a poor fit for the cost driver identified here.
3. A DB subnet group is network configuration metadata and deleting it does not suspend the running database compute that generates the instance-hour charge. The deciding constraint is nonproduction database; predictable off-hours; storage may remain billed. It solves a different problem and leaves the stated waste largely unchanged.
4. A read replica creates another database instance and cost center. Stopping only the primary would also disrupt replication and does not represent the intended simple nonproduction stop/start pattern. The deciding constraint is nonproduction database; predictable off-hours; storage may remain billed. The service behavior described here does not deliver the requested reduction in ongoing spend.

 

Question 8

A business application needs high availability only in production. Its separate integration-test RDS database can be recreated from automation and has no availability SLA. Which deployment choice avoids paying for standby capacity that the test environment does not require?

1. Use Multi-AZ with a read replica in another Region
2. Use an RDS Multi-AZ DB cluster
3. Use a Single-AZ RDS deployment for the integration-test database
4. Create an Aurora Global Database

Correct Answer(s)

 

C

Rationale

1. Cross-Region replication adds database and data-transfer cost for geographic resilience, which is beyond a test environment with no recovery SLA. The deciding constraint is integration test only; infrastructure is reproducible; no availability SLA. Under these constraints, it changes architecture without addressing the relevant billing dimension.
2. A Multi-AZ DB cluster is designed for availability and read capacity across Availability Zones; those additional resources are unnecessary under the stated disposable-test requirement. The deciding constraint is integration test only; infrastructure is reproducible; no availability SLA. The scenario does not require the capability this option primarily provides.
3. A Single-AZ RDS deployment avoids the extra standby or multi-instance resources associated with high-availability topologies when the test environment explicitly accepts an Availability Zone failure. The deciding constraint is integration test only; infrastructure is reproducible; no availability SLA. It addresses the recurring charge while leaving unrelated resilience requirements unchanged.
4. Aurora Global Database is a cross-Region resilience and global-read architecture, not the least-cost topology for a disposable integration-test database. The deciding constraint is integration test only; infrastructure is reproducible; no availability SLA. The added resource would not remove the charge the team is trying to reduce.

 

Question 9

A team repeatedly creates full copies of a 6 TB Aurora production cluster for short-lived test cycles. Most test runs modify less than 2% of the data. Which approach reduces the initial duplicate-storage footprint while providing an isolated writable database?

1. Create Aurora database clones using copy-on-write
2. Restore a full Aurora snapshot for every test run
3. Export the cluster to CSV files and import into a new RDS instance
4. Create a cross-Region Aurora Global Database secondary

Correct Answer(s)

 

A

Rationale

1. Aurora cloning uses copy-on-write, initially sharing underlying data pages with the source and allocating additional storage as either side changes pages. The deciding constraint is 6 TB Aurora source; temporary writable tests; less than 2% of data changes. The design is economical because the paid capacity follows the demand or retention need stated.
2. Snapshot restore creates a separate database volume rather than the copy-on-write clone optimized for rapid, space-efficient test environments. The deciding constraint is 6 TB Aurora source; temporary writable tests; less than 2% of data changes. It therefore adds cost or complexity without satisfying the requested optimization.
3. Exporting and reimporting the database creates a new full copy and adds data movement work; it is not the storage-efficient Aurora cloning mechanism. The deciding constraint is 6 TB Aurora source; temporary writable tests; less than 2% of data changes. The workload characteristic in the prompt points to a different service mechanism.
4. A Global Database secondary is maintained for cross-Region availability and read use cases, not as an isolated, short-lived writable testing copy. The deciding constraint is 6 TB Aurora source; temporary writable tests; less than 2% of data changes. The scenario does not require the capability this option primarily provides.

 

Question 10

An online catalog serves the same product records thousands of times per minute from an RDS database. Writes are comparatively rare, and a short cache TTL is acceptable. Which architecture is most likely to lower database compute pressure enough to permit a smaller DB instance?

1. Enable a longer automated backup retention period
2. Add more provisioned IOPS to the RDS volume
3. Increase the RDS instance class and keep all reads on the database
4. Cache frequently read product data in Amazon ElastiCache

Correct Answer(s)

 

D

Rationale

1. Backup retention changes recovery history and backup-storage consumption; it does not intercept application reads or reduce the primary instance’s query workload. The deciding constraint is read-heavy catalog; repeated hot records; cache staleness for a short TTL is acceptable. This option may be useful elsewhere, but not for the stated cost-and-usage combination.
2. More provisioned storage IOPS can address storage latency but does not remove repeated SQL executions or their CPU and connection overhead from the database. The deciding constraint is read-heavy catalog; repeated hot records; cache staleness for a short TTL is acceptable. The proposed change would preserve or increase the resource that is currently overprovisioned.
3. Scaling the instance upward increases capacity and recurring compute cost, which is the opposite direction from the requirement to reduce database resource demand. The deciding constraint is read-heavy catalog; repeated hot records; cache staleness for a short TTL is acceptable. This affects another operational concern rather than the bill component named in the question.
4. ElastiCache can serve repeated hot reads from memory, reducing query work on RDS and potentially allowing the relational instance to be right-sized to a lower steady load. The deciding constraint is read-heavy catalog; repeated hot records; cache staleness for a short TTL is acceptable. That makes the option the closest match to both the technical constraint and cost objective.

 

Question 11

CloudWatch shows an RDS instance averaging 7% CPU, low memory pressure, and modest I/O for several months. The application has no near-term growth forecast. What is the most direct cost-optimization action after validating peak usage?

1. Add a same-size read replica
2. A smaller validated RDS instance class
3. Increase the storage autoscaling maximum
4. Enable Multi-AZ only to reduce price

Correct Answer(s)

 

B

Rationale

1. A read replica adds another billed DB instance and is appropriate for read scaling or resilience, not for correcting an underutilized primary. The deciding constraint is months of low utilization; peaks verified; no expected demand growth. It does not alter the usage model responsible for the recurring cost in this case.
2. Right-sizing reduces the recurring instance charge when measured CPU, memory, connection, and I/O demand consistently leave large unused headroom and peaks remain within a smaller class. The deciding constraint is months of low utilization; peaks verified; no expected demand growth. The optimization is targeted: it changes the resource creating waste instead of shifting the problem.
3. Raising the storage-autoscaling ceiling only permits more future storage growth; it does not reduce the oversized CPU and memory allocation already being billed. The deciding constraint is months of low utilization; peaks verified; no expected demand growth. The choice would be justified by a different resilience or performance requirement.
4. Multi-AZ is an availability feature that adds redundant database resources; it should be justified by resilience requirements rather than used as a cost-reduction mechanism. The deciding constraint is months of low utilization; peaks verified; no expected demand growth. This affects another operational concern rather than the bill component named in the question.

 

Question 12

A DynamoDB table stores seven years of order history. Monthly storage cost now exceeds request cost, and only a small fraction of old orders are read each month. Which table class should the architect evaluate for the historical table?

1. A global table replica in another Region
2. DynamoDB Standard
3. DynamoDB Standard-IA
4. DAX with the Standard table class

Correct Answer(s)

 

C

Rationale

1. Adding a global table replica duplicates data in another Region and adds replicated write and storage costs instead of reducing the historical table’s storage cost. The deciding constraint is long-term history; storage dominates monthly spend; infrequent reads and writes. The result would not align paid capacity with the measured demand described here.
2. DynamoDB Standard is the default balance for frequently accessed data; it is less aligned with a history table whose storage dominates overall cost. The deciding constraint is long-term history; storage dominates monthly spend; infrequent reads and writes. It does not alter the usage model responsible for the recurring cost in this case.
3. DynamoDB Standard-IA is intended for tables where storage is the dominant cost and data is read or updated infrequently, trading lower storage pricing for higher request pricing. The deciding constraint is long-term history; storage dominates monthly spend; infrequent reads and writes. This approach uses the documented billing behavior that matters for the stated access pattern.
4. DAX can accelerate cached reads but adds a cache cluster and does not change the table class or its underlying storage pricing. The deciding constraint is long-term history; storage dominates monthly spend; infrequent reads and writes. This is technically separate from the cost lever the architect is being asked to choose.

 

Question 13

A DynamoDB session table is read and updated continuously throughout the day, and request charges dominate its bill while storage is small. Which table class best fits that access pattern?

1. DynamoDB Standard-IA plus a second full copy in Standard
2. S3 Glacier Flexible Retrieval as a DynamoDB table class
3. DynamoDB Standard
4. DynamoDB Standard-IA

Correct Answer(s)

 

C

Rationale

1. Maintaining duplicate full tables in two classes doubles stored data and operational complexity; it does not provide a sensible cost model for the same high-frequency sessions. The deciding constraint is high request frequency; request cost dominates; small storage footprint. The requirement can be met without introducing this additional billed component.
2. S3 Glacier is an object-storage archival class and cannot be selected as a DynamoDB table class for an actively queried session store. The deciding constraint is high request frequency; request cost dominates; small storage footprint. The service behavior described here does not deliver the requested reduction in ongoing spend.
3. DynamoDB Standard is optimized for the usual balance where request activity is frequent and storage is not the dominant component of table cost. The deciding constraint is high request frequency; request cost dominates; small storage footprint. The selected mechanism reduces unused capacity without weakening the requirement the application actually has.
4. Standard-IA lowers storage price but charges more for reads and writes, which works against a workload whose bill is dominated by frequent request activity. The deciding constraint is high request frequency; request cost dominates; small storage footprint. This is technically separate from the cost lever the architect is being asked to choose.

 

Question 14

A new DynamoDB-backed service receives unpredictable promotional bursts separated by long quiet periods. The team cannot forecast read and write capacity accurately and wants to avoid paying for unused provisioned throughput. Which capacity mode fits best?

1. DynamoDB on-demand capacity mode
2. DynamoDB provisioned capacity with auto scaling disabled
3. DynamoDB provisioned capacity fixed at the promotional peak
4. A larger DynamoDB Standard-IA table class

Correct Answer(s)

 

A

Rationale

1. On-demand mode uses pay-per-request pricing and automatically manages throughput, which matches a workload with unpredictable bursts and substantial idle periods. The deciding constraint is unpredictable promotional bursts; long quiet periods; no reliable capacity forecast. The cost benefit follows from the workload characteristic explicitly given in the question.
2. Provisioned mode with auto scaling disabled requires manual capacity forecasting and can either waste capacity or throttle when the promotional pattern changes. The deciding constraint is unpredictable promotional bursts; long quiet periods; no reliable capacity forecast. The option conflicts with the workload evidence that should drive the cost decision.
3. Fixing provisioned capacity at the peak bills for that throughput during quiet periods, embedding the largest expected burst into the steady cost base. The deciding constraint is unpredictable promotional bursts; long quiet periods; no reliable capacity forecast. The added resource would not remove the charge the team is trying to reduce.
4. Table class changes storage-versus-request pricing but does not replace the table’s throughput capacity mode or solve unpredictable request-volume planning. The deciding constraint is unpredictable promotional bursts; long quiet periods; no reliable capacity forecast. It solves a different problem and leaves the stated waste largely unchanged.

 

Question 15

A mature DynamoDB workload has nearly constant traffic and a well-understood hourly request rate. The operations team can manage scaling policies and wants predictable provisioned throughput rather than pay-per-request pricing. Which capacity approach should be evaluated?

1. Change the table to Standard-IA regardless of access frequency
2. Provisioned capacity fixed at ten times normal demand
3. On-demand mode solely because it is serverless
4. Provisioned capacity with target-tracking auto scaling

Correct Answer(s)

 

D

Rationale

1. Standard-IA addresses the relationship between storage and request costs, not whether throughput should be provisioned or billed per request. The deciding constraint is steady and predictable DynamoDB traffic; team accepts scaling-policy management. The scenario does not require the capability this option primarily provides.
2. Provisioning ten times normal demand intentionally creates large unused throughput and defeats the goal of aligning paid capacity with actual traffic. The deciding constraint is steady and predictable DynamoDB traffic; team accepts scaling-policy management. It therefore adds cost or complexity without satisfying the requested optimization.
3. On-demand mode removes capacity planning and is excellent for variable workloads, but the scenario specifically has forecastable steady demand where provisioned pricing can be evaluated for cost predictability. The deciding constraint is steady and predictable DynamoDB traffic; team accepts scaling-policy management. Under these constraints, it changes architecture without addressing the relevant billing dimension.
4. Provisioned capacity is appropriate for steady, predictable workloads, and target-tracking auto scaling can adjust configured read and write capacity around expected demand without fixing it permanently at an extreme peak. The deciding constraint is steady and predictable DynamoDB traffic; team accepts scaling-policy management. After measuring the workload, this option removes excess spend at the layer where it originates.

 

Question 16

A DynamoDB table stores password-reset tokens that become useless 30 minutes after creation. The application currently runs a scheduled cleanup job that writes DeleteItem calls for expired records. Which feature can reduce cleanup overhead and avoid write-throughput consumption for expiration deletes?

1. Switch every read to strongly consistent mode
2. DynamoDB TTL on an expiration timestamp
3. Run a full table Scan every five minutes and delete old items
4. Add a global secondary index on the token value solely for cleanup

Correct Answer(s)

 

B

Rationale

1. Strongly consistent reads increase read-unit consumption and provide fresher read semantics, but they have no role in deleting records that have exceeded their retention period. The deciding constraint is tokens expire after 30 minutes; application cleanup writes are unnecessary overhead. The workload characteristic in the prompt points to a different service mechanism.
2. DynamoDB TTL lets the service remove expired items automatically, typically within days of expiration, without consuming write throughput for the TTL deletion in the source Region. The deciding constraint is tokens expire after 30 minutes; application cleanup writes are unnecessary overhead. This choice is appropriate because the constraint permits the trade-off needed to lower ongoing cost.
3. Frequent full scans consume read resources and the subsequent application deletes consume writes, making the cleanup path more expensive and operationally noisy. The deciding constraint is tokens expire after 30 minutes; application cleanup writes are unnecessary overhead. This option may be useful elsewhere, but not for the stated cost-and-usage combination.
4. A new global secondary index adds index storage and write maintenance; it does not cause expired items to be deleted automatically. The deciding constraint is tokens expire after 30 minutes; application cleanup writes are unnecessary overhead. It therefore adds cost or complexity without satisfying the requested optimization.

 

Question 17

An application reads DynamoDB product descriptions where a few seconds of replication lag is acceptable. The workload is read-heavy and currently requests strong consistency for every GetItem. Which change directly reduces read capacity consumption without changing item size?

1. Add a second identical table and read strongly from both
2. Keep strongly consistent reads and double provisioned RCUs
3. Use transactional reads for every lookup
4. Use eventually consistent reads for these product lookups

Correct Answer(s)

 

D

Rationale

1. Duplicating the table adds storage and write replication work while retaining strong reads, so it introduces cost rather than exploiting the allowed consistency trade-off. The deciding constraint is read-heavy product data; a few seconds of staleness is acceptable. The proposed change would preserve or increase the resource that is currently overprovisioned.
2. Increasing provisioned RCUs preserves the more expensive consistency choice and raises available capacity; it does not reduce units consumed by each strongly consistent read. The deciding constraint is read-heavy product data; a few seconds of staleness is acceptable. This affects another operational concern rather than the bill component named in the question.
3. Transactional reads consume more read capacity than ordinary strong reads and are intended for transactional guarantees, not lower-cost catalog lookups. The deciding constraint is read-heavy product data; a few seconds of staleness is acceptable. It does not exploit the specific tolerance or access pattern provided by the scenario.
4. Eventually consistent DynamoDB reads consume half the read units of strongly consistent reads for the same item size, making them a direct cost lever when slight staleness is acceptable. The deciding constraint is read-heavy product data; a few seconds of staleness is acceptable. The architecture keeps the necessary capability while avoiding resources the scenario does not need.

 

Question 18

A DynamoDB table has a global secondary index used only by a reporting feature that was retired six months ago. CloudWatch shows no index query traffic, but every table write still maintains the index. What is the most direct cost action after confirming no dependencies?

1. Increase the index’s projected attributes
2. Create a second copy of the same index
3. Delete the unused global secondary index
4. Switch all base-table reads to strong consistency

Correct Answer(s)

 

C

Rationale

1. Projecting more attributes into the index increases its stored data and can increase write costs, moving in the opposite direction from the cleanup objective. The deciding constraint is GSI has no consumers; base table remains active; all dependencies verified. It is not the AWS mechanism that controls the capacity or retention behavior at issue.
2. A second identical index duplicates the same storage and write-maintenance overhead without providing a new access pattern or business requirement. The deciding constraint is GSI has no consumers; base table remains active; all dependencies verified. It does not alter the usage model responsible for the recurring cost in this case.
3. Deleting an unused GSI removes its index storage and eliminates future write propagation to that index after dependency checks confirm it is no longer required. The deciding constraint is GSI has no consumers; base table remains active; all dependencies verified. The billing model matches this workload better than keeping peak or redundant capacity continuously allocated.
4. Strong consistency on base-table reads changes read semantics and cost; it does not remove the unused index or the write work required to maintain it. The deciding constraint is GSI has no consumers; base table remains active; all dependencies verified. That trade-off is unnecessary because the prompt explicitly permits a more economical design.

 

Question 19

A DynamoDB application needs a GSI to answer a query using only the partition key, sort key, status, and total attributes. The current index projects ALL attributes, including several large text fields that the query never reads. Which change best reduces index storage and write cost while keeping the query covered?

1. Move the table to Standard-IA solely to change projection behavior
2. An INCLUDE projection for status and total
3. Keep ALL projection and add another large text attribute
4. Create a duplicate GSI with ALL projection

Correct Answer(s)

 

B

Rationale

1. Table class changes DynamoDB storage-versus-request pricing but does not control which attributes are projected into an individual GSI. The deciding constraint is query needs only two non-key attributes; large unneeded fields dominate index entry size. The requirement can be met without introducing this additional billed component.
2. An INCLUDE projection keeps the index keys and selected non-key attributes needed by the query while avoiding unnecessary large fields in each index entry. The deciding constraint is query needs only two non-key attributes; large unneeded fields dominate index entry size. The option is cost-focused and remains consistent with the stated performance or retention boundary.
3. Keeping ALL projection preserves the unnecessary fields and adding another large attribute increases index storage and write amplification rather than reducing it. The deciding constraint is query needs only two non-key attributes; large unneeded fields dominate index entry size. This is technically separate from the cost lever the architect is being asked to choose.
4. A duplicate ALL-projection GSI doubles index structures for the same access pattern and adds more storage and write maintenance. The deciding constraint is query needs only two non-key attributes; large unneeded fields dominate index entry size. That trade-off is unnecessary because the prompt explicitly permits a more economical design.

 

Question 20

A relational application on SQL Server pays substantial database-engine license cost. Assessment shows that most T-SQL can run on Aurora PostgreSQL with modest compatibility work, and the business wants a managed open-source target with minimal downtime during migration. Which migration direction best addresses the recurring license-cost goal?

1. Aurora PostgreSQL with AWS migration tooling
2. Create a second SQL Server read replica and retain the primary
3. Increase SQL Server backup retention before renewing licenses
4. Move to RDS for SQL Server on a larger instance

Correct Answer(s)

 

A

Rationale

1. Aurora PostgreSQL removes the SQL Server engine-license model from the target and can be paired with AWS assessment and migration tooling to reduce migration risk and downtime. The deciding constraint is commercial SQL Server license cost is the driver; PostgreSQL compatibility is acceptable; minimize downtime. The scenario provides the prerequisite that makes this service feature a defensible optimization.
2. A second SQL Server instance retains the same commercial engine and adds compute and licensing-related cost while serving a different scaling or resilience purpose. The deciding constraint is commercial SQL Server license cost is the driver; PostgreSQL compatibility is acceptable; minimize downtime. That makes it a poor fit for the cost driver identified here.
3. Backup retention is important for recovery but does not change the target engine or recurring software-license economics driving this migration. The deciding constraint is commercial SQL Server license cost is the driver; PostgreSQL compatibility is acceptable; minimize downtime. The requirement can be met without introducing this additional billed component.
4. RDS for SQL Server remains on the commercial SQL Server engine and a larger instance increases compute cost without addressing the licensing objective. The deciding constraint is commercial SQL Server license cost is the driver; PostgreSQL compatibility is acceptable; minimize downtime. The option conflicts with the workload evidence that should drive the cost decision.

• < Amazon AWS SAA-C03 Cost-Optimized Compute, Purchasing Models, Rightsizing, and Elasticity Practice Test 3
• Amazon AWS SAA-C03 Cost-Optimized Databases, Capacity, Serverless, Caching, Retention, and Migration Practice Test 2 >