DBS-C01 Flashcards — Free AWS Certified Database Specialty DBS-C01 Study Cards

Create a covering index on the filter column

A covering index includes all columns needed by the reporting queries, allowing PostgreSQL to satisfy the query entirely from the index without accessing the heap (table) pages. This eliminates the overhead of random I/O for row lookups, which is especially beneficial when filtering on a high-cardinality, low-selectivity column where many rows match but the index scan alone can return the required data. In Amazon RDS for PostgreSQL, this reduces read IOPS consumption and improves query latency.

Enable DynamoDB Time to Live (TTL) on the session token attribute

DynamoDB Time to Live (TTL) automatically deletes expired items after a specified timestamp, making it ideal for session data that must be removed after 24 hours. This approach requires no additional infrastructure, meets the single-digit millisecond latency requirement by using the session token as the primary key, and ensures automatic cleanup without manual intervention or added cost.

AWS Database Migration Service (AWS DMS) with ongoing replication from Oracle to Aurora PostgreSQL

AWS DMS with ongoing replication (change data capture, CDC) is the correct choice because it enables a near-zero-downtime migration by continuously replicating changes from the source Oracle database to the target Aurora PostgreSQL while the source remains fully operational. After the initial full load, DMS applies ongoing transactions, allowing you to cut over with minimal interruption. This directly addresses the requirement to minimize downtime for the nightly batch job and ensures data integrity through transactional consistency.

Use a composite primary key with a partition key of follower ID and a sort key of timestamp, and store the followee ID as an attribute

It models the access pattern directly: the follower ID as the partition key ensures all posts from followed users are co-located, and the sort key of timestamp allows efficient retrieval of the most recent 10 posts via a Query with a limit of 10 and descending order. This design avoids expensive scans or secondary index lookups, meeting the low-latency and scalability requirements.

Use AWS Database Migration Service (AWS DMS) with ongoing replication.

AWS DMS with ongoing replication (change data capture, CDC) is the correct choice because it allows continuous synchronization of the source PostgreSQL database with the target RDS for PostgreSQL instance after an initial full load. This minimizes downtime by enabling the target to stay up-to-date with changes until the cutover, which is critical for a 2 TB database with a high write workload.

AWS Schema Conversion Tool (AWS SCT)

AWS Schema Conversion Tool (AWS SCT) is designed specifically to convert database schemas from one engine to another, including Oracle to Amazon Aurora PostgreSQL. It automatically translates Oracle DDL (tables, indexes, stored procedures, functions, etc.) into PostgreSQL-compatible format, handling data type mappings, PL/SQL to PL/pgSQL conversion, and other schema-level transformations. AWS DMS handles data migration, not schema conversion, making SCT the correct choice for this requirement.

Increase the number of parallel threads in the DMS task settings.

Increasing the number of parallel threads in the DMS task settings allows AWS DMS to process multiple table partitions or row changes concurrently, which directly addresses the bottleneck caused by a high volume of write operations on the source. By default, DMS uses a single thread per table, but when the source is under heavy write load, parallel threads can capture and apply changes more efficiently, reducing the overall migration time.

The application is connecting to the DB instance in a different Availability Zone, increasing network latency.

After failover, the new primary DB instance resides in us-east-1b, while the application likely continues to connect to the original endpoint or is still running in us-east-1a. This cross-AZ network hop introduces additional latency for write operations, as the application must send data over the network between Availability Zones. The DB instance class and storage are identical, so performance differences are not due to hardware changes.

Use pg_terminate_backend to terminate the long-running queries.

The immediate cause of high CPU utilization is the long-running active queries consuming resources. Using pg_terminate_backend to terminate these queries will quickly free up CPU cycles, providing immediate relief. This is the first troubleshooting step before making configuration changes or scaling, as it directly addresses the symptom shown in the pg_stat_activity output.

Switch to provisioned capacity mode and configure auto scaling.

DynamoDB on-demand capacity mode does not allow manual adjustment of capacity units; it scales automatically but can still throttle if traffic exceeds the previous peak by a large margin. Switching to provisioned capacity mode with auto scaling allows you to set a higher minimum capacity and scale proactively based on actual usage patterns, reducing throttling without code changes. This approach gives more control over capacity limits while still automating adjustments.

Create one or more read replicas and redirect read traffic to them.

Creating read replicas offloads read queries from the primary DB instance to replica instances, directly reducing the number of read I/O operations on the primary. Since the application is read-heavy and Read IOPS is high during business hours, distributing read traffic to replicas alleviates the I/O bottleneck on the primary instance without requiring a larger instance or storage changes.

Increase the provisioned write capacity for the table.

The developer reports throttled write requests, which directly indicates that the provisioned write capacity (500 WCUs) is insufficient to handle the peak write traffic. Increasing the provisioned write capacity for the table is the most direct and effective action to eliminate write throttling, as it raises the limit on write operations per second. Option C is correct because it addresses the root cause—write capacity exhaustion—without introducing unnecessary components or changing read behavior.

Upgrade to a larger instance type, such as db.r5.xlarge.

The db.r5.large instance type has 2 vCPUs and 16 GiB of memory. Sustained CPU utilization above 90% during peak hours indicates that the instance is compute-bound for the workload. Upgrading to db.r5.xlarge (4 vCPUs, 32 GiB memory) doubles the available CPU capacity, directly reducing CPU utilization for the same query load. The on-premises server had similar specifications, but RDS instances may have different CPU architectures or hypervisor overhead, making the larger instance the most direct fix.

Configure the DynamoDB table to use AWS KMS encryption with a CMK. Create an IAM role with a policy that grants access to the table and includes a condition that the encryption context matches the CMK.

It combines DynamoDB encryption at rest with a customer-managed KMS CMK and uses an IAM role policy with an encryption context condition. This ensures that only specific IAM roles can access the table, and the encryption context condition ties the KMS key usage to the table, providing fine-grained access control with minimal operational overhead. The encryption context is automatically set by DynamoDB to the table ARN, so the condition key `kms:EncryptionContext:aws:dynamodb:tableName` can be used to restrict decryption to that specific table.

Update the security group inbound rule to allow traffic from the application server's private IP address.

The application server is in a private subnet, so it communicates with the RDS instance using its private IP address. The security group inbound rule must allow traffic from the application server's private IP (or the security group of the application server) on port 5432. The current rule only allows the application server's public IP, which is not used for traffic within the VPC, causing the connection failure.

The IAM role used for publishing logs does not have the necessary permissions to use the KMS key for CloudWatch Logs.

When publishing database audit logs to CloudWatch Logs with a customer-managed KMS key, the IAM role used by RDS must have explicit permissions for the `kms:Encrypt` and `kms:Decrypt` actions on the KMS key. Without these permissions, RDS cannot encrypt the log stream, and the logs will not appear. Option C correctly identifies this missing permission as the most likely cause.