A company observes that a newly created Amazon CloudWatch alarm is not transitioning out of the INSUFFICIENT_DATA state. The alarm was created to track the mem_used_percent metric from an Amazon EC2…

Question

Options

• AEnable CloudWatch detailed monitoring for the EC2 instance
• BCreate an IAM instance profile that contains CloudWatch permissions. Add the instance profile to
• CMigrate the EC2 instance into a private subnet
• DCreate an IAM user that has an access key ID and a secret access key. Update the unified

• A
  6% (1)
• B
  71% (12)
• C
  12% (2)
• D
  12% (2)

Explanation

Option B is correct because the CloudWatch agent needs IAM permissions to publish metrics to CloudWatch - without an instance profile containing policies like CloudWatchAgentServerPolicy, the agent runs but silently fails to deliver data, leaving the alarm in INSUFFICIENT_DATA. An IAM instance profile (role attached to EC2) is the correct, credential-free mechanism for granting this access.

Why the distractors are wrong:

• A - Detailed monitoring only increases polling frequency for built-in EC2 metrics (CPU, network, etc.); mem_used_percent is a custom agent metric and is completely unaffected by it.
• C - The subnet location is irrelevant here; the agent's inability to publish is a permissions problem, not a network problem, and moving to a private subnet could actually introduce connectivity issues without a VPC endpoint or NAT gateway.
• D - Configuring the agent with IAM user access keys could technically work but is the wrong approach; AWS best practice is always instance profiles (roles) over long-term credentials embedded in config files.

Memory tip: Think "Agent needs a Badge" - the CloudWatch agent is a worker that needs an ID badge (IAM role via instance profile) to enter CloudWatch's building and drop off custom metrics. No badge = agent runs fine but metrics never arrive.

No community discussion yet for this question.