SOA-C03 Cheat Sheet — Free Essentials

Key facts distilled from CertKata's SOA-C03 question bank. Free to read — no account needed.

Metrics, Logs, and Traces: three different signals

CloudWatch Metrics are numeric time-series data (CPU utilization, request count) — cheap to store and query, but they tell you WHAT happened, not why. CloudWatch Logs capture the actual event text, queryable with Logs Insights, and are what you go to for the WHY. X-Ray traces a single request's path across multiple services, showing WHERE time was spent — the tool for diagnosing latency in a distributed system that metrics and logs alone can't localize. A CloudOps engineer typically starts with a metric alarm, then drops into logs or traces to find the root cause.

CloudWatch alarms: states, periods, and datapoints to alarm

An alarm is in one of three states: OK, ALARM, or INSUFFICIENT_DATA (not enough data yet to evaluate). "Datapoints to alarm" (M out of N) lets you require, say, 3 breaching datapoints out of the last 5 evaluation periods before firing — smoothing out a single noisy spike that a naive "1 out of 1" threshold would trigger on immediately. A shorter period gives faster detection at the cost of more noise; a longer period is calmer but slower to react. Getting an alarm's period and evaluation count wrong is a common source of either alert fatigue or missed incidents.

CloudFormation change sets and drift detection

A change set previews exactly what a stack update would add, modify, or replace before anything actually happens — the update equivalent of terraform plan, and the way to catch an unintended resource replacement (which can mean downtime or data loss) before it executes. Drift detection separately checks whether a resource has been changed outside CloudFormation, such as a manual console edit, and reports which properties no longer match the template — but it only detects drift, it doesn't fix it; reconciling still requires either updating the template or manually reverting the out-of-band change.

The shared responsibility model, from an operations seat

AWS is responsible for security OF the cloud — physical facilities, hardware, and the underlying virtualization and network layer are patched and secured entirely on AWS's side, invisible to you. You're responsible for security IN the cloud, and for a CloudOps engineer that mostly means the guest OS (patching EC2 yourself, since AWS doesn't reach inside your instance), IAM configuration, security group and NACL rules, and encryption choices. Moving to a managed service like RDS narrows what you own — AWS also patches the database engine there — but never eliminates your side of the line entirely.

RTO vs. RPO and the four DR strategies

Recovery Time Objective is how long you can be down before service is restored; Recovery Point Objective is how much data loss, measured in time, you can tolerate. Backup and restore is the cheapest and slowest strategy — nothing runs until a disaster triggers a rebuild. Pilot light keeps a minimal core synced and idle. Warm standby runs a scaled-down but fully functional copy continuously. Multi-site active-active runs full capacity in more than one Region at once, the fastest to recover and the most expensive to run day to day.

NAT Gateway vs. NAT instance

A NAT Gateway is a managed AWS service — highly available within its AZ, scales automatically to your bandwidth, and requires no patching, but bills hourly plus per-GB data processed and only supports up to 5 Gbps by default without a workaround. A NAT instance is a regular EC2 instance running NAT software — cheaper at low, steady traffic, more flexible (can also act as a bastion or run other software), but it's a single point of failure you have to patch, size, and monitor yourself. For production workloads at real scale, NAT Gateway is the default recommendation; a NAT instance mostly still shows up for cost-constrained dev/test environments.