DOP-C02 Monitoring and Logging Practice Test 18 — 15 Questions

Question 1

A company runs a web application on Amazon EC2 instances behind an Application Load Balancer. The operations team wants to analyze application access logs and error rates. They need to identify the top IP addresses making requests, as well as the distribution of HTTP status codes over time. Which THREE steps should the team take to achieve this? (Select THREE.)

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Enable access logs on the Application Load Balancer and store them in an Amazon S3 bucket.. Enabling access logs on the Application Load Balancer and storing them in an S3 bucket captures detailed HTTP request data, including client IPs, request paths, and HTTP status codes. This raw log data is essential for analyzing top IP addresses and status code distributions over time.

Answer

Enable AWS CloudTrail to log all API calls.

Answer

Enable VPC Flow Logs to capture IP traffic data.

Question 2

A company runs a production web application on Amazon EC2 instances that are part of an Auto Scaling group. The instances are behind an Application Load Balancer. The DevOps team has enabled detailed CloudWatch metrics and set up a CloudWatch dashboard to monitor the application. Recently, the team noticed that the CPU Utilization metric for the Auto Scaling group shows a spike every day at 2:00 PM, but the application performance remains normal. The team wants to investigate the cause of the CPU spike. What should the team do FIRST to identify the root cause?

Accepted Answer

Use CloudWatch Logs Insights to query the application logs on the instances to identify any scheduled tasks or jobs running at 2:00 PM.. The FIRST step in root-cause analysis is to gather evidence, not to change the environment. CloudWatch Logs Insights allows the team to query application and system logs on the EC2 instances to identify scheduled tasks (e.g., cron jobs, batch scripts, log rotation) that run at 2:00 PM and cause the CPU spike. This is non-disruptive and directly targets the symptom's timing, providing data to confirm or rule out hypotheses before making changes.

Answer

Enable AWS CloudTrail to log all API calls to the instances.

Answer

Disable any scheduled tasks on the instances to see if the spike stops.

Answer

Increase the instance size to provide more CPU capacity to handle the spike.

Question 3

A company runs a multi-region application on Amazon EC2 instances across us-east-1 and eu-west-1. The application uses an Amazon Aurora global database for writes in us-east-1 and reads in eu-west-1. The DevOps team wants to monitor the replication lag between the primary and secondary regions. They have set up a CloudWatch alarm on the AuroraReplicaLag metric in both regions. However, they notice that the alarm in eu-west-1 sometimes triggers false positives when the lag spikes briefly but then recovers. The team wants to reduce false alarms while still being alerted to sustained high lag that could impact read replicas. The team is already using a standard CloudWatch alarm with a period of 1 minute and evaluation periods of 1. What should the team change to reduce false positives?

Accepted Answer

Increase the number of evaluation periods to 3, so the alarm triggers only if the lag is high for 3 consecutive minutes.. The false positives occur because a single 1-minute evaluation period triggers on brief, transient lag spikes. Increasing the number of evaluation periods to 3 means the alarm fires only when the lag exceeds the threshold for 3 consecutive 1-minute periods, filtering out short spikes while still catching sustained high lag. This is the standard CloudWatch approach to reduce false positives without losing sensitivity to real issues.

Answer

Increase the alarm threshold to a higher value, such as 10 seconds.

Answer

Reduce the metric period to 30 seconds to get more granular data.

Answer

Create a composite alarm that triggers when both the AuroraReplicaLag and CPUUtilization metrics are high.

Question 4

A company runs a serverless application using AWS Lambda and Amazon API Gateway. The application processes user uploads to an S3 bucket. The operations team uses CloudWatch Logs for monitoring, but they are finding it difficult to correlate logs across multiple Lambda functions that handle different parts of the workflow. The team wants to trace requests as they flow through the application and identify bottlenecks or errors. The team has already enabled CloudWatch Logs for all Lambda functions. What should the team do to achieve end-to-end request tracing?

Accepted Answer

Enable AWS X-Ray on the Lambda functions and API Gateway to trace requests end-to-end.. AWS X-Ray is the native distributed tracing service that integrates with Lambda and API Gateway to trace requests end-to-end across services. Enabling X-Ray on the Lambda functions and API Gateway propagates a trace ID through the workflow, letting the team visualize the full request path, latency per segment, and errors. CloudWatch ServiceLens can then surface the X-Ray traces alongside logs and metrics for correlation.

Answer

Use CloudWatch Contributor Insights to analyze the log data and identify the top contributors to latency.

Answer

Use AWS CloudTrail to log all API calls and correlate them with CloudWatch Logs.

Answer

Create a CloudWatch ServiceLens service map to visualize the application components.

Question 5

A company runs a critical application on Amazon EKS. The DevOps team uses Prometheus for monitoring and Grafana for visualization. The team has set up a Prometheus server on an EC2 instance to scrape metrics from the EKS cluster. However, they are experiencing high memory usage on the Prometheus server, and some metrics are being dropped because of the retention period. The team wants to implement a scalable and managed monitoring solution that can store metrics for longer durations without the operational overhead of managing the Prometheus server. The team also wants to retain the ability to use PromQL queries and Grafana dashboards. What should the team do?

Accepted Answer

Migrate to Amazon Managed Service for Prometheus to ingest and store metrics, and use Amazon Managed Grafana for visualization.. Amazon Managed Service for Prometheus is a scalable, fully managed service that ingests and stores Prometheus metrics, supports PromQL queries, and integrates seamlessly with Amazon Managed Grafana. This eliminates the operational overhead of managing a Prometheus server while enabling longer retention and scaling. Option A is incorrect because Amazon Managed Grafana is a visualization tool only; it does not store metrics. Option C is incorrect because increasing the EC2 instance size does not address the operational overhead or scalability issues; it only postpones the problem. Option D is incorrect because Amazon CloudWatch Container Insights does not support PromQL natively, and migrating to CloudWatch would require rewriting queries and dashboards, losing compatibility with existing Prometheus and Grafana setups.

Answer

Use Amazon Managed Grafana to visualize metrics directly from the EKS cluster without a Prometheus server.

Answer

Increase the EC2 instance size for the Prometheus server and extend the retention period.

Answer

Set up Amazon CloudWatch Container Insights to collect metrics from the EKS cluster and store them in CloudWatch Logs.

Question 6

A company runs a web application on an Auto Scaling group of EC2 instances. The operations team uses CloudWatch alarms to monitor the application. They have set up a CPUUtilization alarm that triggers when the average CPU exceeds 70% for 5 minutes. The alarm triggers a scaling policy to add instances. Recently, the team noticed that the alarm frequently triggers during the day, but the application performance is acceptable. They suspect the alarm is too sensitive and want to reduce the number of false alarms. The team wants to keep the alarm responsive to real CPU spikes but avoid triggering on short bursts. What should the team change in the alarm configuration?

Accepted Answer

Increase the number of evaluation periods to 3, so the alarm triggers only if CPU is high for 3 consecutive periods.. To reduce false alarms while remaining responsive to real CPU spikes, increase the number of evaluation periods. With 3 consecutive periods, the alarm triggers only if CPU exceeds 70% for 15 minutes (assuming 5-minute periods), filtering out short bursts. This maintains responsiveness to sustained spikes while avoiding triggers on transient spikes.

Answer

Create a composite alarm that combines CPUUtilization with MemoryUtilization.

Answer

Reduce the metric period to 1 minute and keep evaluation periods at 1.

Answer

Lower the threshold to 60% to catch more CPU spikes.

Question 7

Refer to the exhibit. A DevOps engineer runs this query to investigate a spike in errors. What is the most likely interpretation?

Accepted Answer

The error rate is increasing sharply in the last 15 minutes.. The query counts ERROR messages per 5-minute bin for a specific log stream. The output shows a clear increasing trend from 1 to 12 errors over the last 20 minutes, indicating a recent escalation of errors.

Answer

The error rate is decreasing over time.

Answer

The error rate is stable with no significant change.

Answer

The query is incorrectly filtering log streams.

Question 8

Refer to the exhibit. An alarm is configured as shown. The CPU utilization averages 85% for 10 minutes, then spikes to 95% for the next 5 minutes, and returns to 80%. How many times will the SNS topic receive a notification?

Accepted Answer

0. Per the exhibit: Period=300s (5 min), EvaluationPeriods=2, Threshold=90.0, ComparisonOperator=GreaterThanThreshold, no DatapointsToAlarm override (so 2 consecutive breaching 5-minute periods are required to enter ALARM). CPU averages 85% for two 5-minute periods (not breaching, since 85 is not > 90), then 95% for one 5-minute period (breaching), then returns to 80% (not breaching). The single breaching period is immediately preceded and followed by non-breaching periods, so the alarm never accumulates 2 consecutive breaches and never transitions into ALARM -- it stays in OK the entire time. Since neither AlarmActions nor OKActions fire without an actual state transition, and none occurs, the SNS topic receives zero notifications.

Answer

1

Answer

2

Answer

3

Question 9

Refer to the exhibit. A security team reviews this CloudTrail log entry. Which finding is most concerning?

Accepted Answer

The user did not authenticate with MFA.. The session was created without MFA (mfaAuthenticated: false). This is a security concern because the role allows console access and the user did not use MFA, increasing risk of unauthorized access. The termination is the action, but the lack of MFA is a security gap.

Answer

The event occurred in us-east-1.

Answer

The instance was terminated by an assumed role.

Answer

The source IP is from a public IP.

Question 10

Refer to the exhibit. A DevOps engineer runs the CloudWatch Logs Insights query and sees a spike in errors at 12:00. Which action would best help identify the root cause?

Accepted Answer

Query the logs around 12:00 without aggregation to see the actual error messages.. The query shows a sudden spike at 12:00. To identify the root cause, the engineer should look at the error messages themselves around that time. Filtering by @timestamp and @message to see the actual error messages will help identify the type of error. Adding a filter for a specific error pattern or grouping by error message would also help.

Answer

Add a filter for @logStream to see which log stream has the most errors.

Answer

Increase the limit to 100 to see more results.

Answer

Change the bin time to 1m to get more granular data.

Question 11

Refer to the exhibit. The CloudWatch alarm is set on CPUUtilization. The instance's CPU at 10:00 is 75%, at 10:05 is 82%, and at 10:10 is 85%. Will the alarm trigger?

Accepted Answer

Yes, but only after 10:10 when two consecutive periods are above the threshold.. The alarm evaluates 2 consecutive periods (each 5 minutes). At 10:05, the average for that period is 82% (above 80), but the previous period (10:00) average is 75% (below 80). So only one period is breached. At 10:10, the average for that period is 85% (above 80), and the previous period (10:05) average is 82% (above 80). So two consecutive periods are breached, triggering the alarm.

Answer

Yes, because the CPU exceeded 80% at 10:05.

Answer

No, because the alarm uses Average statistic and the average over the entire time is below 80%.

Answer

No, because the first data point at 10:00 is below the threshold.

Question 12

Refer to the exhibit. An administrator wants to be notified when any EC2 instance is launched in the account. Which combination of services would provide the most efficient and cost-effective solution?

Accepted Answer

Create an Amazon EventBridge rule that matches RunInstances events from CloudTrail and sends to an SNS topic.. The most efficient and cost-effective solution is to create an Amazon EventBridge rule that matches RunInstances events from CloudTrail and sends notifications to an SNS topic. EventBridge provides near real-time event processing with minimal overhead, and CloudTrail captures EC2 instance launch events. This avoids the need for continuous polling or additional services.

Answer

Enable detailed billing reports and create a cost anomaly detection monitor.

Answer

Use AWS Config rules to detect non-compliant instances and trigger an SNS notification.

Answer

Set up a CloudWatch alarm on the RunInstances metric in the EC2 namespace.

Question 13

A company runs a containerized order-processing service on Amazon EKS. The DevOps team wants to detect when the service's CPU utilization exceeds 80% for 5 consecutive minutes and then automatically notify an on-call engineer. They also need to see both application logs and CPU metrics side-by-side in a single dashboard for troubleshooting. Which combination of AWS services should the team use to meet these requirements with the LEAST operational overhead?

Accepted Answer

Amazon CloudWatch Container Insights with CloudWatch alarms and CloudWatch dashboards. Container Insights provides native EKS monitoring with automatic metric and log collection, and CloudWatch alarms and dashboards integrate directly to alert on CPU thresholds and visualize logs and metrics together. The other options either lack CPU metric collection or require substantial additional tooling and management, making them less suitable for a low-overhead solution.

Answer

AWS X-Ray with CloudWatch Logs Insights and CloudWatch alarms

Answer

AWS CloudTrail with Amazon EventBridge rules and Amazon SNS topics

Answer

Amazon Managed Service for Prometheus with AWS Distro for OpenTelemetry and Grafana dashboards

Question 14

A platform team runs Amazon EKS clusters across three AWS accounts and wants centralized observability. They need (1) container-level CPU and memory metrics with custom dimensions for namespace and workload, and (2) application logs from all pods shipped to a single destination, queryable with a structured query language. Which TWO actions should the team take? (Choose two.)

Accepted Answer

Configure Fluent Bit on each node to send pod logs to a CloudWatch Logs log group, and use CloudWatch Logs Insights for structured queries.. Container Insights via the CloudWatch Observability EKS add-on supplies the CPU and memory metrics with namespace and workload dimensions, while Fluent Bit log shipping to CloudWatch Logs provides the centralized, queryable log destination. Together they satisfy both the metric-dimension and structured-log-query requirements across the three accounts using native AWS observability services.

Answer

Enable AWS CloudTrail data events on the EKS cluster to capture pod-level container metrics from the Kubernetes API server.

Answer

Deploy Prometheus with the CloudWatch agent's Prometheus scraping feature and rely on CloudWatch Logs for log aggregation without Fluent Bit.

Answer

Use AWS Config conformance packs to aggregate pod logs from all three accounts into a single queryable destination.

Question 15

A DevOps engineer supports a Python application on AWS Lambda that writes structured JSON logs to CloudWatch Logs. When a request fails, the engineer must be able to search all invocations across a log group for a specific request ID and see only lines containing that ID, returning results in seconds. Which approach meets this requirement with the least effort?

Accepted Answer

Use CloudWatch Logs Insights with a query that filters on the request ID field parsed from the JSON log events.. CloudWatch Logs Insights is purpose-built for interrogating log groups with a query language that understands JSON, so filtering on a request ID field returns the exact log lines quickly. It works against the existing log group without new infrastructure, which satisfies both the speed and minimal-effort constraints.

Answer

Create a CloudWatch Logs metric filter that matches the request ID pattern and graph the resulting metric on a dashboard.

Answer

Subscribe the log group to a Lambda function that scans events and writes matches to an Amazon DynamoDB table.

Answer

Export the log group to Amazon S3 and query it with Amazon Athena using a Glue table.