Enable access logging on the Application Load Balancer is correct because ALB access logs provide per-request records that capture timing for each stage and deliver those logs to Amazon S3 so you can examine request_processing_time, target_processing_time, and response_processing_time without changing application code.

Access logs include the fields request_processing_time, target_processing_time, and response_processing_time so you can separate load balancer queuing from target processing and outbound response time. The logs are stored in S3 and you can query them with Amazon Athena or process them with log analytics tools to get per-request latency distributions and identify slow requests or problematic targets.

Review Amazon CloudWatch metrics for the load balancer is insufficient because CloudWatch metrics for ALBs are aggregated over time windows and do not provide per-request timing details. You would need per-request logs or custom instrumentation to achieve that level of granularity.

Install the Amazon CloudWatch agent on the EC2 instances collects operating system and host level metrics and can forward logs, but it does not capture the ALB data plane timing fields such as request_processing_time and target_processing_time.

Use AWS CloudTrail to review API activity records control plane API calls and audit events and it does not provide data plane per-request latencies through the load balancer.

Full AWS Practitioner Certification Question