DOP-C02 Monitoring and Logging Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Enable VPC Flow Logs to capture traffic patterns.

  Why it's wrong here

  VPC Flow Logs capture only network-layer metadata about IP traffic, such as source/destination addresses, ports, protocol, and packet/byte counts. They do not inspect or record application-layer payloads, so HTTP request paths, status codes, and per-request latencies are entirely absent. Without these details, Flow Logs cannot explain why users see 5xx errors or experience slow responses, making them ineffective for application-level troubleshooting.

• ✓

  Enable ALB access logs and store them in Amazon S3.

  Why this is correct

  Enabling ALB access logs in Amazon S3 records every HTTP/HTTPS request processed by the load balancer, including the request URI, query string, client and target IPs, HTTP method, and both the ALB and target response status codes. Crucially, these logs contain the request processing time and target response time fields that directly expose where latency is introduced. This per-request detail makes access logs the most direct and accurate source for diagnosing application errors and performance bottlenecks at the HTTP layer.

• ✓

  Install the CloudWatch agent on EC2 instances to collect application logs and custom metrics.

  Why this is correct

  Installing the CloudWatch agent on the EC2 instances collects operating-system-level logs, application stdout/stderr, and custom metrics, then streams them to CloudWatch Logs and CloudWatch Metrics. This enables you to search application error messages, parse structured logs with CloudWatch Logs Insights, and create alarms for conditions such as exception counts or elevated memory usage. Unlike ALB access logs, the agent provides visibility into the application runtime itself, helping uncover root causes that never manifest as HTTP errors at the load balancer.

• ✗

  Enable AWS CloudTrail to log API calls made to the load balancer.

  Why it's wrong here

  AWS CloudTrail records management-plane (control-plane) API actions such as CreateLoadBalancer, ModifyTargetGroup, or SetSecurityGroups, along with the identity of the caller and the timestamp. It does not capture the data-plane HTTP requests that clients send through the load balancer, nor does it include application-layer details like status codes, paths, or response times. Thus CloudTrail is useful for auditing configuration changes and security events, but it cannot help diagnose application-level failures or performance degradation.

• ✓

  Enable detailed CloudWatch metrics for the ALB (e.g., RequestCount, TargetResponseTime).

  Why this is correct

  Detailed CloudWatch metrics for the ALB—such as TargetResponseTime, RequestCount, and HTTPCode_Target_5XX_Count—provide minute-level, aggregate views of traffic and target-group health, enabling near-real-time dashboards and automated alarms. These metrics also support percentile statistics (e.g., p99) that reveal latency outliers. However, they summarize traffic across all requests and do not contain individual request URIs, client IPs, or exact error codes, so they complement but cannot replace the forensic detail found in ALB access logs.

Go deeper

Related to this question