mediumMultiple Choice

ISC2 CC Explicit Allow Practice Question

Exhibit

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::company-bucket/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "10.0.0.0/16"
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": "10.0.0.0/16"
        }
      }
    }
  ]
}

Refer to the exhibit. A security engineer applies this storage access policy to restrict access. Users outside the 10.0.0.0/16 network report being denied access, which is expected. However, users inside that network also report access denied. What is the likely issue?

⚠ Common exam trap

ISC2 often tests the misconception that a single Allow statement for one action (like read) implicitly permits all other actions for users who satisfy the condition, when in reality each action requires its own explicit Allow.

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 policy only allows read access; users likely need list or other actions.

The storage policy only grants the read action, but users inside the 10.0.0.0/16 network are likely performing other actions such as list or write. Even though the source IP condition allows access from the trusted network, the explicit Allow statement is scoped solely to read. Any request for a different action (like list) will be implicitly denied by default, as IAM and storage policies are deny-by-default unless an explicit Allow exists for that specific action.

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 condition syntax is incorrect and causes all requests to be evaluated incorrectly.
Why it's wrong here
A syntax error would produce a policy evaluation failure or deployment rejection, not selective denial affecting only in-range addresses while out-of-range users are denied as designed. Syntax faults are tempting to blame first, but the symptom's asymmetry points to a condition operator or value mismatch.
✗
The Deny statement overrides the Allow statement for all requests.
Why it's wrong here
An unconditional Deny would deny out-of-range users (as observed) but also in-range users, which matches the symptom only if the Allow never applies — yet the stem's exhibit shows a conditional Allow. Deny precedence is tempting because it genuinely overrides Allow in policy evaluation.
✓
The policy only allows read access; users likely need list or other actions.
Why this is correct
The storage policy only grants the read action, but users inside the 10.0.0.0/16 network are likely performing other actions such as list or write. Even though the source IP condition allows access from the trusted network, the explicit Allow statement is scoped solely to read. Any request for a different action (like list) will be implicitly denied by default, as IAM and storage policies are deny-by-default unless an explicit Allow exists for that specific action.
✗
The resource identifier includes a wildcard, causing a mismatch.
Why it's wrong here
A wildcard in the resource identifier would affect every request regardless of source IP, yet out-of-range users are correctly denied and in-range users wrongly denied — an address-scoping fault, not a resource mismatch. Wildcards are tempting because resource scoping errors do cause blanket denials.

Go deeper

ISC2 CC Explicit Allow Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question