Amazon Web Services
Expert
DBS-C01
AWS Certified Database - Specialty
The AWS Certified Database - Specialty (DBS-C01) validates expertise in recommending, designing, and maintaining optimal AWS database solutions. This specialty certification targets database administrators, developers, and architects with five or more years of experience working with relational and non-relational database technologies, including at least two years working with AWS.
The exam covers five domains: Workload-Specific Database Design (26%), Deployment and Migration (20%), Management and Operations (18%), Monitoring and Troubleshooting (18%), and Database Security (18%). Candidates must demonstrate deep knowledge of Amazon RDS (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server), Amazon Aurora, Amazon DynamoDB, Amazon ElastiCache (Redis, Memcached), Amazon Neptune, Amazon DocumentDB, Amazon Keyspaces, Amazon Timestream, and Amazon MemoryDB for Redis.
Key skills tested include choosing the right database engine for specific workloads, designing for high availability with Multi-AZ and read replicas, implementing database migration strategies using AWS DMS and SCT, configuring automated backups, point-in-time recovery, and cross-region replication, optimizing database performance through indexing, caching, and query optimization, and implementing database encryption, IAM authentication, and network isolation.
Updated Jun 2024
Database
65
Sorular
6
Deneme Sınavları
75%
Geçme Puanı
80
Görüntülenme
0
Toplam Deneme
0%
Ort. Puan
0%
Geçme Oranı
0
Tartışmalar
DBS-C01 Practice Exam 1
Comprehensive practice exam covering AWS database design, deployment, migration, management, operations, monitoring, troubleshooting, and security across 65 specialty-level questions.
65 Q
180 dakika
75%
DBS-C01 Practice Exam 2
Comprehensive practice exam covering AWS database design, deployment, migration, management, operations, monitoring, troubleshooting, and security across 65 specialty-level questions.
65 Q
180 dakika
75%
DBS-C01 Practice Exam 3
Comprehensive practice exam covering AWS database design, deployment, migration, management, operations, monitoring, troubleshooting, and security across 65 specialty-level questions.
65 Q
180 dakika
75%
DBS-C01 Practice Exam 4
Comprehensive practice exam covering AWS database design, deployment, migration, management, operations, monitoring, troubleshooting, and security across 65 specialty-level questions.
65 Q
180 dakika
75%
DBS-C01 Practice Exam 5
Comprehensive practice exam covering AWS database design, deployment, migration, management, operations, monitoring, troubleshooting, and security across 65 specialty-level questions.
65 Q
180 dakika
75%
DBS-C01 Practice Exam 6
Comprehensive practice exam covering AWS database design, deployment, migration, management, operations, monitoring, troubleshooting, and security across 65 specialty-level questions.
65 Q
180 dakika
75%
Tüm İçeriğin Kilidini Aç DBS-C01
6 Deneme Sınavı + Bilgi Kartları — 3 ay erişim
€39.99
€26.99
%30 Tasarruf
veya Aylık abonelik / İçerik Paketi ile dahil
Önizleme (10 / 120)
How does encryption at rest work for Amazon RDS databases and what key management options are available?
Amazon RDS encryption at rest protects your data by encrypting the underlying storage of DB instances, automated backups, read replicas, and snapshots using AES-256 encryption through AWS Key Management Service. You can choose between AWS managed keys, which RDS creates and manages automatically with the alias aws/rds, or customer managed keys (CMKs) that you create and control in KMS, providing granular key policy management and the ability to audit key usage through CloudTrail. Encryption must be enabled at instance creation time and cannot be added to an existing unencrypted instance. To encrypt an existing unencrypted database, you must create an unencrypted snapshot, copy the snapshot with encryption enabled specifying your desired KMS key, and then restore a new encrypted instance from the encrypted snapshot. All data written to disk including the database volume, temporary tablespace, redo logs, and transaction logs is encrypted transparently without application changes. Read replicas of an encrypted instance are automatically encrypted using the same or a different KMS key, and cross-Region read replicas require a KMS key in the destination Region. Automated backups and manual snapshots inherit the encryption status of the source instance.
What is AWS Database Migration Service (DMS) and what task types does it support?
AWS Database Migration Service (DMS) is a managed service that migrates databases to AWS quickly and securely while keeping the source database fully operational during the migration, minimizing downtime. DMS supports three task types that define the scope of the migration. Full load migration copies all existing data from the source to the target in a single bulk operation. This is appropriate when you can tolerate a brief period of downtime and do not need ongoing replication. Full load plus CDC (Change Data Capture) first performs a full load of existing data and then continuously replicates ongoing changes from the source to the target. This approach minimizes downtime because the source remains operational while incremental changes are captured and applied. CDC only replicates only ongoing changes without performing an initial full load, which is useful when you have already loaded the data through another mechanism such as native database export/import or Snowball. DMS tasks run on replication instances that you provision within your VPC and connect to both source and target endpoints. You configure table mappings to specify which schemas, tables, and columns to include or exclude, and you can apply transformation rules to rename schemas, tables, or columns during migration.
What factors should you consider when selecting an AWS database engine for a specific workload?
Selecting the right AWS database engine requires evaluating multiple workload characteristics. First, consider the data model: relational data with complex joins and ACID transactions suits RDS or Aurora, key-value access patterns fit DynamoDB, graph relationships require Neptune, document-oriented data aligns with DocumentDB, and time-series telemetry belongs in Timestream. Second, assess performance requirements including read/write latency expectations, throughput needs measured in operations per second, and whether the workload is read-heavy, write-heavy, or balanced. Third, evaluate scalability requirements: DynamoDB offers virtually unlimited horizontal scaling while RDS scales vertically with read replicas for read distribution. Fourth, consider consistency requirements, as some workloads demand strong consistency while others tolerate eventual consistency for better performance. Fifth, examine operational complexity tolerance, because managed services like Aurora Serverless reduce operational burden compared to self-managed RDS instances. Sixth, factor in cost patterns, since DynamoDB on-demand pricing suits unpredictable workloads while provisioned capacity or reserved instances benefit steady-state workloads. Finally, consider data access patterns, query complexity, existing application compatibility, compliance requirements, and the team expertise with specific database technologies.
What are the key differences between Amazon Aurora MySQL and Aurora PostgreSQL, and when would you choose each?
Amazon Aurora MySQL and Aurora PostgreSQL are both cloud-native engines built on the Aurora distributed storage layer, but they serve different use cases. Aurora MySQL is compatible with MySQL 5.7 and 8.0, making it ideal for migrating existing MySQL workloads. It supports features like Aurora parallel query for analytical queries on transactional data, Aurora MySQL zero-downtime patching, and native integration with Lambda for invoking functions from stored procedures. It excels in web application workloads, content management systems, and e-commerce platforms with straightforward relational schemas. Aurora PostgreSQL is compatible with PostgreSQL and supports advanced features including PostGIS for geospatial data, JSONB for semi-structured document storage, common table expressions for complex recursive queries, full-text search, and rich data types like arrays, hstore, and ranges. Choose Aurora PostgreSQL when workloads require complex analytical queries, geospatial processing, advanced indexing with partial and expression-based indexes, or when migrating from Oracle using the Babelfish compatibility layer. Aurora PostgreSQL also supports pgvector for machine learning vector similarity searches. Both engines share the same six-copy storage across three Availability Zones, support up to 15 read replicas with sub-10ms replica lag, automatic storage scaling up to 128 TiB, and continuous backup to S3.
What is the difference between AWS managed keys, customer managed keys, and custom key stores in KMS for database encryption?
AWS KMS provides three tiers of key management for database encryption, each offering different levels of control and responsibility. AWS managed keys are created, rotated, and managed entirely by AWS on your behalf, identified by aliases like aws/rds or aws/dynamodb. They rotate automatically every year, cannot be deleted or have their key policies modified, and provide the simplest option with no additional cost beyond the service encryption charges. Customer managed keys (CMKs) are KMS keys you explicitly create and manage, giving you full control over key policies that define who can use and administer the key, the ability to enable or disable the key to immediately prevent all encryption and decryption operations, configurable automatic rotation on an annual basis, and comprehensive CloudTrail audit logs showing every cryptographic operation. CMKs cost $1 per month per key plus per-request charges. You can grant cross-account access to CMKs through key policies and grants, enabling scenarios where a central security account manages encryption keys used by database accounts. Custom key stores use AWS CloudHSM clusters as the backing for your KMS keys, providing FIPS 140-2 Level 3 validated hardware security modules where you control the HSM cluster and key material never leaves the HSMs in plaintext. This option satisfies the most stringent regulatory requirements for key custody.
How do DMS source and target endpoints work, and what authentication methods are supported?
DMS endpoints define the connection information for the source database you are migrating from and the target database you are migrating to. Each endpoint specifies the engine type such as Oracle, SQL Server, MySQL, PostgreSQL, MongoDB, or Amazon S3, along with the server name, port, database name, and authentication credentials. DMS supports multiple authentication methods including username and password stored directly in the endpoint configuration, AWS Secrets Manager integration where DMS retrieves credentials automatically from a secret ARN, and IAM database authentication for supported engines like Aurora MySQL and Aurora PostgreSQL. For network connectivity, DMS endpoints can connect to databases in the same VPC, across VPCs using VPC peering, over VPN or Direct Connect to on-premises databases, or through publicly accessible endpoints. SSL/TLS encryption can be configured on endpoints to encrypt data in transit between the replication instance and the source or target database. You specify the SSL mode as none, require, verify-ca, or verify-full depending on your security requirements. DMS supports a wide range of source and target engine combinations, though the supported features vary by engine pair, so you should consult the compatibility matrix before planning your migration.
How does the Aurora storage architecture provide high availability and durability?
Aurora uses a distributed, fault-tolerant, self-healing storage system designed for 99.999999999% (eleven nines) durability. The storage layer automatically replicates data six ways across three Availability Zones, maintaining two copies in each AZ. Aurora can tolerate the loss of up to two copies without affecting write availability and up to three copies without affecting read availability. The storage volume is divided into 10GB segments called protection groups, and each protection group is replicated six ways. This segmented approach means that if a storage node fails, Aurora only needs to repair the affected 10GB segments rather than the entire volume, enabling repair in approximately 10 seconds using parallel recovery across the distributed storage fleet. Aurora storage is independent from the compute instances, meaning the storage layer continues operating even when all compute instances are stopped. The storage volume automatically grows in increments of 10GB up to 128 TiB without requiring manual provisioning. Continuous backups are performed automatically to Amazon S3, providing point-in-time recovery with granularity down to one second for a retention period up to 35 days. Aurora also supports backtracking for MySQL-compatible clusters, allowing you to rewind the database to a specific point in time without restoring from backup, which is significantly faster for recovering from user errors or bad deployments.
What are DMS replication instances and how do you size and configure them appropriately?
DMS replication instances are managed EC2 instances that run the replication software and perform the actual data migration between source and target endpoints. When creating a replication instance, you select an instance class that determines the CPU and memory capacity, such as dms.t3.medium for small migrations or dms.r5.4xlarge for large, high-throughput workloads. The replication instance must have sufficient storage to buffer data during migration, and you can allocate between 50 GB and 6 TB of storage. For sizing, consider the number and size of tables being migrated, the volume of ongoing changes if using CDC, the number of concurrent migration tasks, and LOB (Large Object) handling which is memory-intensive. Replication instances are launched within a VPC and can be configured as Multi-AZ for high availability, where a standby instance is maintained in a different Availability Zone and automatic failover occurs if the primary instance becomes unavailable. You assign a replication subnet group that specifies which subnets the instance can be placed in, and security groups control network access. Monitoring metrics include CPU utilization, freeable memory, swap usage, and network throughput, all available through CloudWatch. Scale up the instance class if CPU or memory becomes a bottleneck during migration.
How does encryption in transit work for AWS database services using SSL and TLS connections?
Encryption in transit protects data as it travels between your application and the database service using Transport Layer Security protocols. Amazon RDS supports SSL/TLS connections for all database engines, with each engine having specific configuration requirements. For MySQL and MariaDB, you download the RDS CA certificate bundle, configure your client with the --ssl-ca parameter pointing to the certificate, and optionally enforce SSL by creating database users with REQUIRE SSL. For PostgreSQL, you set sslmode to verify-full in the connection string and specify the sslrootcert parameter. For SQL Server and Oracle, you configure force SSL through the RDS parameter group by setting rds.force_ssl to 1. Amazon Aurora supports the same SSL mechanisms as its compatible engines and additionally provides encrypted connections between cluster nodes automatically. Amazon DynamoDB encrypts all traffic between your application and the service endpoint using HTTPS by default with TLS 1.2, requiring no additional configuration. Amazon Redshift supports SSL connections configured through the cluster parameter group, and you can set require_ssl to true to reject all non-SSL connections. ElastiCache for Redis supports TLS encryption in transit, which must be enabled at cluster creation and encrypts all communication between clients and the Redis cluster as well as replication traffic between nodes.
What is Amazon DynamoDB single-table design and what are its advantages over multi-table design?
Single-table design is a modeling technique where multiple entity types are stored in a single DynamoDB table, using carefully designed partition keys and sort keys to support all required access patterns. Instead of creating separate tables for customers, orders, and order items as you would in a relational database, you combine them using composite keys such as PK=CUSTOMER#123 with SK=PROFILE for customer data, SK=ORDER#456 for orders, and SK=ORDER#456#ITEM#789 for order items. The primary advantages are reduced operational overhead because you manage one table instead of many, lower cost since DynamoDB charges per table for features like backups and streams, the ability to retrieve related entities in a single query operation using key conditions, and transactional operations across entity types within the same table using TransactWriteItems. The sort key enables efficient range queries like fetching all orders for a customer. Global secondary indexes with overloaded keys support additional access patterns, such as querying orders by status across all customers. However, single-table design has trade-offs: the schema is harder to understand and maintain, adding new access patterns may require table restructuring, and it requires thorough upfront access pattern analysis. It works best when access patterns are well-known and stable. For applications with evolving or unpredictable access patterns, multi-table design may offer more flexibility despite the additional operational cost.
Bilgi Kartları
temel 120 kavramlarını kapsayan kart DBS-C01
veya Aylık abonelik / İçerik Paketi ile dahil
110 kilidi açıldıktan sonra daha fazla kart mevcut
Mevcut Diller
English
Japanese
Korean
Simplified Chinese
Sınav Konuları
1
17 Q
Workload-Specific Database Design
Select appropriate database services for specific use cases, design database solutions for performance, compliance, and scalability.
2
13 Q
Deployment and Migration
Plan and execute database migration strategies using DMS, SCT. Determine data migration approaches and validation.
3
12 Q
Management and Operations
Determine maintenance tasks and processes, design backup and recovery strategies, manage operational costs.
4
12 Q
Monitoring and Troubleshooting
Plan and execute monitoring strategies, troubleshoot and resolve database issues, and optimize performance.
5
11 Q
Database Security
Encrypt data at rest and in transit, evaluate auditing solutions, determine access control and authentication mechanisms.
DBS-C01 Cheat Sheet
Hızlı başvuru kılavuzu - 6 bölüm
AWS Certified Database - Specialty (DBS-C01)
The DBS-C01 exam validates your expertise in designing, deploying, managing, and troubleshooting database solutions on the AWS platform. This Specialty-level certification is designed for database professionals who have five or more years of experience with general database technologies and at least two years of hands-on experience with AWS database services. The exam tests your ability to select the right database engine for specific workloads, migrate databases to AWS, manage and operate database environments, monitor performance, and implement security best practices across relational, key-value, document, in-memory, graph, time-series, and ledger database services.
Exam Details
| Exam Code | DBS-C01 |
| Duration | 180 minutes |
| Number of Questions | 65 questions (50 scored + 15 unscored) |
| Passing Score | 750 / 1000 |
| Cost | $300 USD |
| Validity | 3 years |
| Question Types | Multiple choice (single & multiple select), scenario-based |
| Testing Options | Pearson VUE testing center or online proctored |
| Recommended Experience | 5+ years database experience, 2+ years hands-on with AWS database services |
| Certification Level | Specialty |
Domain Weights
| Domain | Weight |
|---|---|
| Domain 1: Workload-Specific Database Design | 26% |
| Domain 2: Deployment and Migration | 20% |
| Domain 3: Management and Operations | 18% |
| Domain 4: Monitoring and Troubleshooting | 18% |
| Domain 5: Database Security | 18% |
Study Tips
- Domain 1 carries the highest weight at 26%; dedicate the most study time to understanding all AWS database services, their use cases, and how to select the right engine for specific workload requirements
- Amazon Aurora and DynamoDB are the two most heavily tested services across all five domains; master their architectures, scaling mechanisms, replication models, and performance optimization strategies
- RDS is foundational to this exam; understand Multi-AZ deployments, read replicas, parameter groups, option groups, and the differences between RDS engine types including MySQL, PostgreSQL, Oracle, SQL Server, and MariaDB
- DMS and SCT are critical for Domain 2; know migration patterns for homogeneous and heterogeneous migrations, continuous replication, and how to validate migrated data
- Know the backup and recovery capabilities for every database service; understand automated backups, manual snapshots, point-in-time recovery, and cross-Region replication for disaster recovery
- Encryption is tested across multiple domains; understand encryption at rest using KMS, encryption in transit using SSL/TLS, and how to enable encryption for each database service including retroactive encryption strategies
- Performance optimization questions are common; master Performance Insights, Enhanced Monitoring, slow query logs, and know how to diagnose common database performance bottlenecks
- Practice with real AWS scenarios; the exam is heavily scenario-based and expects you to pick the most appropriate database solution while considering cost, performance, scalability, and operational overhead
Question Strategy Tips
- Read the last sentence of each question first to identify what is being asked, then read the full scenario with that context in mind
- Look for keywords like "low latency", "high throughput", "ACID compliance", "serverless", "graph queries", or "time-series data" which point toward specific database services
- When two answers seem correct, choose the one that provides the best balance of performance, cost-effectiveness, and operational simplicity while meeting all stated requirements
- AWS-managed and serverless options are almost always preferred over self-managed solutions on EC2 unless the question specifically mentions a requirement that only self-managed databases can fulfill
- Pay close attention to whether the question mentions a single Region or multi-Region requirement because the correct answer often differs significantly between Aurora Global Database, DynamoDB Global Tables, and cross-Region read replicas
- Questions about migration always require you to identify the source and target database engines first; homogeneous migrations use DMS alone while heterogeneous migrations require SCT plus DMS
- Flag complex questions and return later; do not spend more than 2.5 minutes per question on the first pass
- Use the full 180 minutes; database scenarios require careful reading to identify all constraints related to consistency, availability, latency, and throughput requirements
Key Differences from Other AWS Exams
- Database Specialty goes much deeper into database internals, query optimization, and engine-specific configurations than any Associate or Professional exam
- Unlike Solutions Architect which focuses on broad architecture design, Database Specialty expects you to know the specific features and limitations of each AWS database engine
- This exam tests database migration in far greater depth than other exams; you must understand DMS task types, SCT conversion rules, and migration validation strategies
- Performance tuning is tested at a deeper level including query plan analysis, index optimization, connection pooling, and caching strategies specific to each database engine
- Database Specialty expects you to understand traditional database concepts like normalization, ACID properties, CAP theorem, and how they apply to AWS database service selection
- Security questions focus specifically on database-level controls including IAM database authentication, row-level security, column-level encryption, and database audit logging
Recommended Preparation Path
- Step 1 - Foundation: Ensure you have a solid understanding of relational database concepts, NoSQL patterns, and AWS networking fundamentals before attempting the Database Specialty exam
- Step 2 - Deep Dive: Study each AWS database service in depth including Aurora, RDS, DynamoDB, ElastiCache, Neptune, DocumentDB, Keyspaces, Timestream, QLDB, and MemoryDB for Redis
- Step 3 - Hands-On Labs: Build database architectures with Multi-AZ deployments, read replicas, Global Database, DynamoDB Global Tables, and DAX; practice migrations with DMS and SCT
- Step 4 - Practice Exams: Take multiple full-length practice exams under timed conditions. Review every wrong answer thoroughly and understand why the correct answer is the most appropriate database solution
- Step 5 - Weak Areas: Identify your weakest domains from practice exams and dedicate additional study time to those areas before scheduling the real exam
Exam Day Checklist
- Arrive 15 minutes early for testing center or start your online proctored check-in 30 minutes before the scheduled time
- Bring two forms of valid identification (one with photo) for testing center; clear your workspace for online proctoring
- You have 180 minutes for 65 questions, which gives you approximately 2 minutes and 46 seconds per question
- Use the "Flag for Review" feature liberally on questions you are unsure about; you can return to them later
- Read every word in the scenario carefully as questions often contain critical constraints about throughput, latency, consistency, or compliance requirements buried in the middle of the text
- Your score is calculated on a scale of 100-1000; you need 750 to pass, which means you need to answer approximately 72-75% correctly
- Results are typically available within 1-5 business days through your AWS Certification account
- If you do not pass, you can retake the exam after 14 days; there is no limit on the number of attempts
- Request accommodations in advance if English is not your first language (extra 30 minutes available for non-native speakers)
Recommended AWS Whitepapers & Resources
- AWS Database Migration Guide: Comprehensive guide to planning and executing database migrations using DMS and SCT; covers homogeneous and heterogeneous migration strategies in depth; essential for Domain 2
- Amazon Aurora User Guide: Deep dive into Aurora architecture, cluster endpoints, Global Database, Serverless v2, Parallel Query, and performance optimization; critical for Domains 1, 3, and 4
- Amazon DynamoDB Developer Guide: Covers partition key design, secondary indexes, DynamoDB Streams, Global Tables, DAX, and capacity planning; essential for all five domains
- AWS Well-Architected Framework - Reliability Pillar: Database backup and recovery strategies, Multi-AZ and multi-Region architectures, and disaster recovery patterns relevant to Domains 2 and 3
- AWS Database Caching Strategies: ElastiCache and DAX caching patterns including lazy loading, write-through, and TTL strategies; important for performance optimization in Domain 1
- AWS Security Best Practices for Databases: Encryption at rest and in transit, IAM database authentication, VPC security, and audit logging patterns; directly relevant to Domain 5
Domain 1: Workload-Specific Database Design (26%)
This domain focuses on selecting and designing the appropriate AWS database solution for specific workload requirements. You must understand the characteristics, strengths, and limitations of every AWS database service and be able to recommend the right engine based on data model, access patterns, throughput requirements, latency expectations, consistency needs, and cost considerations. This is the highest-weighted domain at 26% and requires deep knowledge of all AWS database offerings.
AWS Database Service Selection Guide
Understanding when to use each AWS database service is the foundation of this domain. The following table maps workload characteristics to the most appropriate database engine.
| Workload Type | AWS Service | Key Characteristics |
|---|---|---|
| Relational (general) | Amazon RDS | ACID compliance, complex joins, structured schemas; MySQL, PostgreSQL, Oracle, SQL Server, MariaDB engines |
| Relational (high performance) | Amazon Aurora | 5x MySQL / 3x PostgreSQL throughput, up to 128 TB auto-scaling storage, 6-way replication across 3 AZs |
| Key-value / Document | Amazon DynamoDB | Single-digit millisecond latency, unlimited throughput, serverless, auto-scaling; supports key-value and document models |
| Document (MongoDB compatible) | Amazon DocumentDB | MongoDB API compatible, managed JSON document store, up to 15 read replicas, automatic storage scaling |
| In-memory caching | Amazon ElastiCache | Microsecond latency, Redis or Memcached engines; session stores, leaderboards, real-time analytics |
| In-memory (durable) | Amazon MemoryDB for Redis | Redis compatible with Multi-AZ durability, microsecond reads, single-digit millisecond writes; primary database for Redis workloads |
| Graph | Amazon Neptune | Property graph (Gremlin) and RDF (SPARQL) support; social networks, fraud detection, knowledge graphs, recommendation engines |
| Time-series | Amazon Timestream | Purpose-built for IoT and operational data, automatic tiered storage (memory to magnetic), built-in analytics functions |
| Ledger / Immutable | Amazon QLDB | Cryptographically verifiable transaction log, immutable and transparent, document data model with PartiQL support |
| Wide column (Cassandra) | Amazon Keyspaces | Apache Cassandra compatible, serverless, CQL support; equipment maintenance, fleet management, route optimization |
Amazon Aurora Deep Dive
Aurora is the most heavily tested relational database service on this exam. It is a cloud-native relational engine built for high performance, high availability, and seamless scalability.
| Feature | Description | Key Details |
|---|---|---|
| Storage Architecture | Distributed, fault-tolerant, self-healing storage | 6 copies across 3 AZs; survives loss of 2 copies for writes, 3 copies for reads; 10 GB segments with automatic repair |
| Aurora Replicas | Up to 15 read replicas in-cluster | Share the same storage volume; sub-10ms replica lag; automatic failover priority tiers (0-15) |
| Aurora Global Database | Cross-Region replication | Sub-second replication to up to 5 secondary Regions; managed RPO/RTO failover; ideal for DR and low-latency global reads |
| Aurora Serverless v2 | Auto-scaling compute capacity | Scales in increments of 0.5 ACU; min/max ACU range configurable; scales in place without downtime; supports read replicas |
| Aurora Parallel Query | Analytical query acceleration | Pushes query processing to the storage layer; up to 2x improvement for analytical queries without impacting OLTP performance |
| Cluster Endpoints | Built-in connection management | Writer endpoint (primary), reader endpoint (load-balanced across replicas), custom endpoints (user-defined instance groups) |
| Backtrack | Point-in-time rewind (MySQL only) | Rewind database to a specific point in time without restoring from backup; configurable backtrack window up to 72 hours |
Amazon DynamoDB Deep Dive
DynamoDB is the most heavily tested NoSQL service on this exam. It is a fully managed, serverless key-value and document database designed for single-digit millisecond performance at any scale.
| Feature | Description | Key Details |
|---|---|---|
| Primary Key Design | Partition key or composite key | Partition key (hash) for single-item access; composite key (partition + sort) for range queries; high-cardinality partition keys prevent hot partitions |
| Secondary Indexes | GSI and LSI for alternate access patterns | GSI: different partition and sort key, eventual consistency, own provisioned throughput; LSI: same partition key, different sort key, strong consistency, must be created at table creation |
| Capacity Modes | Provisioned or on-demand | Provisioned: set RCU/WCU with auto-scaling; On-demand: pay-per-request, instant scaling; switch between modes once every 24 hours |
| DynamoDB Streams | Ordered change data capture | Records item-level changes in near real-time; 24-hour retention; triggers Lambda functions; 4 view types (KEYS_ONLY, NEW_IMAGE, OLD_IMAGE, NEW_AND_OLD_IMAGES) |
| Global Tables | Multi-Region active-active replication | Fully managed, multi-master replication; eventual consistency across Regions; requires DynamoDB Streams enabled; sub-second replication |
| DAX (DynamoDB Accelerator) | In-memory caching for DynamoDB | Microsecond read latency; write-through cache; API compatible (drop-in replacement); deployed in VPC; up to 10 nodes per cluster |
| TTL (Time to Live) | Automatic item expiration | Items deleted within 48 hours of expiry at no cost; expired items excluded from reads and queries; deletions appear in DynamoDB Streams |
Caching Strategies
Caching is a critical component of database design for reducing latency, lowering database load, and improving cost efficiency. The exam tests your knowledge of when and how to implement caching.
| Strategy | How It Works | Best For |
|---|---|---|
| Lazy Loading (Cache-Aside) | Data loaded into cache only on cache miss; application checks cache first, reads from DB on miss, writes to cache | Read-heavy workloads where stale data is acceptable; minimizes cache size; handles cache failures gracefully |
| Write-Through | Data written to cache and database simultaneously on every write operation | Workloads requiring data consistency between cache and database; eliminates stale reads; higher write latency |
| TTL (Time to Live) | Cached items expire after a configurable time period; combines with lazy loading or write-through | Balancing data freshness with cache performance; prevents indefinite stale data; common with lazy loading |
- ElastiCache for Redis supports clustering with up to 500 nodes, encryption at rest and in transit, AUTH token authentication, Global Datastore for cross-Region replication, and pub/sub messaging
- ElastiCache for Memcached is simpler with multi-threaded architecture, supports Auto Discovery, and is ideal for simple caching workloads that do not require persistence or complex data structures
- DAX vs ElastiCache: Use DAX when the cache must be transparent to the DynamoDB API (drop-in replacement); use ElastiCache when you need to cache results from multiple data sources or need advanced data structures
Database Design Patterns
- Single-Table Design (DynamoDB): Store multiple entity types in a single table using composite keys and GSIs; reduces the number of API calls; use overloaded sort keys and GSIs to support multiple access patterns from one table
- CQRS (Command Query Responsibility Segregation): Separate read and write models; use DynamoDB Streams or Aurora read replicas to maintain separate optimized views for reading and writing
- Event Sourcing: Store state changes as a sequence of events rather than overwriting current state; use DynamoDB Streams, Kinesis, or QLDB for immutable event logs
- Read Replica Pattern: Direct read-heavy workloads to replicas; Aurora supports up to 15 in-cluster replicas and cross-Region replicas; RDS supports up to 5 read replicas per instance
- Sharding: Distribute data across multiple database instances for horizontal scaling; use application-level or proxy-based routing; DynamoDB handles this automatically via partitioning
- Exam Tip: When a question describes an access pattern, identify the data model first (relational, key-value, document, graph, time-series) and then select the AWS service that natively supports that model
Purpose-Built Databases Comparison
- Neptune vs DynamoDB: Use Neptune when you need to traverse relationships (social networks, recommendations, fraud graphs); use DynamoDB for high-throughput key-value access with predictable performance
- Timestream vs DynamoDB: Use Timestream for IoT telemetry and time-series analytics with automatic tiered storage; use DynamoDB when you need sub-millisecond access to individual time-series records
- QLDB vs DynamoDB: Use QLDB when you need cryptographically verifiable, immutable audit logs (financial transactions, supply chain); use DynamoDB for general-purpose workloads
- Keyspaces vs DynamoDB: Use Keyspaces when migrating existing Cassandra workloads or when CQL is required; use DynamoDB for new applications requiring key-value or document access patterns
- DocumentDB vs DynamoDB: Use DocumentDB when migrating MongoDB workloads or when you need complex document queries with aggregation pipelines; use DynamoDB for simpler document access patterns
- MemoryDB vs ElastiCache: Use MemoryDB when Redis is the primary database requiring durability; use ElastiCache when Redis is a caching layer in front of another database
Domain 2: Deployment and Migration (20%)
This domain covers planning and executing database deployments and migrations to AWS. You must understand AWS Database Migration Service (DMS), AWS Schema Conversion Tool (SCT), and various migration strategies for both homogeneous and heterogeneous database migrations. This domain also covers high-availability deployment patterns including Multi-AZ, read replicas, Aurora Global Database, and DynamoDB Global Tables.
AWS Database Migration Service (DMS)
DMS is the primary service for migrating databases to AWS. It supports one-time migrations and continuous data replication with minimal downtime. Understanding DMS task types, endpoint configurations, and replication instances is critical for this domain.
| Feature | Description | Key Details |
|---|---|---|
| Migration Types | Three task types for different scenarios | Full load (one-time bulk migration), CDC only (ongoing changes only), Full load + CDC (bulk migration followed by continuous replication) |
| Replication Instance | EC2 instance running DMS engine | Size based on data volume and number of tables; Multi-AZ for HA; runs in VPC; requires connectivity to source and target |
| Source Endpoints | Supported source databases | Oracle, SQL Server, MySQL, PostgreSQL, MongoDB, SAP ASE, DB2, S3, Azure SQL, and more; on-premises, EC2, or RDS |
| Target Endpoints | Supported target databases | RDS, Aurora, DynamoDB, S3, Redshift, Elasticsearch, Neptune, DocumentDB, Kinesis, Kafka |
| Table Mappings | Control which data is migrated | Selection rules (include/exclude schemas/tables), transformation rules (rename, add column, convert data type), JSON format |
| Validation | Data validation during migration | Row count comparison, column-by-column comparison; identifies mismatches between source and target; enable in task settings |
| LOB Handling | Large object migration options | Full LOB mode (no size limit, slower), Limited LOB mode (truncates to max size, faster), Inline LOB mode (combines both approaches) |
AWS Schema Conversion Tool (SCT)
SCT converts source database schemas, stored procedures, functions, views, and application code to a target database format. It is required for heterogeneous migrations where the source and target database engines differ.
- Assessment Reports: SCT generates detailed migration assessment reports that identify conversion complexity, action items requiring manual intervention, and estimated effort for each database object
- Conversion Scope: Converts schemas, stored procedures, functions, triggers, views, and sequences; supports Oracle to PostgreSQL, SQL Server to MySQL, Oracle to Aurora, and many other engine combinations
- Data Extraction Agents: SCT data extraction agents run on-premises to extract data from data warehouses (Teradata, Netezza, Greenplum) and load it into Amazon Redshift via S3
- DMS Integration: For heterogeneous migrations, use SCT first to convert the schema, then use DMS to migrate the data; SCT handles structure, DMS handles data
- Exam Tip: Homogeneous migrations (same engine type) do not require SCT; DMS alone handles the migration. SCT is only needed when the source and target engines are different
Migration Strategies
| Strategy | Description | When to Use |
|---|---|---|
| Homogeneous Migration | Same engine source to target (e.g., MySQL to Aurora MySQL) | DMS only; no schema conversion needed; native tools like mysqldump or pg_dump can also be used for small databases |
| Heterogeneous Migration | Different engine source to target (e.g., Oracle to Aurora PostgreSQL) | SCT for schema conversion + DMS for data migration; requires manual review of conversion issues; more complex and time-consuming |
| Snapshot Migration | Restore from native database backup or snapshot | RDS snapshot restore, Aurora snapshot restore, or native backup restore to RDS; fastest for large databases when brief downtime is acceptable |
| Blue/Green Deployment | Create staging environment, sync, then switch | RDS Blue/Green Deployments create a staging copy, replicate changes, then switchover with minimal downtime; ideal for version upgrades and schema changes |
| Native Export/Import | Use database engine native tools | mysqldump, pg_dump/pg_restore, Oracle Data Pump, SQL Server bak files; suitable for small to medium databases with acceptable downtime |
High Availability Deployment Patterns
| Pattern | Service | Details |
|---|---|---|
| RDS Multi-AZ | RDS (all engines) | Synchronous standby replica in different AZ; automatic failover (60-120 seconds); standby is not readable; DNS endpoint stays the same after failover |
| RDS Multi-AZ Cluster | RDS MySQL/PostgreSQL | 1 writer + 2 readable standby instances across 3 AZs; faster failover (under 35 seconds); reader endpoint for read scaling |
| Aurora Multi-AZ | Aurora MySQL/PostgreSQL | Up to 15 replicas across AZs; automatic failover to replica (30 seconds); shared storage layer; reader endpoint for load balancing |
| Aurora Global Database | Aurora MySQL/PostgreSQL | 1 primary Region + up to 5 secondary Regions; sub-second replication; managed failover with RPO/RTO targets; for DR and global reads |
| DynamoDB Global Tables | DynamoDB | Active-active multi-Region; sub-second replication; conflict resolution via last-writer-wins; requires Streams enabled |
| Cross-Region Read Replicas | RDS MySQL/PostgreSQL/MariaDB | Asynchronous replication to another Region; can be promoted to standalone; for read scaling and DR; uses async replication |
| ElastiCache Global Datastore | ElastiCache for Redis | Cross-Region replication for Redis clusters; sub-second replication; automatic failover to secondary Region |
RDS Blue/Green Deployments
- How It Works: Creates a staging (green) environment that is a copy of the production (blue) environment; uses logical replication to keep green in sync with blue; switchover changes the DB endpoint to point to green
- Use Cases: Major or minor engine version upgrades, parameter group changes, schema changes, and maintenance operations that traditionally required downtime
- Supported Engines: RDS MySQL, RDS MariaDB, RDS PostgreSQL, and Aurora MySQL; not available for Oracle, SQL Server, or Aurora PostgreSQL
- Switchover Process: Writes are blocked on both environments during switchover; green environment is promoted to the new production; blue environment is retained for rollback; typically completes in under 1 minute
- Exam Tip: Blue/Green Deployments are the preferred answer for any question about minimizing downtime during RDS engine upgrades or major configuration changes
Migration Best Practices
- Pre-Migration Assessment: Use SCT assessment reports to identify conversion complexity, test application compatibility with the target engine, and estimate migration timeline and effort
- Network Connectivity: Ensure the DMS replication instance has network access to both source and target; use VPN or Direct Connect for on-premises sources; place the replication instance in the same VPC as the target when possible
- Full Load Optimization: Disable foreign keys, triggers, and secondary indexes on the target during full load; re-enable after load completes; use parallel load with table-level or segment-level partitioning for large tables
- CDC Optimization: Ensure source database has binary logging (MySQL) or supplemental logging (Oracle) enabled; use batch apply for CDC on targets with high write throughput
- Validation: Enable DMS data validation to compare source and target rows; use premigration assessments to identify potential issues; test application functionality against the target database before cutover
- Exam Tip: Questions about minimal downtime migration almost always require Full Load + CDC; the application cuts over to the target after the CDC catches up with the source
Domain 3: Management and Operations (18%)
This domain covers the ongoing management and operational tasks for AWS database services including backup and recovery, scaling strategies, maintenance operations, parameter and option group configuration, and infrastructure as code for database provisioning. You must understand how to maintain database availability, perform upgrades with minimal downtime, and automate operational tasks using AWS services and tools.
Backup and Recovery
Understanding backup strategies, retention policies, and recovery procedures for each AWS database service is essential for this domain.
| Service | Backup Type | Key Details |
|---|---|---|
| RDS Automated Backups | Daily snapshots + transaction logs | Retention: 0-35 days (0 disables); PITR to any second within retention; stored in S3; taken during backup window; can cause brief I/O suspension (Single-AZ) |
| RDS Manual Snapshots | User-initiated full snapshots | Retained until explicitly deleted; can be copied cross-Region; can be shared with other AWS accounts; encrypted snapshots can be shared if KMS key is shared |
| Aurora Backups | Continuous incremental backups | Retention: 1-35 days; PITR to any second; no performance impact; backup stored across 3 AZs; backtrack available for MySQL (rewind without restore) |
| DynamoDB Backups | On-demand + PITR | On-demand: full table backup, no performance impact, retained until deleted; PITR: continuous backup, restore to any second within 35 days; both zero-impact on performance |
| DocumentDB Backups | Continuous incremental backups | Retention: 1-35 days; PITR to any second; stored across 3 AZs; manual snapshots also supported |
| Neptune Backups | Continuous incremental backups | Retention: 1-35 days; PITR to any second; manual snapshots retained until deleted; similar to Aurora backup architecture |
| ElastiCache Backups | Redis snapshots (RDB files) | Automatic daily snapshots with configurable retention (1-35 days); manual snapshots retained until deleted; Memcached does not support backups |
Scaling Strategies
| Strategy | Service | Details |
|---|---|---|
| Vertical Scaling (Scale Up) | RDS, Aurora, ElastiCache, DocumentDB | Change instance class for more CPU/memory; causes brief downtime during modification (use Multi-AZ for minimal impact); apply immediately or during maintenance window |
| Read Scaling (Replicas) | RDS (5), Aurora (15), DocumentDB (15) | Add read replicas for read-heavy workloads; Aurora replicas share storage (no replication lag); RDS replicas use async replication |
| Aurora Auto Scaling | Aurora | Automatically add/remove Aurora Replicas based on CloudWatch metrics (CPU, connections); configure min/max replicas and target metric values |
| Aurora Serverless v2 | Aurora | Auto-scales compute in 0.5 ACU increments; min/max ACU configurable; scales up in seconds without connection disruption; ideal for variable workloads |
| DynamoDB Auto Scaling | DynamoDB (Provisioned) | Application Auto Scaling adjusts RCU/WCU based on target utilization; set min/max capacity and target utilization percentage (default 70%) |
| DynamoDB On-Demand | DynamoDB | Instantly accommodates traffic; no capacity planning; pay-per-request pricing; ideal for unpredictable or spiky workloads; accommodates up to 2x previous peak |
| Storage Auto Scaling | RDS | Automatically increases storage when free space is low; set maximum storage threshold; no downtime; Aurora and DynamoDB scale storage automatically |
Parameter Groups and Option Groups
- Parameter Groups: Control database engine configuration; dynamic parameters apply immediately without reboot; static parameters require a reboot to take effect; each RDS/Aurora instance is associated with one parameter group
- Cluster Parameter Groups (Aurora): Apply to all instances in an Aurora cluster; control cluster-wide settings like character set, time zone, and binlog format; changes propagate to all instances
- Option Groups (RDS only): Enable additional database engine features like Oracle TDE, SQL Server Audit, MySQL memcached plugin, and Oracle APEX; not available for Aurora
- Default vs Custom: Default parameter/option groups cannot be modified; create custom groups to change settings; you can modify a custom group and associate it with an instance
- Exam Tip: Know common parameters like max_connections, innodb_buffer_pool_size (MySQL), shared_buffers (PostgreSQL), and understand when changes require a reboot versus applying immediately
Maintenance and Upgrades
| Operation | Impact | Best Practice |
|---|---|---|
| Minor Version Upgrade | Brief downtime during apply | Enable auto minor version upgrade; applied during maintenance window; test on non-production first; use Multi-AZ to minimize impact |
| Major Version Upgrade | Extended downtime possible | Use Blue/Green Deployments for minimal downtime; test application compatibility; review deprecated features; cannot be auto-applied |
| OS Maintenance | Brief downtime during patching | Applied during maintenance window; Multi-AZ instances patch standby first, then failover and patch primary; deferred if no pending patches |
| Instance Class Change | Brief downtime during modification | Apply immediately or defer to maintenance window; Multi-AZ modifies standby first, then failover; Aurora modifies one instance at a time |
| Storage Modification | No downtime (RDS gp2/gp3/io1/io2) | Can increase size, change type, or adjust IOPS online; 6-hour cooldown between storage modifications; Aurora storage scales automatically |
Infrastructure as Code for Databases
- CloudFormation: Define RDS instances, Aurora clusters, DynamoDB tables, and ElastiCache clusters as infrastructure code; use AWS::RDS::DBInstance, AWS::RDS::DBCluster, AWS::DynamoDB::Table resource types; supports drift detection
- AWS CDK: Define database infrastructure using TypeScript, Python, Java, or C#; higher-level constructs for common patterns; synthesizes to CloudFormation templates
- AWS Backup: Centralized backup management for RDS, Aurora, DynamoDB, EFS, and other services; define backup plans with schedules and retention policies; cross-Region and cross-account backup copy rules; supports compliance with AWS Backup Vault Lock
- Systems Manager: Use SSM Automation runbooks for database operational tasks; Parameter Store for storing database connection strings and credentials; Maintenance Windows for scheduling operations
- Exam Tip: Questions about automating database operations favor AWS Backup for centralized backup management and CloudFormation for repeatable database provisioning across environments
Connection Management
- RDS Proxy: Fully managed database proxy that pools and shares database connections; reduces connection overhead by up to 97%; supports IAM and Secrets Manager authentication; ideal for Lambda functions and serverless architectures
- Connection Pooling: Application-side pooling (PgBouncer, ProxySQL) or RDS Proxy; reduces the number of database connections; critical for serverless workloads where connection count can spike
- Aurora Endpoints: Cluster endpoint (writer), reader endpoint (load-balanced reads), custom endpoints (user-defined instance groups), instance endpoints (direct access to specific instances)
- Exam Tip: RDS Proxy is the go-to answer for Lambda-to-database connection problems; it handles connection pooling, failover, and credential rotation transparently
Domain 4: Monitoring and Troubleshooting (18%)
This domain covers monitoring database performance, identifying bottlenecks, and troubleshooting common database issues on AWS. You must understand CloudWatch metrics, Performance Insights, Enhanced Monitoring, database-engine-specific logging, and know how to diagnose and resolve performance problems across all AWS database services.
Amazon CloudWatch for Databases
CloudWatch is the foundation of database monitoring on AWS. Every managed database service publishes metrics to CloudWatch, and you can create alarms to trigger automated actions when thresholds are breached.
| Metric | What It Measures | Troubleshooting Guidance |
|---|---|---|
| CPUUtilization | Percentage of CPU used by the database instance | High CPU: check for inefficient queries, missing indexes, or insufficient instance size; consider read replicas to offload reads |
| FreeableMemory | Available RAM on the database instance | Low memory: increase instance size, optimize buffer pool settings, reduce connection count, or add caching layer |
| ReadIOPS / WriteIOPS | Number of disk I/O operations per second | High IOPS: optimize queries, add indexes, use Provisioned IOPS storage (io1/io2), or increase buffer pool to reduce disk reads |
| ReadLatency / WriteLatency | Average time per disk I/O operation | High latency: switch to Provisioned IOPS storage, optimize write-heavy queries, check for lock contention |
| DatabaseConnections | Number of active database connections | Near max_connections: implement connection pooling (RDS Proxy), increase max_connections parameter, or scale up instance |
| FreeStorageSpace | Available storage space on the instance | Low storage: enable storage auto-scaling, increase allocated storage, archive old data, or purge unnecessary logs |
| ReplicaLag | Replication delay between primary and replica | High lag: check network throughput, increase replica instance size, reduce write load on primary, check for long-running transactions |
| DynamoDB ConsumedReadCapacityUnits | RCU consumed by DynamoDB operations | Throttling: increase provisioned capacity, switch to on-demand, optimize queries to read fewer items, use DAX for caching |
Performance Insights
Performance Insights is a database performance monitoring feature available for RDS and Aurora. It provides a visual dashboard to identify database performance bottlenecks and correlate them with specific SQL queries, wait events, users, and hosts.
| Feature | Description | Key Details |
|---|---|---|
| Database Load (DBLoad) | Average number of active sessions | DBLoad above max vCPU count indicates CPU bottleneck; broken down by wait events, SQL statements, users, and hosts |
| Wait Events | What database sessions are waiting on | CPU waits, I/O waits, lock waits, network waits; helps identify whether the bottleneck is compute, storage, or contention |
| Top SQL | SQL statements consuming the most resources | Identifies the specific queries causing load; shows execution count, average latency, and rows examined per query |
| Retention | Historical performance data | Free tier: 7 days; paid: up to 24 months; longer retention enables trend analysis and capacity planning |
| Counter Metrics | Engine-level performance counters | OS-level and engine-level metrics like buffer cache hit ratio, temp tables created, sort operations, and table lock waits |
Enhanced Monitoring
Enhanced Monitoring provides real-time operating system metrics for RDS and Aurora instances at granularities from 1 second to 60 seconds. It runs an agent on the instance to collect OS-level metrics that CloudWatch standard metrics do not capture.
- OS-Level Metrics: CPU breakdown (user, system, wait, idle, steal), memory (active, inactive, free, buffers), file system utilization, disk I/O (read/write throughput and latency), network (rx/tx bytes and packets), and process list
- Granularity: 1, 5, 10, 15, 30, or 60 second intervals; finer granularity provides more detail but generates more data and higher cost
- CloudWatch vs Enhanced Monitoring: CloudWatch collects metrics from the hypervisor; Enhanced Monitoring collects from the OS agent on the instance; Enhanced Monitoring provides more granular and accurate CPU and memory metrics
- Process List: Shows all running OS processes including the database engine processes; helps identify if non-database processes are consuming resources
- Exam Tip: Use Enhanced Monitoring when you need OS-level metrics like CPU steal time (indicates noisy neighbor on shared hardware), memory swap usage, or per-process resource consumption
Database Engine Logs
| Engine | Log Types | Key Configuration |
|---|---|---|
| MySQL / Aurora MySQL | Error log, slow query log, general log, audit log | slow_query_log=1, long_query_time (seconds), log_output=FILE; publish to CloudWatch Logs for centralized analysis |
| PostgreSQL / Aurora PostgreSQL | PostgreSQL log, pgAudit log | log_min_duration_statement (ms) for slow queries, log_statement (none/ddl/mod/all), pgAudit for detailed audit logging |
| Oracle | Alert log, audit trail, listener log, trace files | Oracle unified auditing for comprehensive audit trails; AWR and ASH reports for performance analysis |
| SQL Server | Error log, agent log, SQL Server Audit | SQL Server Audit enabled via option group; publishes to S3; use SQL Server Agent for automated maintenance tasks |
| DynamoDB | CloudTrail API logs, Contributor Insights | CloudTrail logs all DynamoDB API calls; Contributor Insights shows most accessed and throttled items and partition keys |
DynamoDB Troubleshooting
- Throttling (ProvisionedThroughputExceededException): Caused by exceeding provisioned RCU/WCU; solutions include enabling auto-scaling, switching to on-demand mode, using exponential backoff in application code, or redesigning the partition key for better distribution
- Hot Partitions: One partition receives disproportionate traffic; caused by low-cardinality partition keys; solutions include adding a random suffix to partition keys (write sharding), using a composite key, or redesigning the data model
- Contributor Insights: Identifies most frequently accessed and throttled partition keys and items; enable per table or GSI; helps pinpoint hot key issues without manual analysis
- Scan vs Query Performance: Scans read every item in the table (expensive); queries read only items matching the partition key; use queries whenever possible; use parallel scans for batch processing; use FilterExpressions to reduce returned data (but RCU is still consumed)
- GSI Throttling: GSI has its own provisioned throughput; if GSI is throttled, it back-pressures the base table; ensure GSI capacity matches expected query patterns; GSI writes consume base table WCU
- Exam Tip: When a question describes DynamoDB performance issues, first check for hot partition keys (use Contributor Insights), then check provisioned capacity, and finally evaluate if the access pattern requires a GSI or table redesign
Common RDS/Aurora Troubleshooting Patterns
| Problem | Symptoms | Resolution |
|---|---|---|
| Connection Exhaustion | Too many connections error, application timeouts | Implement RDS Proxy for connection pooling; increase max_connections; identify and close idle connections; scale up instance class |
| Slow Queries | High query latency, increased DBLoad in Performance Insights | Enable slow query log; analyze with EXPLAIN; add missing indexes; optimize query structure; increase instance size if CPU-bound |
| Lock Contention | Wait events showing lock waits in Performance Insights | Identify blocking queries; reduce transaction scope; use optimistic locking; consider read committed isolation level |
| Storage Full | Database becomes read-only, writes fail | Enable storage auto-scaling; manually increase storage; delete unnecessary data or logs; purge binary logs (MySQL) |
| High Replica Lag | ReplicaLag metric increasing, stale reads | Increase replica instance size; reduce write load on primary; avoid long-running transactions; use Aurora (shared storage, sub-10ms lag) |
| Failover Delays | Longer than expected failover time | Use Aurora for faster failover (30s); ensure DNS caching is low; use RDS Proxy for transparent failover; test failover regularly |
Monitoring Best Practices
- Layered Monitoring: Use CloudWatch for baseline metrics, Enhanced Monitoring for OS-level detail, Performance Insights for query-level analysis, and database engine logs for detailed debugging
- Proactive Alerting: Create CloudWatch Alarms on CPUUtilization, FreeableMemory, FreeStorageSpace, DatabaseConnections, and ReplicaLag; use SNS for notifications and Lambda for automated remediation
- CloudWatch Logs Integration: Publish database engine logs to CloudWatch Logs for centralized analysis; use CloudWatch Logs Insights for ad-hoc queries across log groups; set up metric filters for error patterns
- EventBridge Integration: RDS and Aurora emit events for failovers, backups, maintenance, and configuration changes; create EventBridge rules to trigger Lambda functions or SNS notifications for operational awareness
- Exam Tip: When a question asks about identifying the root cause of database performance issues, the answer typically involves Performance Insights for SQL-level analysis and Enhanced Monitoring for OS-level bottlenecks
Domain 5: Database Security (18%)
This domain covers securing AWS database environments including encryption at rest and in transit, authentication and authorization, network security, audit logging, and compliance. You must understand how to implement defense-in-depth security controls across all database services using KMS, IAM, Secrets Manager, VPC configurations, and database-engine-specific security features.
Encryption at Rest
Encryption at rest protects stored data from unauthorized physical access. AWS uses KMS to manage encryption keys for all managed database services.
| Service | Encryption Details | Key Considerations |
|---|---|---|
| RDS | AES-256 encryption using KMS keys | Must be enabled at creation; cannot encrypt an existing unencrypted instance directly; workaround: create encrypted snapshot copy, then restore from it |
| Aurora | AES-256 encryption using KMS keys | Encrypts the entire cluster including storage, backups, snapshots, and replicas; must be enabled at cluster creation; all replicas share the same encryption key |
| DynamoDB | AES-256 encryption, always enabled | Three key options: AWS owned key (default, free), AWS managed key (aws/dynamodb), customer managed key (CMK); can change key type at any time without downtime |
| ElastiCache | AES-256 encryption using KMS keys (Redis only) | Must be enabled at creation for Redis clusters; Memcached does not support encryption at rest; encrypts backups and snapshots |
| DocumentDB | AES-256 encryption using KMS keys | Enabled by default; encrypts storage, backups, snapshots, and replicas; cannot be disabled after creation |
| Neptune | AES-256 encryption using KMS keys | Must be enabled at creation; encrypts storage, snapshots, automated backups, and read replicas in the same cluster |
Encryption in Transit
- RDS/Aurora SSL/TLS: Use SSL/TLS certificates to encrypt connections; download the RDS CA certificate bundle; set rds.force_ssl=1 (PostgreSQL) or require_secure_transport=ON (MySQL) in parameter group to enforce encrypted connections
- DynamoDB: All connections to DynamoDB use HTTPS (TLS) by default; VPC endpoints provide private network paths; no additional configuration required
- ElastiCache: Redis supports in-transit encryption (must be enabled at creation); uses TLS for client-to-node and node-to-node communication; Memcached does not support in-transit encryption
- DocumentDB: TLS is enabled by default; connections use the Amazon DocumentDB CA certificate; can be disabled via cluster parameter (tls=disabled) but not recommended
- Exam Tip: Know how to enforce encryption in transit for each database engine; for RDS, this is done via parameter groups; for DynamoDB, it is automatic; for ElastiCache, it must be enabled at creation time
Authentication and Authorization
| Method | Services | Details |
|---|---|---|
| IAM Database Authentication | RDS MySQL/PostgreSQL, Aurora MySQL/PostgreSQL | Generate authentication tokens using IAM credentials; tokens valid for 15 minutes; no password stored in database; managed via IAM policies; limited to 200 connections/second |
| Kerberos Authentication | RDS Oracle/SQL Server/PostgreSQL/MySQL | Integrates with AWS Managed Microsoft AD; enables single sign-on; users authenticate via Active Directory credentials |
| Native Database Auth | All RDS/Aurora engines | Traditional username/password authentication managed within the database engine; use Secrets Manager for credential rotation |
| IAM Policies (DynamoDB) | DynamoDB | Fine-grained access control via IAM policies; restrict access to specific tables, items, and attributes using conditions on leading keys and attributes |
| Redis AUTH | ElastiCache for Redis | AUTH token (password) required for connection; RBAC (Role-Based Access Control) with user groups for fine-grained access; ACL commands for Redis 6+ |
AWS Secrets Manager
- Credential Storage: Stores database credentials, API keys, and other secrets as encrypted key-value pairs; integrates with KMS for encryption; supports versioning and staging labels
- Automatic Rotation: Built-in rotation for RDS, Aurora, DocumentDB, and Redshift credentials; uses Lambda functions to update the credential in both Secrets Manager and the database; configurable rotation schedule (days)
- RDS Integration: RDS can manage the master user password in Secrets Manager; credentials are rotated automatically; applications retrieve current credentials at connection time
- Multi-User Rotation: Alternating users strategy creates two users and alternates between them during rotation; prevents disruption to active connections during credential rotation
- Exam Tip: Secrets Manager is always preferred over hardcoded credentials or parameter store for database passwords because it provides automatic rotation; use Parameter Store SecureString only for non-rotating secrets
Network Security
| Control | Description | Best Practice |
|---|---|---|
| VPC Placement | Deploy databases in private subnets | Place RDS, Aurora, ElastiCache, DocumentDB, and Neptune in private subnets with no internet gateway; use DB subnet groups spanning at least 2 AZs |
| Security Groups | Stateful firewall rules for database instances | Allow inbound only from application security groups on the database port; deny all other inbound traffic; review and audit security group rules regularly |
| NACLs | Stateless subnet-level firewall | Additional layer of defense; restrict inbound and outbound traffic at the subnet level; must allow ephemeral ports for return traffic |
| VPC Endpoints | Private connectivity to AWS services | Gateway endpoint for DynamoDB (free, route table entry); interface endpoints for other services; keeps traffic within AWS network |
| Public Accessibility | Whether the database has a public IP | Set Publicly Accessible to No for production databases; even if set to Yes, security groups still control access; always use private subnets |
Audit Logging
- CloudTrail: Logs all API calls to RDS, DynamoDB, ElastiCache, and other services; captures who made the call, when, and from where; essential for security auditing and compliance; enable across all Regions and accounts
- Aurora Database Activity Streams: Near-real-time stream of database activity to Kinesis Data Firehose; captured by the database engine, not the application; supports synchronous (strict) and asynchronous modes; provides separation of duties between DBAs and security teams
- MySQL Audit Plugin: MariaDB Audit Plugin available for RDS MySQL and Aurora MySQL; logs connections, queries, and table access; configured via option groups (RDS) or parameter groups (Aurora)
- PostgreSQL pgAudit: Extension for detailed audit logging in RDS PostgreSQL and Aurora PostgreSQL; logs SELECT, INSERT, UPDATE, DELETE at the object level; configured via shared_preload_libraries parameter
- Oracle Audit: Unified auditing for comprehensive Oracle activity logging; includes standard audit trail, fine-grained auditing, and Oracle Data Redaction for masking sensitive data in query results
- Exam Tip: Aurora Database Activity Streams is the preferred answer for questions about real-time database audit logging with separation of duties; CloudTrail logs API-level activity, not SQL-level activity
DynamoDB Fine-Grained Access Control
- Leading Key Condition: Use dynamodb:LeadingKeys condition key in IAM policies to restrict users to accessing only items where the partition key matches their user ID; enables multi-tenant security
- Attribute-Level Control: Use dynamodb:Attributes condition key to restrict which attributes a user can read or write; hide sensitive columns from unauthorized users
- Web Identity Federation: Use Cognito or OIDC providers to issue temporary credentials with fine-grained DynamoDB access; each user gets access only to their own data based on their identity token
- VPC Endpoint Policies: Attach policies to DynamoDB VPC gateway endpoints to restrict which tables can be accessed from within the VPC; provides network-level access control in addition to IAM
- Exam Tip: Fine-grained access control questions always involve IAM policy conditions on dynamodb:LeadingKeys combined with Cognito or web identity federation for user-specific data access
Database Security Best Practices
- Defense in Depth: Layer security controls including VPC placement, security groups, encryption at rest and in transit, IAM authentication, Secrets Manager for credentials, and audit logging at every level
- Least Privilege: Grant only the minimum database permissions required; use IAM policies for DynamoDB, database roles and grants for RDS/Aurora, and RBAC for ElastiCache Redis
- Credential Management: Never hardcode database credentials; use Secrets Manager with automatic rotation for RDS/Aurora passwords; use IAM database authentication for passwordless access where possible
- Encryption Strategy: Enable encryption at rest for all database services; enforce TLS for all connections; use customer managed KMS keys when you need key policy control, rotation management, or cross-account access
- Compliance: Use CloudTrail for API-level auditing, Database Activity Streams for SQL-level auditing, and AWS Config rules to verify database security configuration compliance continuously
- Exam Tip: Security questions favor defense-in-depth approaches that combine network security (VPC, security groups), authentication (IAM, Secrets Manager), encryption (KMS, TLS), and monitoring (CloudTrail, Activity Streams)