DOP-C02 Incident and Event Response 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.

• ✓

  The CloudWatch agent is not installed or configured to collect memory metrics.

  Why this is correct

  The CloudWatch agent is required to emit in-guest memory metrics. The default EC2 monitoring collects only hypervisor-level metrics such as CPU utilization, disk I/O, and network throughput; memory utilization is not visible from the hypervisor and must be reported by the agent inside the OS. If the agent is not installed or its configuration does not define memory as a collected metric, the MemoryUtilization metric will be absent, causing any alarm relying on it to remain in INSUFFICIENT_DATA and never trigger.

• ✗

  The instance is using instance store volumes instead of EBS, which prevents metric collection.

  Why it's wrong here

  The underlying storage type of the EC2 instance—whether EBS or instance store—has no bearing on CloudWatch metric collection for standard EC2 metrics. CloudWatch receives basic instance metrics (e.g., CPUUtilization, DiskReadOps, NetworkIn) directly from the AWS hypervisor, and these are published whether the root volume is EBS or ephemeral instance store. Instance store volumes are not a supported basis for blocking or preventing metric delivery; the actual reason memory metrics are missing is that the in-guest CloudWatch agent is not running, not the storage volume type.

• ✗

  The CloudWatch metrics retention period is set to 1 day, so old alarms were deleted.

  Why it's wrong here

  CloudWatch metric retention is independent of alarm evaluation and alarm lifecycle. The default retention period is 15 months, and while data points disappear after that period, existing alarms are never deleted solely because of a retention setting; they enter the INSUFFICIENT_DATA state if no recent data is available. Even if retention were set to 1 day, the alarm would still exist and would evaluate against the metric stream—the reason a memory alarm does not fire is simply that no memory metric is being published, not that the alarm was removed from the account.

• ✗

  The EC2 instance's root EBS volume is encrypted, blocking CloudWatch agent logs.

  Why it's wrong here

  EBS volume encryption operates at the storage-layer level, transparently encrypting data at rest, and it does not interfere with any software running on the instance or its network communications. The CloudWatch agent writes logs and metrics to CloudWatch over HTTPS using the AWS API, which does not read from or write to the EBS volume in a way that encryption could block. If the agent were unable to send metrics, the cause would typically be missing IAM permissions, network restrictions, or a misconfigured agent, not the encryption state of the root volume.

Go deeper

Related to this question