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

 

Topic 19 Practice Test 2 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

A legacy SQL Server application uses a limited set of T-SQL features, and developers want to move to Aurora PostgreSQL without rewriting the entire data-access layer at once. Which feature should be evaluated to reduce migration effort while pursuing lower commercial-engine cost?

1. RDS Proxy for SQL Server
2. Babelfish for Aurora PostgreSQL
3. Aurora MySQL parallel query
4. DynamoDB Accelerator (DAX)

Correct Answer(s)

 

B

Rationale

1. RDS Proxy manages database connections but does not translate SQL Server T-SQL into PostgreSQL-compatible behavior or change the destination engine. The deciding constraint is limited T-SQL usage; reduce rewrite effort; target Aurora PostgreSQL. That makes it a poor fit for the cost driver identified here.
2. Babelfish for Aurora PostgreSQL provides SQL Server-compatible endpoints and T-SQL semantics for supported workloads, which can reduce application changes during a migration away from SQL Server. The deciding constraint is limited T-SQL usage; reduce rewrite effort; target Aurora PostgreSQL. That is the relevant lever for this workload rather than adding capacity elsewhere.
3. Aurora MySQL is a different engine family and parallel query is a query-execution feature, not a SQL Server compatibility layer for T-SQL applications. The deciding constraint is limited T-SQL usage; reduce rewrite effort; target Aurora PostgreSQL. It solves a different problem and leaves the stated waste largely unchanged.
4. DAX is an in-memory cache for DynamoDB and has no role in translating relational SQL Server protocols or easing an Aurora PostgreSQL migration. The deciding constraint is limited T-SQL usage; reduce rewrite effort; target Aurora PostgreSQL. Under these constraints, it changes architecture without addressing the relevant billing dimension.

 

Question 2

An RDS database is configured with 8 TB of provisioned storage even though only 1.4 TB is used and growth is slow. The allocated storage cannot be reduced in place. Which strategy can produce a smaller ongoing storage footprint with controlled cutover?

1. Wait for RDS storage autoscaling to scale the volume down
2. Set MaxAllocatedStorage below the current allocated size
3. Reduce automated backup retention and expect allocated storage to shrink
4. A new, smaller RDS instance with controlled migration

Correct Answer(s)

 

D

Rationale

1. RDS storage autoscaling only grows allocated storage when thresholds are met; it does not automatically scale storage down after demand falls. The deciding constraint is 8 TB allocated; 1.4 TB used; in-place shrink is unsupported. The workload characteristic in the prompt points to a different service mechanism.
2. MaxAllocatedStorage controls the upper limit for autoscaling and cannot be set below the already allocated storage to shrink the live volume. The deciding constraint is 8 TB allocated; 1.4 TB used; in-place shrink is unsupported. It therefore adds cost or complexity without satisfying the requested optimization.
3. Backup retention affects backup data, not the provisioned database volume size, so shortening retention cannot reclaim the already allocated primary storage capacity. The deciding constraint is 8 TB allocated; 1.4 TB used; in-place shrink is unsupported. The scenario does not require the capability this option primarily provides.
4. RDS does not scale allocated storage downward in place, so correcting a large over-allocation requires moving to a new appropriately sized storage layout through migration or a supported blue/green path. It therefore aligns the paid resource with the usage pattern described in the scenario.

 

Question 3

An Aurora Serverless v2 cluster has one writer and three serverless readers. The writer must remain responsive, but two low-priority reporting readers may pause independently during long idle periods. Which reader configuration supports that cost behavior?

1. Failover priority 2–15 for independently pausing serverless readers
2. Keep a user connection permanently open on each reporting reader
3. Assign every reader failover priority 0
4. Use provisioned reader instances for the low-priority reports

Correct Answer(s)

 

A

Rationale

1. Serverless readers in failover tiers 2–15 can have capacity behavior independent of the writer, allowing eligible readers to auto-pause when their own user activity stops. The deciding constraint is writer remains active; selected readers may be idle; independent pause desired. This preserves the stated requirement while removing the specific source of avoidable spend.
2. Any open user-initiated connection prevents an eligible serverless instance from pausing, directly defeating the objective of suspending idle reporting compute. The deciding constraint is writer remains active; selected readers may be idle; independent pause desired. It does not exploit the specific tolerance or access pattern provided by the scenario.
3. Readers in failover priority 0 or 1 track the writer’s capacity and pause/resume group, so they are not the broadest choice for independent reporting-reader pause behavior. The deciding constraint is writer remains active; selected readers may be idle; independent pause desired. This option may be useful elsewhere, but not for the stated cost-and-usage combination.
4. Provisioned instances do not use Aurora Serverless auto-pause, so converting the low-priority readers to provisioned capacity removes the intended zero-ACU cost mechanism. The deciding constraint is writer remains active; selected readers may be idle; independent pause desired. The proposed change would preserve or increase the resource that is currently overprovisioned.

 

Question 4

An Aurora Serverless v2 writer is configured with a minimum of 0 ACUs, but it never auto-pauses. The same cluster also contains a provisioned Aurora reader that must stay running. Which design fact explains the behavior?

1. The cluster uses Aurora storage instead of EBS
2. A zero minimum requires a global database secondary
3. The provisioned reader prevents writer auto-pause
4. The writer endpoint always disables all Serverless v2 scaling

Correct Answer(s)

 

C

Rationale

1. All Aurora clusters use the Aurora storage layer; that storage design does not by itself disable Serverless v2 scaling or auto-pause eligibility. The deciding constraint is minimum is 0 ACUs; provisioned reader remains in same Aurora cluster. It is not the AWS mechanism that controls the capacity or retention behavior at issue.
2. Auto-pause is a Serverless v2 cluster capacity feature and does not require creating a Global Database secondary, which would add unrelated cross-Region cost. The deciding constraint is minimum is 0 ACUs; provisioned reader remains in same Aurora cluster. The proposed change would preserve or increase the resource that is currently overprovisioned.
3. In a hybrid Aurora cluster containing provisioned instances, the serverless writer must remain active while provisioned readers are active, so the writer does not auto-pause. The deciding constraint is minimum is 0 ACUs; provisioned reader remains in same Aurora cluster. The choice changes the cost driver named in the prompt without introducing an unrelated service.
4. The writer endpoint can resume a paused writer and is the normal connection endpoint, but its existence does not universally disable auto-pause. The deciding constraint is minimum is 0 ACUs; provisioned reader remains in same Aurora cluster. The choice would be justified by a different resilience or performance requirement.

 

Question 5

An RDS workload uses gp3 storage and has normal latency. A proposal recommends moving to io2 solely because it is a higher-performance storage class, even though the application does not need additional IOPS. What is the cost-optimized decision?

1. Use magnetic storage for all production databases
2. Move to io2 and provision the maximum IOPS
3. Keep gp3 with only the required performance
4. Add a read replica solely to increase storage cost

Correct Answer(s)

 

C

Rationale

1. Magnetic storage is legacy and not the general recommendation for a healthy modern production workload; cost optimization should not sacrifice appropriate performance and supportability. The deciding constraint is gp3 meets latency and throughput needs; no evidence that provisioned IOPS is required. The result would not align paid capacity with the measured demand described here.
2. io2 is valuable for demanding and latency-sensitive workloads, but maximum provisioned IOPS would add cost without a demonstrated performance requirement here. The deciding constraint is gp3 meets latency and throughput needs; no evidence that provisioned IOPS is required. The choice would be justified by a different resilience or performance requirement.
3. General Purpose SSD storage is appropriate when its performance meets the workload, so retaining gp3 avoids paying for provisioned high-end IOPS that provide no business benefit. The deciding constraint is gp3 meets latency and throughput needs; no evidence that provisioned IOPS is required. It fits the required availability and access behavior while targeting the billed resource directly.
4. A read replica adds another database instance and storage copy. It should be justified by read scaling or resilience, not used as a substitute for storage right-sizing. The deciding constraint is gp3 meets latency and throughput needs; no evidence that provisioned IOPS is required. It does not alter the usage model responsible for the recurring cost in this case.

 

Question 6

An RDS test instance was stopped to save compute cost, but the monthly bill is not zero. Which remaining cost category should the team expect while the instance stays stopped?

1. Provisioned database storage and applicable backup storage
2. Read replica CPU that was never created
3. DB instance compute hours at the running rate
4. DynamoDB request units for the RDS database

Correct Answer(s)

 

A

Rationale

1. Stopping an eligible RDS instance suspends DB instance-hour charges, but its provisioned storage and applicable backup storage remain allocated and billable while the database is stopped. The deciding constraint is RDS instance is stopped; data and backups are retained. The scenario’s constraint makes this trade-off appropriate after validating workload measurements.
2. No read replica exists in the scenario, so there is no replica CPU resource whose cost could explain the remaining bill. The deciding constraint is RDS instance is stopped; data and backups are retained. This is technically separate from the cost lever the architect is being asked to choose.
3. The central savings from stopping RDS is that DB instance compute hours are not charged during the stopped interval, so the running compute rate is not the expected residual charge. The deciding constraint is RDS instance is stopped; data and backups are retained. The requirement can be met without introducing this additional billed component.
4. RDS does not use DynamoDB read or write request units; those charges belong to a different database service and capacity model. The deciding constraint is RDS instance is stopped; data and backups are retained. The service behavior described here does not deliver the requested reduction in ongoing spend.

 

Question 7

A company keeps hundreds of manual RDS snapshots indefinitely even after the related applications are decommissioned. Legal retention requires only the last 13 monthly recovery points. Which action most directly reduces backup-storage cost while respecting the requirement?

1. Increase automated backup retention for every database
2. Create a read replica for each historical snapshot
3. Copy every snapshot to a second Region before deleting none
4. A 13-snapshot lifecycle that deletes older snapshots

Correct Answer(s)

 

D

Rationale

1. Longer automated retention creates more retained backup history rather than addressing the manual snapshots already kept beyond policy. The deciding constraint is manual snapshots accumulate indefinitely; policy requires exactly 13 monthly recovery points. That makes it a poor fit for the cost driver identified here.
2. Read replicas are live database instances for availability or read scaling and are not a cost-effective substitute for retained historical recovery points. The deciding constraint is manual snapshots accumulate indefinitely; policy requires exactly 13 monthly recovery points. The option conflicts with the workload evidence that should drive the cost decision.
3. Copying every snapshot to another Region without deleting obsolete copies multiplies retained storage and data-transfer activity instead of enforcing the required lifecycle. The deciding constraint is manual snapshots accumulate indefinitely; policy requires exactly 13 monthly recovery points. It solves a different problem and leaves the stated waste largely unchanged.
4. Deleting manual snapshots beyond the validated retention requirement removes unnecessary backup storage while the lifecycle preserves the 13 recovery points the business must keep. The deciding constraint is manual snapshots accumulate indefinitely; policy requires exactly 13 monthly recovery points. This is the service-native mechanism intended for the cost pattern described here.

 

Question 8

A DynamoDB table stores only records that have a `needsReview` attribute when an order requires manual intervention. Analysts query only those exceptional orders. Which index design keeps the secondary index small?

1. Project every order into a second full table
2. A sparse GSI keyed only on needsReview items
3. Run a full table Scan for every analyst request
4. Write the index key attributes on every order

Correct Answer(s)

 

B

Rationale

1. A second full table duplicates all items and creates another synchronization burden instead of representing only the exception set. The deciding constraint is only exceptional records require the alternate access pattern; exception attribute is absent on normal items. The added resource would not remove the charge the team is trying to reduce.
2. A DynamoDB GSI is sparse when only items containing its key attributes are written to the index, which keeps storage and index write activity focused on the exceptional subset. The deciding constraint is only exceptional records require the alternate access pattern; exception attribute is absent on normal items. It addresses the recurring charge while leaving unrelated resilience requirements unchanged.
3. Repeated full scans consume read resources across the entire base table and scale cost with table size rather than the small number of orders requiring review. The deciding constraint is only exceptional records require the alternate access pattern; exception attribute is absent on normal items. The scenario does not require the capability this option primarily provides.
4. Adding the GSI key attributes to every order makes the index dense, causing normal orders to consume index storage and maintenance writes even though analysts never need them. The deciding constraint is only exceptional records require the alternate access pattern; exception attribute is absent on normal items. It solves a different problem and leaves the stated waste largely unchanged.

 

Question 9

A DynamoDB analytics job uses Scan plus a filter expression to return only 2% of a large table. The team assumes the filter will reduce read capacity cost. What change is more likely to reduce consumed reads if the access pattern is frequent and queryable by key?

1. Use a ProjectionExpression alone and continue scanning the full table
2. Switch every Scan to strongly consistent reads
3. Keep Scan and add more FilterExpression clauses
4. A Queryable key or index for the required subset

Correct Answer(s)

 

D

Rationale

1. Projection changes which attributes are returned but DynamoDB read capacity is still based on item sizes read, so it does not fix a full-table access pattern. The deciding constraint is filter returns 2% of a large table; workload runs frequently; subset can be modeled by key. It therefore adds cost or complexity without satisfying the requested optimization.
2. Strong consistency increases the read-unit cost of Scan and does not make the access path selective, so it would worsen the stated cost problem. The deciding constraint is filter returns 2% of a large table; workload runs frequently; subset can be modeled by key. This option may be useful elsewhere, but not for the stated cost-and-usage combination.
3. A filter expression is evaluated after Scan reads items, so adding more filter predicates can reduce returned data without proportionally reducing the capacity consumed by the scanned items. The deciding constraint is filter returns 2% of a large table; workload runs frequently; subset can be modeled by key. The scenario does not require the capability this option primarily provides.
4. A Query-compatible key design lets DynamoDB read the targeted key range instead of scanning the full table and discarding most items after the read operation. The deciding constraint is filter returns 2% of a large table; workload runs frequently; subset can be modeled by key. The design is economical because the paid capacity follows the demand or retention need stated.

 

Question 10

A DynamoDB table has large 7 KB items. A microservice frequently reads one 200-byte attribute using GetItem and a ProjectionExpression. The team expects the projection to cut read capacity in proportion to returned bytes. Which statement is correct for cost planning?

1. Projection bills only the returned 200 bytes
2. Capacity is billed from full item size, not projected bytes
3. Projection automatically moves the attribute into DAX at no cost
4. Projection converts the request to a free metadata read

Correct Answer(s)

 

B

Rationale

1. Projection reduces response payload and can simplify application handling, but it does not make DynamoDB charge solely for the bytes returned to the client. The deciding constraint is 7 KB item; only 200 bytes returned; GetItem uses ProjectionExpression. The proposed change would preserve or increase the resource that is currently overprovisioned.
2. DynamoDB calculates read capacity from the size of the item accessed, rounded according to the read-unit rules, even when a ProjectionExpression returns only selected attributes. The deciding constraint is 7 KB item; only 200 bytes returned; GetItem uses ProjectionExpression. That makes the option the closest match to both the technical constraint and cost objective.
3. DAX is an optional managed cache that must be provisioned and used explicitly. A ProjectionExpression does not automatically create or populate a DAX cache. The deciding constraint is 7 KB item; only 200 bytes returned; GetItem uses ProjectionExpression. This option may be useful elsewhere, but not for the stated cost-and-usage combination.
4. A projected attribute remains part of a normal DynamoDB read; there is no separate free metadata-read category created by ProjectionExpression. The deciding constraint is 7 KB item; only 200 bytes returned; GetItem uses ProjectionExpression. This affects another operational concern rather than the bill component named in the question.

 

Question 11

A DynamoDB table has highly seasonal traffic but usually stays near zero requests for several months. Which characteristic of on-demand capacity is especially relevant to its cost model during those quiet months?

1. On-demand requires a fixed minimum RCU and WCU reservation
2. On-demand bills for the previous traffic peak every hour
3. On-demand pay-per-request throughput billing
4. On-demand converts table storage into free storage during idle months

Correct Answer(s)

 

C

Rationale

1. Fixed read and write capacity units are a provisioned-mode concept; on-demand does not require a baseline RCU or WCU reservation for quiet periods. The deciding constraint is seasonal workload; months of nearly zero requests; data remains stored. This affects another operational concern rather than the bill component named in the question.
2. The previous peak influences rapid scaling behavior, but on-demand billing is not an hourly reservation at that historical peak. The deciding constraint is seasonal workload; months of nearly zero requests; data remains stored. It is not the AWS mechanism that controls the capacity or retention behavior at issue.
3. With on-demand capacity, DynamoDB bills read and write requests as they occur rather than charging for provisioned throughput, so zero traffic does not generate throughput charges. The deciding constraint is seasonal workload; months of nearly zero requests; data remains stored. The optimization is targeted: it changes the resource creating waste instead of shifting the problem.
4. Capacity mode governs throughput billing, not stored-data billing. DynamoDB table storage remains chargeable even when an on-demand table receives no requests. The deciding constraint is seasonal workload; months of nearly zero requests; data remains stored. The choice would be justified by a different resilience or performance requirement.

 

Question 12

A DynamoDB table is provisioned at 50,000 RCUs because of a one-hour daily peak, but typical demand is 4,000 RCUs. Traffic follows a repeatable pattern. Which configuration reduces prolonged overprovisioning while retaining provisioned mode?

1. DynamoDB auto scaling with bounded target utilization
2. Create a global table solely to absorb the peak
3. Keep 50,000 RCUs fixed all day
4. Switch to strongly consistent reads for all requests

Correct Answer(s)

 

A

Rationale

1. Target-tracking auto scaling can increase and decrease provisioned capacity within defined bounds as demand changes, avoiding a fixed peak-sized allocation throughout the day. The deciding constraint is repeatable one-hour peak; typical demand far lower; remain in provisioned mode. This approach uses the documented billing behavior that matters for the stated access pattern.
2. Global tables replicate data across Regions for multi-Region access and resilience; they add replicated write and storage cost rather than right-size a predictable local peak. The deciding constraint is repeatable one-hour peak; typical demand far lower; remain in provisioned mode. It does not alter the usage model responsible for the recurring cost in this case.
3. A fixed 50,000-RCU setting preserves the exact overprovisioning problem during the many hours when demand is only a fraction of that level. The deciding constraint is repeatable one-hour peak; typical demand far lower; remain in provisioned mode. This is technically separate from the cost lever the architect is being asked to choose.
4. Strongly consistent reads consume more capacity per item than eventual reads and do not adjust how much throughput is provisioned. The deciding constraint is repeatable one-hour peak; typical demand far lower; remain in provisioned mode. That trade-off is unnecessary because the prompt explicitly permits a more economical design.

 

Question 13

A Redshift analytics workload runs only for ad hoc business reviews a few times each week, and there is little value in keeping provisioned compute running between sessions. Which deployment model should the architect evaluate first?

1. Amazon Redshift Serverless
2. An RDS read replica used as a data warehouse
3. A permanently running large provisioned Redshift cluster
4. A larger Redshift provisioned cluster with no pause schedule

Correct Answer(s)

 

A

Rationale

1. Redshift Serverless meters compute in RPUs as work is performed and can be a strong fit for intermittent analytics where dedicated cluster capacity would sit idle much of the week. The deciding constraint is ad hoc analytics only a few times weekly; long idle periods. The selected mechanism reduces unused capacity without weakening the requirement the application actually has.
2. An RDS read replica is still an operational relational database instance and does not provide the columnar warehouse architecture or serverless billing model requested. The deciding constraint is ad hoc analytics only a few times weekly; long idle periods. The option conflicts with the workload evidence that should drive the cost decision.
3. A permanently running large provisioned cluster reserves compute even when analysts are not querying, which embeds idle capacity into the cost structure. The deciding constraint is ad hoc analytics only a few times weekly; long idle periods. This is technically separate from the cost lever the architect is being asked to choose.
4. Increasing provisioned Redshift size without a pause or right-sizing strategy raises the idle compute footprint instead of matching cost to intermittent demand. The deciding constraint is ad hoc analytics only a few times weekly; long idle periods. The service behavior described here does not deliver the requested reduction in ongoing spend.

 

Question 14

A Redshift Serverless workgroup serves small BI dashboards. Monitoring shows the queries use little capacity, but the base capacity is much higher than needed. What is the most direct configuration lever for recurring compute cost?

1. Store a second copy of every table in the same namespace
2. Duplicate the workgroup in another Region
3. A lower tested Redshift Serverless base RPU capacity
4. Raise base RPU capacity to the maximum

Correct Answer(s)

 

C

Rationale

1. Duplicating tables adds storage and maintenance overhead without changing the workgroup’s base RPU setting or reducing the compute resources used to serve dashboards. The deciding constraint is light BI workload; observed utilization is low; performance must remain acceptable. That makes it a poor fit for the cost driver identified here.
2. A second Regional workgroup adds compute and data-transfer considerations for resilience, not a cost correction for an oversized single workgroup. The deciding constraint is light BI workload; observed utilization is low; performance must remain acceptable. The option conflicts with the workload evidence that should drive the cost decision.
3. Redshift Serverless base capacity controls the starting warehouse resources and cost-performance balance, so lowering an oversized base after testing can reduce compute spend. The deciding constraint is light BI workload; observed utilization is low; performance must remain acceptable. The cost benefit follows from the workload characteristic explicitly given in the question.
4. Raising base capacity allocates more resources for complex or concurrent workloads and moves cost in the wrong direction when current dashboards already use little capacity. The deciding constraint is light BI workload; observed utilization is low; performance must remain acceptable. It solves a different problem and leaves the stated waste largely unchanged.

 

Question 15

A Redshift Serverless environment is shared by analysts, and management wants a hard guardrail against an unexpected query burst consuming excessive compute in one day. Which mechanism directly addresses the requirement?

1. Increase the base RPU capacity without a limit
2. Configure a Redshift Serverless usage limit for RPU-hours
3. Use an RDS Reserved DB Instance
4. Add more table replicas in managed storage

Correct Answer(s)

 

B

Rationale

1. Increasing base capacity gives queries more resources but does not establish a ceiling on daily RPU-hours and can increase the rate of spend. The deciding constraint is shared serverless warehouse; management requires daily compute-spend guardrail. It therefore adds cost or complexity without satisfying the requested optimization.
2. Redshift Serverless usage limits can constrain RPU consumption over a defined period, providing a direct control against runaway serverless compute spend. The deciding constraint is shared serverless warehouse; management requires daily compute-spend guardrail. After measuring the workload, this option removes excess spend at the layer where it originates.
3. RDS Reserved DB Instances apply to Amazon RDS instance usage, not Redshift Serverless RPU consumption, so they cannot enforce this workgroup guardrail. The deciding constraint is shared serverless warehouse; management requires daily compute-spend guardrail. Under these constraints, it changes architecture without addressing the relevant billing dimension.
4. Table copies consume storage and maintenance resources yet do not cap how much Redshift Serverless compute analysts can use. The deciding constraint is shared serverless warehouse; management requires daily compute-spend guardrail. The scenario does not require the capability this option primarily provides.

 

Question 16

A provisioned Redshift development cluster is needed only during business hours. The team wants to keep the data but avoid paying for cluster compute overnight. Which operational feature should be considered?

1. Create a second always-on cluster
2. Resize the cluster larger before every night
3. Increase automated snapshot retention as the only action
4. Scheduled Redshift pause and resume

Correct Answer(s)

 

D

Rationale

1. A second always-on cluster duplicates compute and storage resources instead of eliminating overnight idle capacity. The deciding constraint is development warehouse; predictable off-hours; data must persist. It does not exploit the specific tolerance or access pattern provided by the scenario.
2. Resizing larger before an idle period increases provisioned resources when no work is expected and therefore contradicts the cost objective. The deciding constraint is development warehouse; predictable off-hours; data must persist. This option may be useful elsewhere, but not for the stated cost-and-usage combination.
3. Snapshot retention protects recovery history but does not itself suspend provisioned warehouse compute, so the cluster would continue generating its normal running charges. The deciding constraint is development warehouse; predictable off-hours; data must persist. It therefore adds cost or complexity without satisfying the requested optimization.
4. Provisioned Redshift clusters can be paused and resumed, allowing development compute to be unavailable during planned idle periods while data is retained for later use. The deciding constraint is development warehouse; predictable off-hours; data must persist. This choice is appropriate because the constraint permits the trade-off needed to lower ongoing cost.

 

Question 17

A large provisioned Redshift production cluster runs continuously at stable utilization. Forecasts show the same baseline for the next year. Which purchasing strategy can reduce the cost of that predictable provisioned compute?

1. Increase the cluster node count without commitment
2. Evaluate Redshift reserved-node pricing for the steady baseline
3. Create a second identical on-demand cluster
4. Convert every query to Redshift Spectrum regardless of data location

Correct Answer(s)

 

B

Rationale

1. Adding nodes without a commitment increases capacity and recurring charges; it should be justified by workload demand rather than used as a purchasing optimization. The deciding constraint is provisioned Redshift; continuous stable baseline; one-year forecast. This affects another operational concern rather than the bill component named in the question.
2. Reserved-node pricing can lower the effective cost of predictable, continuously used provisioned Redshift capacity when the organization is willing to commit for a term. The deciding constraint is provisioned Redshift; continuous stable baseline; one-year forecast. The architecture keeps the necessary capability while avoiding resources the scenario does not need.
3. A second identical cluster duplicates the running compute footprint, which increases cost instead of discounting the stable capacity the business already needs. The deciding constraint is provisioned Redshift; continuous stable baseline; one-year forecast. The proposed change would preserve or increase the resource that is currently overprovisioned.
4. Spectrum is useful for querying data in S3 but it is not a universal replacement for local warehouse processing, nor does it automatically discount steady provisioned nodes. The deciding constraint is provisioned Redshift; continuous stable baseline; one-year forecast. It is not the AWS mechanism that controls the capacity or retention behavior at issue.

 

Question 18

A company maintains two Redshift clusters for separate teams. Both teams need to query the same 20 TB curated dataset, and the current process physically copies that dataset into each cluster every night. Which architecture can reduce duplicate storage and ETL work?

1. Redshift data sharing from the producer
2. Create a third duplicate cluster as a central copy
3. Continue full nightly copies to every cluster
4. Export and reimport the 20 TB dataset for each query

Correct Answer(s)

 

A

Rationale

1. Redshift data sharing lets authorized consumers access live shared data without requiring a separate physical copy of the shared dataset in each consumer cluster. The deciding constraint is two Redshift consumers; same 20 TB curated data; duplicate copies are the cost driver. The billing model matches this workload better than keeping peak or redundant capacity continuously allocated.
2. A third duplicate cluster introduces another compute and storage footprint and still does not remove the copies maintained by the existing consumer teams. The deciding constraint is two Redshift consumers; same 20 TB curated data; duplicate copies are the cost driver. That trade-off is unnecessary because the prompt explicitly permits a more economical design.
3. Nightly full copies preserve the duplicated storage and recurring data movement that the architecture is trying to eliminate. The deciding constraint is two Redshift consumers; same 20 TB curated data; duplicate copies are the cost driver. It does not alter the usage model responsible for the recurring cost in this case.
4. Exporting and reimporting tens of terabytes for each query adds substantial transfer and processing work and is less efficient than governed sharing. The deciding constraint is two Redshift consumers; same 20 TB curated data; duplicate copies are the cost driver. It is not the AWS mechanism that controls the capacity or retention behavior at issue.

 

Question 19

A DynamoDB archive table has storage costs above 70% of its monthly bill and almost no request traffic. The table currently uses reserved capacity under Standard. Before changing to Standard-IA, what cost detail must the architect explicitly include in the analysis?

1. Standard-IA disables encryption at rest
2. Standard-IA removes point-in-time recovery support
3. Include lost reserved-capacity discount in the Standard-IA comparison
4. Standard-IA forces all reads to be strongly consistent

Correct Answer(s)

 

C

Rationale

1. DynamoDB table classes do not disable the service’s encryption-at-rest capabilities, so encryption is not the special cost caveat in this comparison. The deciding constraint is archive table; storage dominates; existing reserved capacity discount under Standard. That trade-off is unnecessary because the prompt explicitly permits a more economical design.
2. Standard-IA remains compatible with DynamoDB features such as point-in-time recovery; changing class does not inherently remove that recovery capability. The deciding constraint is archive table; storage dominates; existing reserved capacity discount under Standard. The result would not align paid capacity with the measured demand described here.
3. AWS notes that reserved capacity is not supported for Standard-IA tables, so an existing reserved-capacity discount must be included when comparing total cost between classes. The deciding constraint is archive table; storage dominates; existing reserved capacity discount under Standard. The option is cost-focused and remains consistent with the stated performance or retention boundary.
4. Table class and read consistency are independent choices. Standard-IA does not force strongly consistent reads or alter the application’s consistency setting. The deciding constraint is archive table; storage dominates; existing reserved capacity discount under Standard. This is technically separate from the cost lever the architect is being asked to choose.

 

Question 20

A company is retiring an RDS database after exporting all required historical records to an approved long-term archive. It no longer needs point-in-time restore or any manual snapshots for that system. What is the final cost action after retention approval and validation?

1. Increase backup retention to the maximum indefinitely
2. Leave the DB stopped forever with all snapshots
3. Create an additional read replica before decommissioning
4. Delete the retired DB instance and obsolete snapshots

Correct Answer(s)

 

D

Rationale

1. Maximum indefinite retention keeps more backup data and directly conflicts with the validated decision that no database recovery artifacts are required. The deciding constraint is application retired; historical data already archived; recovery retention no longer required. The requirement can be met without introducing this additional billed component.
2. A stopped RDS instance still incurs storage and applicable backup costs, so leaving it stopped indefinitely preserves a residual bill for a system with no recovery requirement. The deciding constraint is application retired; historical data already archived; recovery retention no longer required. The option conflicts with the workload evidence that should drive the cost decision.
3. A read replica creates another live database copy and cost center, which is unnecessary when the application is being retired. The deciding constraint is application retired; historical data already archived; recovery retention no longer required. The service behavior described here does not deliver the requested reduction in ongoing spend.
4. Once archival, legal retention, and recovery requirements are formally satisfied, deleting the unused database and obsolete snapshots removes ongoing storage and related resource charges. The deciding constraint is application retired; historical data already archived; recovery retention no longer required. The scenario provides the prerequisite that makes this service feature a defensible optimization.

• < Amazon AWS SAA-C03 Cost-Optimized Databases, Capacity, Serverless, Caching, Retention, and Migration Practice Test 1
• Amazon AWS SAA-C03 Cost-Optimized Networking, NAT, Endpoints, Connectivity, Routing, and Edge Caching Practice Test 1 >