Amazon SOA-C02: Databases and Caching — Study Guide

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Part of the AWS SysOps Administrator Associate SOA-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.

Databases and caching are core operational responsibilities for a SysOps administrator: they provide persistent storage, availability, and low-latency reads for applications. This domain covers running managed relational databases (RDS and Aurora), scaling read/write capacity, replication and failover behavior, and using ElastiCache to reduce DB load. Proper configuration of backups, parameter groups, monitoring, and cache-invalidation patterns prevents data loss and reduces operational incidents.

RDS and Aurora operations, backups, and Multi-AZ

RDS (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server) and Amazon Aurora (MySQL- and PostgreSQL-compatible) are managed relational engines with different operational semantics. Multi-AZ for RDS creates a synchronous standby in another AZ — managed by AWS, automated failover within minutes, no manual promotion, and the standby is not accessible for reads. Aurora separates writer and reader endpoints: writer is a cluster endpoint backed by a primary, and Aurora uses distributed storage that automatically replicates across AZs and can typically fail over faster than RDS because storage is shared.

Configure backups and retention using:

Automated backups: enable with a retention period (e.g., modify-db-instance –backup-retention-period 7). These provide point-in-time recovery (PITR) to any second within the retention window for supported engines.
Manual snapshots: create-db-snapshot (or create-db-cluster-snapshot for Aurora) to capture a retained snapshot; snapshots persist until you delete them.
PITR restore: aws rds restore-db-instance-to-point-in-time for RDS, or restore-db-cluster-from-snapshot and then create instances for Aurora.

Decision criteria:

Use Multi-AZ for high availability and automated failover when write availability is critical and reads on standby are not required.
Use Aurora (clustered storage) when you need high IOPS, fast failover, and storage auto-scaling.
Use read replicas for read scaling and cross-region disaster recovery (they are asynchronous and can be promoted).

Operational CLI examples:

Enable Multi-AZ: aws rds modify-db-instance –db-instance-identifier mydb –multi-az –apply-immediately
Create automated snapshot: aws rds create-db-snapshot –db-snapshot-identifier snap1 –db-instance-identifier mydb
Restore PITR: aws rds restore-db-instance-to-point-in-time –source-db-instance-identifier mydb –target-db-instance-identifier mydb-restore –restore-time “YYYY-MM-DDTHH:MM:SSZ”

Read replicas, failover, and replication strategies

Read replicas are asynchronous copies (RDS or Aurora readers) used primarily to scale read traffic and offload reporting. They incur replication lag (monitor ReplicaLag metric) and are not suited for strong consistency. Read replicas can be promoted to standalone DB instances to support disaster recovery.

Replication strategies and choices:

Synchronous (RDS Multi-AZ standby) — zero data drift guarantee, no read capacity on standby.
Asynchronous read replicas — scale reads, enable cross-region copies, risk of replica lag and potential data loss on failover.
Aurora readers — provide clustered read endpoints, low-latency failover via endpoint re-routing, and automatic reader endpoint balancing.

Operational patterns:

Create read replica: aws rds create-db-instance-read-replica –db-instance-identifier read1 –source-db-instance-identifier primary
Promote replica: aws rds promote-read-replica –db-instance-identifier read1
Monitor: CloudWatch DatabaseConnections, ReplicaLag, ReadIOPS, WriteIOPS, and Performance Insights to decide when to add or remove replicas.

Decision criteria:

If you need HA for writes, choose Multi-AZ. If you need read throughput and analytics offload, choose read replicas or Aurora readers.
For cross-region DR, create read replicas in target region and consider automated snapshot copy or DMS for migration.

Caching with ElastiCache and cache invalidation

ElastiCache offers Redis and Memcached to reduce DB load and latency. Choose Redis when you need persistence, replication, data structures, and high availability with Multi-AZ and automatic failover. Choose Memcached for simple horizontal caching where sharding and multithreaded performance are priorities.

Key configuration and patterns:

Create Redis cluster with replicas and Multi-AZ: aws elasticache create-replication-group –replication-group-id rg1 –replication-group-description “rg” –engine redis –num-cache-clusters 3 –automatic-failover-enabled
Use cluster mode enabled for Redis to scale shards; Memcached requires client-side hashing for sharding.
Eviction policies: volatile-lru, allkeys-lru, noeviction — tune based on whether you prefer evicting expired keys only or any keys when memory is full.
Monitor CacheHits and CacheMisses to calculate cache hit ratio: hit_ratio = CacheHits / (CacheHits + CacheMisses). Aim for high hit ratio to reduce DB reads.

Cache invalidation strategies:

Cache-aside: application checks cache first, on miss reads DB and populates cache; explicitly expire or delete cache on writes.
Write-through/write-behind: cache writes propagate to DB; write-behind batches DB writes (adds complexity).
Time-to-live (TTL): set conservative TTLs for data that can be stale; combine with cache versioning or invalidation keys for schema changes or bulk invalidation.
Use Redis pub/sub or Lambda events to notify application instances for distributed invalidation when needed.

Database parameter groups, scaling, and monitoring

Parameter groups control engine-specific settings (e.g., max_connections, innodb_buffer_pool_size). RDS uses DB parameter groups for instances and DB cluster parameter groups for Aurora. Changes to some parameters require reboot (apply pending-reboot), others apply immediately.

Management patterns:

Create and modify parameter group: aws rds create-db-parameter-group –db-parameter-group-name pg1 –db-parameter-group-family mysql8.0 –description “custom”; then aws rds modify-db-parameter-group –db-parameter-group-name pg1 –parameters “ParameterName=max_connections,ParameterValue=500,ApplyMethod=immediate”
Scale instance class: aws rds modify-db-instance –db-instance-identifier mydb –db-instance-class db.r5.large –apply-immediately (or during maintenance window to avoid restart).
Storage autoscaling: enable for supported engine types; Aurora auto-scales storage automatically.

Monitoring and scaling signals:

Use CloudWatch (FreeableMemory, CPUUtilization, DatabaseConnections, WriteLatency, ReadLatency, DiskQueueDepth) and Performance Insights for slow SQL and top waits.
Enable Enhanced Monitoring and set granularity (e.g., 1s for troubleshooting).
Use RDS Proxy to manage connection pooling and reduce connection storms for serverless or highly concurrent applications.

Backup/restore procedures and migration considerations

Backups and restores must be explicit and tested. Automated backups provide PITR within retention; manual snapshots are retained until deleted and can be copied across regions and to different KMS keys. Be explicit about region and timestamp when restoring.

Common restore commands:

Restore to point in time (RDS): aws rds restore-db-instance-to-point-in-time –source-db-instance-identifier mydb –target-db-instance-identifier mydb-restore –use-latest-restorable-time / or specify –restore-time
Restore snapshot (cross-region): copy-db-snapshot to destination region first, then restore.

Migration considerations:

AWS DMS for minimal downtime migrations (heterogeneous/homogeneous). DMS supports ongoing replication; ensure correct source engine settings (binlog enabled for MySQL).
Logical migration (mysqldump, pg_dump) for simple exports; physical snapshot restore for large datasets.
Validate character sets, parameter group differences, and KMS keys for encrypted snapshots.

Common Pitfalls and Decision Criteria

Restoring backups to wrong region or wrong time: always verify –region and –restore-time before restore; use copied snapshot to target region and test restores in staging.
Assuming read replicas provide high availability: remember replicas are asynchronous; use Multi-AZ or Aurora for write HA and synchronous replication.
Overlooking cache invalidation: design TTLs, versioned keys, or event-driven invalidation; avoid relying solely on short TTLs for correctness.
Not enabling automated backups or retention properly: set backup-retention-period >0 and validate PITR with test restores; ensure KMS keys are available in target region for snapshot copy.
Modifying parameter groups without rebooting: check ApplyMethod; schedule reboots in maintenance windows for parameters that require reboot to avoid unexpected downtime.
Scaling without connection management: increasing instance class without using RDS Proxy or connection pooling may not solve connection storms; implement pooling to manage many short-lived connections.

Practical Problem: Use-Case Scenario

Acme Retail runs a MySQL RDS primary with heavy read traffic and occasional analytics spikes; they face replica lag during nightly ETL and see high connection churn causing CPU spikes.

Enable an additional read replica group for analytics isolated from application readers, and place it in a different AZ or region for DR.
Configure replica monitoring (ReplicaLag metric) and add autoscaling logic to add readers when lag or ReadLatency exceeds thresholds.
Deploy RDS Proxy in front of the application to multiplex connections and reduce connection churn; tune max_connections in parameter group appropriately.
Move analytics jobs to use the analytics replica and adopt cache-aside caching via ElastiCache Redis with appropriate TTLs to reduce repeated queries.
Test failover and restore procedures: perform a PITR restore on a staging instance and validate replica promotion steps.

This approach separates read workloads, reduces connection pressure at the primary, and uses caching to lower DB read volume. It follows AWS best practices by combining read scaling, connection pooling, and tested backup/restore processes to maintain availability and operational resilience.

← Compute and Auto Scaling · All domains · Serverless and Application Integration →

Practice these questions → · Timed practice on ExamRoll.io →