The SAA-C03 exam almost never asks “what is CloudWatch?” Instead it hands you a scenario — “the security team needs a record of every API call for an audit,” “the platform must automatically add servers when CPU climbs,” “an operator changed a security group and no one knows who” — and asks which service solves it. Monitoring and observability questions are some of the most reliably winnable points on the exam if you can tell five very similar-sounding services apart, and some of the easiest to lose if CloudWatch and CloudTrail blur together in your head.
This guide draws sharp lines between the five services the SAA-C03 tests: CloudWatch, CloudTrail, AWS Config, EventBridge, and X-Ray. For each one you will learn what it actually does, the exact keyword that signals it on the exam, and how it connects to the other four. If you are mapping out your overall preparation, start with the AWS Solutions Architect Associate guide for 2026; monitoring shows up across all four exam domains, and it reinforces the resilient architectures and secure architectures material directly.
The One-Sentence Test That Separates the Five Services
Before the detail, memorize these one-liners. On most exam questions, this alone gets you to the answer:
| Service | The one-sentence job | Signal words |
|---|---|---|
| CloudWatch | Monitors performance and health — metrics, logs, alarms, dashboards | ”utilization,” “metric,” “alarm,” “threshold,” “logs” |
| CloudTrail | Records who did what — an audit log of API calls | ”audit,” “who made this change,” “governance,” “API history” |
| AWS Config | Tracks resource configuration and compliance over time | ”configuration change,” “compliance,” “drift,” “desired state” |
| EventBridge | Routes events to targets so the system reacts automatically | ”when X happens, automatically do Y,” “event-driven” |
| X-Ray | Traces a request across microservices to find bottlenecks | ”distributed tracing,” “latency across services,” “bottleneck” |
The classic exam trap is CloudWatch versus CloudTrail. Say it out loud until it is automatic: CloudWatch is about performance; CloudTrail is about audit. “Is the database slow?” is CloudWatch. “Who deleted the database?” is CloudTrail.
Amazon CloudWatch: Metrics, Alarms, Logs, and Dashboards
CloudWatch is the observability backbone of AWS. It has four capabilities the SAA-C03 expects you to know.
Metrics
A metric is a time-ordered set of data points — CPU utilization, request count, queue depth. AWS services publish metrics automatically at no extra setup: EC2 sends CPUUtilization, an ALB sends RequestCount and target health, an SQS queue sends ApproximateNumberOfMessagesVisible.
Two facts the exam loves:
- Standard metrics are every 5 minutes; detailed monitoring is every 1 minute (for an extra charge). If a question needs faster reaction, the answer is often “enable detailed monitoring.”
- Memory and disk usage are NOT default EC2 metrics. The hypervisor cannot see inside the guest OS, so RAM and disk-space utilization require the CloudWatch agent installed on the instance. If a scenario says “alert on memory usage,” the answer includes the CloudWatch agent — this is one of the most repeated SAA-C03 facts.
Custom Metrics
Anything AWS does not measure for you, your application can publish as a custom metric — active user sessions, orders per minute, a business KPI. High-resolution custom metrics can go down to 1-second granularity.
CloudWatch Alarms
An alarm watches a single metric against a threshold and moves between OK, ALARM, and INSUFFICIENT_DATA states. What makes alarms an architecture tool, not just a notification, is their actions:
- Send a notification to an SNS topic (which can fan out to email, SMS, or a Lambda function).
- Trigger an Auto Scaling action — add or remove instances.
- Perform an EC2 action — stop, terminate, reboot, or recover an instance.
CPUUtilization > 70% for 3 minutes
│
▼
CloudWatch Alarm ──► SNS topic ──► email + Lambda
│
└──► Auto Scaling Group: add 1 instanceThat chain — metric to alarm to Auto Scaling — is the mechanism behind dynamic scaling, which ties this topic straight into the resilient architectures domain. When a question describes “automatically add capacity when load increases,” a CloudWatch alarm driving an Auto Scaling policy is the pattern being tested.
CloudWatch Logs
CloudWatch Logs centralizes log data from EC2 (via the agent), Lambda (automatically), VPC Flow Logs, and more. Two features earn exam mentions:
- Logs Insights — a query language for searching and analyzing log data interactively.
- Metric filters — turn a pattern in your logs (say, the count of “ERROR” lines) into a CloudWatch metric you can alarm on. This is the standard way to “alert when the application logs a specific error.”
Log groups have a retention setting; by default logs are kept forever (and billed forever), so setting retention or exporting older logs to S3 is a common cost-and-governance answer.
AWS CloudTrail: The Audit Log of Who Did What
CloudTrail records API activity across your account — nearly every action, whether from the console, CLI, SDK, or another AWS service, is logged as an event showing who did it, when, from where, and what they acted on.
The distinctions the SAA-C03 tests:
- Management events (the default) record control-plane operations — creating an instance, modifying a security group, attaching a policy.
- Data events record high-volume data-plane operations — S3 object-level GetObject/PutObject, Lambda function invocations. These are off by default because they are voluminous, and you enable them deliberately.
Two more high-value facts:
- CloudTrail keeps 90 days of event history viewable in the console for free. For long-term retention you create a trail that delivers logs to an S3 bucket — the standard answer for “retain audit logs for years.”
- An organization trail logs every account in an AWS Organization into one place — the exam’s answer for centralized, multi-account auditing. Log file validation lets you prove the logs were not tampered with, which matters for compliance.
Keep the split clean: CloudWatch tells you the system is misbehaving; CloudTrail tells you who changed it. In an incident you use both — CloudWatch to detect, CloudTrail to investigate.
AWS Config: Configuration State and Compliance Over Time
AWS Config answers a question neither CloudWatch nor CloudTrail does well: “What did this resource’s configuration look like, is it compliant with our rules, and how has it changed?”
Config continuously records the configuration of your resources and keeps a timeline of every change. On top of that timeline sit Config rules — checks that evaluate whether a resource is compliant with a desired state:
- Are all EBS volumes encrypted?
- Is any S3 bucket publicly readable?
- Do all security groups block unrestricted SSH on port 22?
Rules can be AWS-managed (pre-built) or custom (backed by Lambda). When a resource drifts out of compliance, Config flags it and can trigger automatic remediation through Systems Manager Automation — for example, re-encrypting a volume or removing a public bucket ACL.
The CloudTrail-versus-Config line is a favorite exam trap:
| Question shape | Service |
|---|---|
| ”Who made the change and when?” | CloudTrail (the API call and the identity) |
| “What is the current configuration, and does it comply with policy?” | AWS Config (the state and the rule) |
| “How did this resource look last Tuesday?” | AWS Config (configuration timeline) |
| “Prove no one deleted our audit records” | CloudTrail (log file validation) |
Think of it this way: CloudTrail logs the action; Config tracks the resulting state and its compliance. They complement each other, and a strong governance setup runs both — a point that reinforces the secure architectures domain.
Amazon EventBridge: Reacting to Events Automatically
EventBridge (the evolution of CloudWatch Events) is a serverless event bus. It receives events — from AWS services, your own applications, or SaaS partners — and routes them to targets based on rules you define. It is the glue that turns monitoring signals into automated responses.
Where a CloudWatch alarm reacts to a metric crossing a threshold, EventBridge reacts to a thing happening:
- An EC2 instance changes to the “stopped” state → run a Lambda function.
- A new object matching a pattern appears → start a Step Functions workflow.
- A scheduled cron expression fires → trigger a nightly job (EventBridge Scheduler).
Event: "EC2 instance entered state: stopped"
│
▼
EventBridge rule (pattern match)
│
├──► Lambda (auto-remediate)
├──► SNS (notify on-call)
└──► Step Functions (run workflow)The exam distinction between an alarm and an EventBridge rule:
- CloudWatch alarm → “when a metric breaches a threshold” (CPU over 70 percent, queue depth over 1000).
- EventBridge rule → “when a specific event or state change occurs” (an instance stopped, a config rule went non-compliant, a scheduled time arrived).
Many real systems chain them: a metric breaches an alarm, the alarm’s state change becomes an event, EventBridge routes it to remediation. EventBridge is also central to event-driven decoupling, which you will recognize from SQS, SNS, and EventBridge patterns.
AWS X-Ray: Tracing Requests Across a Distributed System
CloudWatch tells you a service is slow. X-Ray tells you which service in a chain is slow. It provides distributed tracing — following a single request as it travels through a front end, an API, several microservices, and a database, and showing where the time actually went.
X-Ray produces a service map (a visual graph of your components and the calls between them) and per-segment timing, so you can point at the one downstream call adding 800 milliseconds of latency. On the SAA-C03, the signal is unambiguous: any scenario mentioning “distributed tracing,” “microservices latency,” or “find the bottleneck across services” is X-Ray. It integrates natively with Lambda, API Gateway, ECS, and EC2, and connects the performance story to the high-performing architectures domain.
Putting It Together: A Worked Scenario
Imagine a three-tier web application with intermittent slowness and a recent unexplained outage. Here is how the five services divide the work:
| Need | Service |
|---|---|
| Alert when the ALB’s 5xx error rate spikes | CloudWatch alarm on the ALB metric |
| Automatically add web servers under load | CloudWatch alarm → Auto Scaling |
| Find which microservice adds the latency | X-Ray service map |
| Discover who changed the security group before the outage | CloudTrail event history |
| Confirm all security groups still comply with the no-open-SSH rule | AWS Config rule |
| Auto-remediate any instance that enters a failed state | EventBridge rule → Lambda/SSM |
| Search application logs for the error pattern | CloudWatch Logs Insights + metric filter |
Notice that no single service does everything, and none of them fully overlaps another. That is exactly the discrimination the exam is testing — not whether you can define CloudWatch, but whether you reach for the right one when the scenario is deliberately worded to tempt the wrong one.
The SAA-C03 Monitoring Cheat Sheet
| Scenario signal | Service / feature |
|---|---|
| ”Alert on EC2 memory or disk usage” | CloudWatch agent (not a default metric) |
| “React faster than 5-minute metrics” | Enable detailed monitoring (1-minute) |
| “Automatically scale on CPU” | CloudWatch alarm → Auto Scaling |
| ”Notify a team when a threshold is breached” | CloudWatch alarm → SNS |
| ”Alert when the app logs a specific error” | CloudWatch Logs metric filter → alarm |
| ”Audit trail of who did what” | CloudTrail |
| ”Retain audit logs for years / multi-account” | CloudTrail trail to S3 / organization trail |
| ”Log high-volume S3 object access” | CloudTrail data events |
| ”Check resources for compliance and drift” | AWS Config rules |
| ”Auto-fix a non-compliant resource” | Config + SSM Automation remediation |
| ”Do Y automatically when event X occurs” | EventBridge rule |
| ”Run a scheduled job serverlessly” | EventBridge Scheduler |
| ”Find the bottleneck across microservices” | X-Ray distributed tracing |
Practice Until the Discriminations Are Reflexive
Monitoring questions punish hesitation. The difference between a right and wrong answer is usually a single keyword — “audit” versus “utilization,” “configuration” versus “who,” “event” versus “threshold” — and under exam time pressure it is easy to grab the familiar name (CloudWatch) when the scenario is quietly pointing at CloudTrail or Config. The cure is repetition against realistic questions until each signal word snaps to its service without conscious effort.
Sailor’s AWS Solutions Architect Associate Certification-Ready mock exam bundle is designed for that: full-length, domain-weighted practice exams that reproduce the SAA-C03’s scenario style — including the CloudWatch-versus-CloudTrail-versus-Config traps that separate a pass from a near-miss. Work them under timed conditions, review every miss to see which keyword you misread, and you will turn monitoring from a coin-flip into a block of guaranteed points. It pairs naturally with your work on the cost-optimized and resilient domains.
Conclusion
Five services, five distinct jobs: CloudWatch watches performance, CloudTrail records who did what, AWS Config tracks configuration and compliance, EventBridge reacts to events, and X-Ray traces requests across services. The SAA-C03 will not ask you to define them — it will describe a situation and trust that most candidates blur the boundaries. Keep the one-sentence tests sharp, memorize the signal words, and practice the scenarios until the right service is obvious on sight. Do that, and the monitoring and observability questions become some of the most dependable points on the entire exam. Anchor the topic in the broader SAA-C03 study path and keep drilling until the discriminations are automatic.
Frequently Asked Questions
What is the difference between CloudWatch and CloudTrail?
CloudWatch monitors performance and health — metrics, logs, alarms, and dashboards that tell you whether your systems are working well. CloudTrail is an audit log — it records who made which API call, when, and from where. Simple test: “Is the system slow or unhealthy?” is CloudWatch; “Who changed or deleted this?” is CloudTrail.
When do I need the CloudWatch agent?
You need the CloudWatch agent whenever you want metrics that AWS cannot see from outside the instance — most importantly memory usage and disk space, which are not default EC2 metrics. The agent also ships custom application logs to CloudWatch Logs. Any exam scenario asking to alarm on RAM or disk utilization implies the agent.
What is the difference between AWS Config and CloudTrail?
CloudTrail records the action and the identity — the API call that changed something and who made it. AWS Config records the resulting configuration state and evaluates it against compliance rules over time. Use CloudTrail to answer “who did it,” and Config to answer “what is the current configuration and does it comply with policy.”
When should I use EventBridge versus a CloudWatch alarm?
Use a CloudWatch alarm when the trigger is a metric crossing a threshold (CPU over 70 percent, queue depth too high). Use an EventBridge rule when the trigger is a discrete event or state change (an instance stopped, an object was created, a scheduled time arrived) and you want to route it to targets like Lambda, SNS, or Step Functions for an automated response.
What does AWS X-Ray do that CloudWatch does not?
CloudWatch tells you that a service is slow or erroring in aggregate. X-Ray provides distributed tracing — it follows an individual request across multiple microservices and shows exactly which component added latency or failed. If a question mentions tracing a request across services or finding a bottleneck in a microservices architecture, the answer is X-Ray.
How long does CloudTrail keep events, and how do I retain them longer?
CloudTrail keeps the last 90 days of management events viewable for free in the console. For longer retention, create a trail that delivers events to an S3 bucket, where you control lifecycle and retention. For multiple accounts, an organization trail centralizes all of them, and log file validation proves the records were not altered.
Is monitoring a big part of the SAA-C03 exam?
Monitoring and observability are not a standalone domain, but they appear throughout all four SAA-C03 domains — resilient (alarms driving Auto Scaling), secure (CloudTrail and Config for governance), high-performing (X-Ray, detailed monitoring), and cost-optimized (log retention, right-sizing signals). Knowing these five services well pays off across the whole exam.