SCS-C02 Management and Security Governance Practice Question

Exhibit

Refer to the exhibit.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "ec2:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "ec2:InstanceType": "t3.micro"
        }
      }
    }
  ]
}

A security engineer attaches the above SCP to an OU containing development accounts. The engineer expects that only t3.micro instances can be launched, but developers report that they cannot launch any EC2 instances. What is the MOST likely reason?

⚠ Common exam trap

A common mix-up: candidates assume a Deny statement with a condition implicitly allows all other actions, forgetting that SCPs follow a default-deny model where any action not explicitly allowed is denied.

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 SCP denies all ec2 actions because there is no explicit allow statement.

SCPs operate on a default-deny model: all actions are implicitly denied unless explicitly allowed. The policy only denies non-t3.micro instance types but does not include an explicit Allow statement for ec2:RunInstances or any other EC2 action. Without an explicit Allow, the implicit deny blocks all EC2 actions, including launching t3.micro instances.

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 SCP syntax is invalid because it uses Deny without an explicit Allow.
Why it's wrong here
Deny statements are inherently valid in SCPs and do not need to be paired with an explicit Allow in the same policy. SCPs use the same JSON policy syntax as IAM, and a Deny effect is a standard element used to explicitly block actions. Because the default behavior of an SCP is to deny everything that is not allowed, the syntax is not invalid.
✗
The condition StringNotEquals is evaluated incorrectly for EC2 instance types.
Why it's wrong here
The condition is syntactically correct and uses the valid ec2:InstanceType condition key; StringNotEquals would make the Deny apply to actions when the instance type is not among the listed values. However, the real reason EC2 actions are blocked is that the SCP lacks a single Allow statement, so the condition's outcome is irrelevant. Even for instance types that match the list, the action is still denied by the implicit default deny.
✗
The SCP is applied at the organization root and overrides the OU-level policy.
Why it's wrong here
The exhibit clearly shows this SCP attached to an OU, not to the organization root. Even if the same SCP were attached at the root, SCPs are additive filters that are all evaluated together; a root-level SCP does not override an OU-level SCP, and an explicit deny from any SCP wins. The actual problem is the missing Allow, not the attachment point.
✓
The SCP denies all ec2 actions because there is no explicit allow statement.
Why this is correct
SCPs act as permission boundaries and never grant permissions; they only filter the actions that IAM policies allow. If an SCP contains only Deny statements and no Allow statement permitting EC2 actions, the implicit default deny applies to every EC2 API call, regardless of what IAM identity-based policies grant. This is why the policy denies all EC2 actions.

Go deeper

SCS-C02 Management and Security Governance Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question