1.2 - Logging and log analysis (CloudWatch Logs, CloudTrail, Config)
AWS SysOps Administrator objective 1.2 covers logging and log analysis. In CloudWatch Logs you organize log groups and streams, set retention (logs never expire by default, a cost trap), push OS and application logs with the CloudWatch agent, turn log patterns into metrics and alarms with metric filters, query with Logs Insights, and stream to Kinesis or Lambda with subscription filters for central logging. AWS CloudTrail records API activity - management versus data events, an organization trail across accounts, and log file integrity validation - answering who did what. AWS Config records resource configuration over time and evaluates compliance with config rules, answering what a resource looks like and whether it drifted. Expect scenario questions that describe finding who made a change, catching a log pattern, or proving compliance, and ask whether CloudWatch Logs, CloudTrail or Config is the right tool.
Who did what (API calls) = CloudTrail. What a resource looks like over time and compliance = AWS Config. Turn a log pattern into an alarm = CloudWatch Logs metric filter.
Practice questions
1. Which TWO metrics are NOT collected by default for an EC2 instance and require the CloudWatch agent? (Choose TWO.)
- CPUUtilization, reported every 5 minutes by default
- Memory (RAM) utilization (correct answer)
- NetworkIn and NetworkOut traffic counters
- Disk (filesystem) space used (correct answer)
The hypervisor cannot see inside the guest OS, so memory and filesystem usage are not default EC2 metrics; the CloudWatch agent must be installed to publish them. CPU and network are hypervisor-visible and collected by default.
2. A custom application publishes a high-resolution CloudWatch metric. Which statement about high-resolution metrics is correct?
- They support 1-second granularity and 10- or 30-second alarms (correct answer)
- They are limited to a one-minute minimum granularity, like standard metrics
- They are available only for AWS-managed namespaces, never for custom ones
- They automatically triple the metric retention window inside CloudWatch
High-resolution custom metrics can be stored at 1-second granularity and alarmed on with 10- or 30-second periods. Standard metrics have a 1-minute minimum; retention is unchanged by resolution.
3. You want a single CloudWatch graph line that sums RequestCount across all instances in a namespace without listing each instance. Which feature do you use?
- A search expression combined with a metric math SUM function (correct answer)
- A composite alarm that references every instance dimension one by one
- A namespace-wide dimension filter applied at the metric unit level
- A high-resolution metric published from each instance every second
A search expression dynamically matches all matching metrics, and wrapping it in a metric math SUM produces one aggregated line without hardcoding instance IDs. Composite alarms combine alarm states, not metric graphs.
4. Your team wants to alarm on the 99th percentile of API latency to catch tail-latency spikes, not the average. Which CloudWatch statistic supports this?
- A percentile statistic such as p99 (correct answer)
- The Average statistic multiplied by a fixed safety factor of three
- The SampleCount statistic converted into milliseconds per request
- The Sum statistic divided by the evaluation period length in seconds
CloudWatch supports percentile statistics (p90, p99, etc.) that expose tail latency far better than the average, which hides spikes. SampleCount and Sum measure volume, not distribution.
5. An EC2 dashboard shows CPU but not memory or disk usage. What is the standard fix?
- Install the unified CloudWatch agent to publish memory and disk metrics (correct answer)
- Enable detailed monitoring so the hypervisor reports RAM every minute
- Turn on EC2 detailed monitoring and wait for memory metrics to appear
- Open a support case because guest memory metrics are simply not available
Memory and disk are guest-OS metrics that the hypervisor cannot see, so you install the unified CloudWatch agent to collect and publish them. Detailed monitoring only shortens the CPU/network sampling interval and never adds memory, so those options are traps.
6. You install the CloudWatch agent on an EC2 instance. Which IAM setup lets it push logs and metrics with least effort?
- Store an IAM user's access keys in the agent config file on disk
- Attach an instance profile with the CloudWatchAgentServerPolicy (correct answer)
- Give the instance the AdministratorAccess managed policy to be safe
- Nothing, because EC2 instances can write to CloudWatch without any role
An instance profile carrying CloudWatchAgentServerPolicy grants exactly the PutLogEvents / PutMetricData permissions the agent needs, with no long-lived keys. Static keys on disk are a security risk, AdministratorAccess is over-broad, and EC2 has no implicit CloudWatch access.