DBS-C01

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

Domain Weights

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.

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.

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.

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.

• 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.

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

High Availability Deployment Patterns

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.

Scaling Strategies

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

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.

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.

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

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

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.

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

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

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)