SCS-C02 Infrastructure Security 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.

• ✗

  Restrict instance types at the VPC level using network ACLs.

  Why it's wrong here

  VPC network ACLs operate at layers 3 and 4, filtering traffic by IP addresses, ports, and protocols; they never evaluate EC2 instance types because that attribute exists only in the fleet/API metadata, not in packet headers. NACLs also apply to traffic crossing subnet boundaries, not to the RunInstances API call itself, so a launch would succeed even if a future network flow matched. This is therefore not a mechanism to restrict instance types, and it cannot satisfy a preventive control requirement.

• ✗

  Use AWS CloudTrail to monitor instance launches and send alerts.

  Why it's wrong here

  AWS CloudTrail records ec2:RunInstances events after the fact, capturing the instance type as a field in the event, and EventBridge rules can trigger alerts or Lambda remediation. However, the API call has already been authorized and the instance launched before the log entry is processed; there is no way for CloudTrail to block or modify the launch. It is a detective/auditing control, not a preventive restriction, so it does not restrict instance types in the required way.

• ✓

  Apply a Service Control Policy (SCP) that denies ec2:RunInstances with noncompliant instance types.

  Why this is correct

  An SCP applied at the root or OU level with a Deny effect for ec2:RunInstances and a StringNotLike/StringNotEquals condition on ec2:InstanceType explicitly blocks noncompliant launches for all principals inside the affected accounts, including IAM users, roles, and the root user. SCPs provide an authoritative guardrail because they are evaluated as a filter on the account's effective permissions and cannot be overridden by a more permissive IAM policy within that account. This gives central governance across the entire AWS Organization, making it the correct preventive control.

• ✗

  Create an IAM role that denies launch of noncompliant instances.

  Why it's wrong here

  An IAM role is a principal identity; attaching a policy that denies ec2:RunInstances to that role would only restrict callers who happen to assume that role, and it could be coupled with a trust policy but still doesn't bind the whole AWS account or other roles. Moreover, IAM is account-scoped and has no authority over other accounts in the organization, so it cannot centrally enforce a policy. The root user of the account or any other role with its own attached policies would remain unaffected, leaving the restriction trivial to bypass.

• ✓

  Use AWS Config rules to detect and automatically stop noncompliant instances.

  Why this is correct

  AWS Config can evaluate the instance type of each newly launched EC2 instance against a custom or managed rule, mark it as noncompliant, and invoke an automatic remediation via Systems Manager Automation or Lambda to stop or terminate the instance. This is a corrective control that operates after launch rather than at the API authorization layer, but it does enforce the requirement in practice. It is accurate as a correct option, though less immediate than an SCP, and serves as common defense-in-depth when paired with a preventive policy.

Go deeper

Related to this question