SCS-C02 Security Logging and Monitoring Practice Question

Exhibit

User: admin
  Groups: Administrators
  Policies:
    - AdministratorAccess (attached via group)
    - AllowSSH (inline policy)

Inline policy document for AllowSSH:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:DescribeInstances",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "ec2:DescribeSecurityGroups",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "ssm:StartSession",
      "Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/SSH": "enabled"
        }
      }
    }
  ]
}

Refer to the exhibit. A security engineer reviews IAM permissions for the 'admin' user. The user is a member of the 'Administrators' group, which has the 'AdministratorAccess' managed policy attached. Additionally, the user has an inline policy named 'AllowSSH'. The engineer wants to ensure that the user can only start SSM sessions on instances with the tag 'SSH: enabled'. However, the user can still start sessions on any instance. What is the most likely reason?

⚠ Common exam trap

SCS-C02 often tests the misconception that a more specific Allow policy can restrict a broader Allow — in IAM, only an explicit Deny can override an Allow, so candidates who pick 'policy precedence' answers fall for this trap.

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 inline policy uses 'Allow' instead of 'Deny' for instances without the tag, so it does not restrict access.

In AWS IAM, an explicit Allow in any attached policy grants access — there is no 'most restrictive wins' rule for Allow statements. Because the user already has AdministratorAccess (which allows ssm:StartSession on *), the inline AllowSSH policy's Allow statement cannot restrict anything; it only adds permissions. To restrict the user to tagged instances, the inline policy must contain an explicit Deny for ssm:StartSession when the resource tag condition is not met (or the AdministratorAccess policy must be removed/scoped).

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 inline policy does not include 'ec2:DescribeInstances' for the SSM session, so it cannot start sessions.
Why it's wrong here
The inline policy already grants ec2:DescribeInstances alongside ssm:StartSession, so the required read action for Session Manager is present. Even if it were absent, the group's AdministratorAccess policy would provide ec2:DescribeInstances and all other needed actions, so the inability to start sessions is not caused by a missing action here. The actual problem is that the inline Allow statement is conditional while the group policy grants an unconditional Allow, meaning the effective permissions still include instances without the relevant tag.
✗
The condition 'aws:ResourceTag/SSH' should be 'aws:RequestTag/SSH' to check the request tag.
Why it's wrong here
aws:ResourceTag is evaluated against tags on the instance that is the target resource of the session, which is exactly the check needed to restrict StartSession to instances labeled SSH. aws:RequestTag refers to tags supplied in the request itself, and ssm:StartSession does not accept or require an SSH tag parameter, so changing the condition to RequestTag would make the condition meaningless. Keeping ResourceTag is correct; it simply must be paired with a Deny effect to block untagged instances when an unconditional Allow also exists.
✓
The inline policy uses 'Allow' instead of 'Deny' for instances without the tag, so it does not restrict access.
Why this is correct
The inline policy allows SSM StartSession only on tagged instances, but since the group policy allows all actions, the effective permission is still 'Allow' on all instances. To restrict, a 'Deny' statement is needed for instances without the tag.
✗
The inline policy 'AllowSSH' is not effective because it is overridden by the group policy 'AdministratorAccess'.
Why it's wrong here
AdministratorAccess does not override the inline policy; IAM combines all applicable Allow and Deny statements from the group and user. Because the group policy is an unconditional Allow for all actions, the inline policy's conditional Allow only adds a narrower grant, which is moot when a broader Allow already exists. An explicit Deny for untagged instances would be required to restrict access, since no Deny overrides the group's wide-open Allow.

Go deeper

SCS-C02 Security Logging and Monitoring Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question