SCS-C02 Threat Detection and Incident Response Practice Question

Exhibit

Refer to the exhibit.

CloudTrail log entry (simplified):
{
  "eventSource": "ec2.amazonaws.com",
  "eventName": "RunInstances",
  "userIdentity": {
    "arn": "arn:aws:iam::123456789012:role/AdminRole",
    "accountId": "123456789012"
  },
  "requestParameters": {
    "instanceType": "m5.xlarge",
    "imageId": "ami-0abcdef1234567890",
    "securityGroupSet": [{"groupId": "sg-0123456789abcdef0"}]
  },
  "responseElements": {
    "instancesSet": {
      "items": [{"instanceId": "i-0a1b2c3d4e5f6g7h8"}]
    }
  },
  "sourceIPAddress": "203.0.113.50",
  "userAgent": "console.amazonaws.com",
  "eventTime": "2025-03-15T14:30:00Z"
}

A security engineer reviews the CloudTrail log entry in the exhibit. The engineer notices that an EC2 instance was launched using an AdminRole. Which additional information would help determine if this is a legitimate action or a potential compromise?

⚠ Common exam trap

The trap here is that candidates focus on technical misconfigurations (like open security groups or unusual AMIs) rather than the behavioral anomaly of an administrative action originating from an unexpected IP, which is the most direct indicator of a potential compromise in CloudTrail logs.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The source IP address 203.0.113.50 is from an unexpected geographic location not associated with the company.

The source IP address 203.0.113.50 is from an unexpected geographic location not associated with the company. In CloudTrail, the `sourceIPAddress` field records the originating IP of the API call. If an AdminRole is used from an IP outside the company's known CIDR ranges or geographic regions, it strongly indicates a potential compromise—such as stolen credentials or an attacker using the role from an unauthorized network. This is a key indicator of anomalous behavior in threat detection.

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 AMI ID ami-0abcdef1234567890 is not a standard Amazon-provided AMI.
Why it's wrong here
A custom AMI ID does not inherently indicate an intrusion. Organizations routinely build and use golden images for consistent deployments, so a non-standard AMI is expected in many accounts. The CloudTrail log only shows the AMI ID used for the launch; without a pre-established whitelist of approved AMIs or additional context, this field is not a reliable sign of compromise.
✓
The source IP address 203.0.113.50 is from an unexpected geographic location not associated with the company.
Why this is correct
The source IP address 203.0.113.50 is recorded in the CloudTrail event as sourceIPAddress, and it originates from a geographic region outside the company's known operating footprint. Anomalous source IPs are a well-known indicator of compromised credentials or unauthorized access, especially when combined with API calls that create resources. This is the only option that represents an actual observable anomaly in the log entry itself, making it the strongest sign of suspicious activity.
✗
The instance type m5.xlarge is unusually large compared to previous launches.
Why it's wrong here
Instance size alone is not a useful indicator of compromise because resource requirements vary by application and workload. A change to a larger instance type could be legitimate scaling, and an attacker might also use a smaller instance; the CloudTrail log provides no baseline or expected instance type for comparison. Without a pattern of abnormal launches, such as a sudden increase in count or a change in region, this field does not provide actionable evidence.
✗
The security group sg-0123456789abcdef0 allows inbound SSH from 0.0.0.0/0.
Why it's wrong here
This statement about the security group rule cannot be verified from the CloudTrail RunInstances event, which includes only the security group IDs in the request parameters, not their ingress rules. Determining whether SSH is open to the world requires a separate DescribeSecurityGroups call or reviewing the security group's configuration. Even if the rule existed, it would be a misconfiguration that should be remediated, but it is not an anomaly revealed by the log entry in question.

Visual reference

Go deeper

SCS-C02 Threat Detection and Incident Response Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question