AWS Certified CloudOps Engineer Associate Training Course

SOA-C03 is written for someone who has already been on the wrong end of a production incident. Almost every scenario question in this domain follows the same three-beat structure: something is observed, a judgment is made about what it means, and an action is taken. If you can name which AWS service owns each beat, a large fraction of the domain answers itself.

Three stores, not one service

People say "CloudWatch" as though it were a single database. It is not. Amazon CloudWatch is a family of stores that hold different shapes of data, and they are queried in different ways. Getting this distinction straight is the single highest-value thing you can do early in your study.

• Metrics are time-ordered numeric data points. Each is a name plus a set of dimensions plus a timestamp plus a value. They are cheap to store, cheap to aggregate, and cheap to alarm on, but they carry no detail about any individual event. A metric can tell you that error rate rose; it cannot tell you which request failed.
• Logs are timestamped text records, grouped into log streams inside log groups. They carry the detail metrics lack, but scanning them costs money and time, and you cannot alarm on raw log text directly.
• Events are structured JSON notifications about state change, delivered through Amazon EventBridge. They are neither stored nor queried in the way metrics and logs are — they are routed. An event exists to trigger something.

Note the asymmetry. Metrics support alarms; logs support search; events support automation. When a question describes a requirement, decide which of those three verbs it needs before you decide which service to name. "Notify when CPU stays above a threshold for fifteen minutes" is an alarm on a metric. "Find every request that returned a particular status in the last hour" is a log query. "Do something the moment an instance enters the stopping state" is an event rule.

The bridge between stores

The three stores are not sealed off from each other, and the bridges are examinable.

A metric filter reads a log group as records arrive, matches a pattern, and increments a custom CloudWatch metric. That is how you get from unalarms-able log text to an alarmable number without paying to scan history. It is forward-only: a metric filter created today does not retroactively process yesterday's logs.

A subscription filter streams matching log events out of a log group in near real time to a destination — a Lambda function, a Kinesis Data Stream, or Amazon Data Firehose. That is the route for anything that must react to log content within seconds, or that must reach a store outside CloudWatch.

An alarm state change is itself an EventBridge event. So is a Systems Manager automation completing, an EC2 instance changing state, an AWS Config rule going non-compliant, and a scheduled cron expression firing. This is the join that makes autonomous remediation possible: metric crosses a threshold, alarm changes state, event fires, rule matches, target runs.

Detect, decide, act

Hold that loop in your head as the shape of the domain.

Detect is instrumentation. Which metrics exist by default, which require the CloudWatch agent, what resolution they arrive at, and how long they are retained. The recurring exam trap is assuming a metric exists when it does not — memory utilization and disk space on EC2 are the classic pair, since the hypervisor cannot see inside the guest operating system and the agent must be installed to report them.

Decide is the alarm and query layer. Static thresholds where you know the normal range, anomaly detection where the normal range is seasonal, composite alarms where a single symptom produces a storm of individual alarms and you want one actionable signal instead.

Act is the automation layer. An alarm can notify an Amazon SNS topic, act directly on EC2 (stop, terminate, reboot, recover), or trigger an Auto Scaling action. Anything richer — run a script on the host, snapshot a volume, open a ticket, roll back a deployment — goes through EventBridge to a Systems Manager Automation runbook or a Lambda function.

Why the domain absorbed cost optimization

SOA-C02 carried a separate domain for cost and performance optimization. SOA-C03 folded that work into this one, and the merge tells you something about how the questions are framed. Right-sizing is treated as an operational activity driven by observed telemetry, not as a finance exercise. When a scenario says an instance family is oversized, the expected reasoning is that you looked at utilization metrics over a representative window and acted — not that someone read a bill.

Practically, that means AWS Compute Optimizer, AWS Cost Explorer's rightsizing recommendations, and Trusted Advisor checks belong to your mental map of this domain, and they belong there as consumers of the same telemetry you have been configuring.

What to build alongside this module

Wire the whole loop once in a sandbox account before you read further. Install the CloudWatch agent on an EC2 instance, publish memory utilization, alarm on it, route the alarm state change through EventBridge to a Systems Manager Automation runbook, and have the runbook do something visible. When you have watched that chain fire end to end, the rest of this domain reads as detail on parts you already understand rather than a list of service names.