Bird
Raised Fist0
AWScloud~5 mins

Policy evaluation logic in AWS - Commands & Configuration

Choose your learning style10 modes available
LearnWhyDeepVisualTryChallengeProjectRecallTime

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Introduction
When you want to control who can do what in your cloud, you use policies. Policy evaluation logic decides if a user is allowed or denied an action based on these policies.
When you want to allow a user to read files from a storage bucket but not delete them
When you want to deny access to a service during certain hours
When you want to combine multiple policies to decide if an action is allowed
When you want to understand why a user was denied access
When you want to test if a policy change will allow or deny an action before applying it
Commands
This command tests if the user 'example-user' is allowed to perform the 's3:GetObject' action according to their policies.
Terminal
aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::123456789012:user/example-user --action-names s3:GetObject
Expected OutputExpected
{ "EvaluationResults": [ { "EvalActionName": "s3:GetObject", "EvalResourceName": "*", "EvalDecision": "allowed", "MatchedStatements": [ { "SourcePolicyId": "policy1", "StartPosition": { "Line": 3, "Column": 5 }, "EndPosition": { "Line": 10, "Column": 6 } } ], "MissingContextValues": [] } ] }
→
--policy-source-arn - Specifies the user or role ARN whose policies are evaluated
→
--action-names - Specifies the AWS action to test
This command tests a custom policy defined in 'policy.json' to see if it allows the 's3:DeleteObject' action.
Terminal
aws iam simulate-custom-policy --policy-input-list file://policy.json --action-names s3:DeleteObject
Expected OutputExpected
{ "EvaluationResults": [ { "EvalActionName": "s3:DeleteObject", "EvalResourceName": "*", "EvalDecision": "explicitDeny", "MatchedStatements": [ { "SourcePolicyId": "customPolicy", "StartPosition": { "Line": 5, "Column": 7 }, "EndPosition": { "Line": 12, "Column": 8 } } ], "MissingContextValues": [] } ] }
→
--policy-input-list - Specifies the JSON file containing the custom policy
→
--action-names - Specifies the AWS action to test
Key Concept

If you remember nothing else from this pattern, remember: AWS evaluates all policies together and denies access if any policy explicitly denies the action.

Common Mistakes
Testing a policy without specifying the correct action name
The evaluation will not check the intended action and may give misleading results
Always specify the exact AWS action you want to test with --action-names
Assuming that absence of an allow means allow
AWS denies by default if no policy explicitly allows the action
Understand that explicit allow is required; absence of allow means deny
Ignoring explicit deny statements in policies
Explicit deny always overrides allow, causing access to be denied
Check for explicit deny statements carefully when troubleshooting access
Summary
Use 'aws iam simulate-principal-policy' to test user or role permissions for specific actions.
Use 'aws iam simulate-custom-policy' to test standalone policies before applying them.
Remember that explicit deny in any policy overrides all allows during evaluation.

Practice

(1/5)
1. What happens if an AWS IAM policy has both an explicit Allow and an explicit Deny for the same action?
easy
A. The explicit Deny always overrides the Allow.
B. The Allow always overrides the Deny.
C. The action is allowed only if the user is an administrator.
D. The action is denied only if there is a condition attached.

Solution

  1. Step 1: Understand explicit Deny effect

    In AWS IAM, an explicit Deny always takes priority over any Allow for the same action.

  2. Step 2: Apply policy evaluation logic

    Even if a policy allows an action, if another policy explicitly denies it, the Deny wins and the action is blocked.

  3. Final Answer:

    The explicit Deny always overrides the Allow. -> Option A

  4. Quick Check:

    Explicit Deny > Allow [OK]
Hint: Remember: Deny always beats Allow in AWS policies [OK]
Common Mistakes:
  • Thinking Allow can override Deny
  • Ignoring explicit Deny effect
  • Assuming conditions affect Deny priority
2. Which of the following is the correct JSON syntax to allow the s3:ListBucket action on a bucket named my-bucket?
easy
A. {\"Effect\": \"Deny\", \"Action\": \"s3:ListBucket\", \"Resource\": \"arn:aws:s3:::my-bucket\"}
B. {\"Effect\": \"Allow\", \"Action\": [\"s3:ListBucket\"], \"Resource\": \"arn:aws:s3:::my-bucket\"}
C. {\"Effect\": \"Allow\", \"Action\": \"s3:ListBucket\", \"Resource\": \"my-bucket\"}
D. {\"Effect\": \"Allow\", \"Action\": \"ListBucket\", \"Resource\": \"arn:aws:s3:::my-bucket\"}

Solution

  1. Step 1: Check Action format

    The Action field must be a string or an array of strings. Using an array is valid and recommended for multiple actions.

  2. Step 2: Verify Resource ARN format

    The Resource must be the full ARN: arn:aws:s3:::my-bucket for the bucket itself.

  3. Final Answer:

    Action as array and correct ARN Resource -> Option B

  4. Quick Check:

    Action array + correct ARN = D [OK]
Hint: Use full ARN and array for actions to avoid syntax errors [OK]
Common Mistakes:
  • Using bucket name instead of ARN in Resource
  • Omitting array brackets for multiple actions
  • Using action name without service prefix
3. Given this policy snippet:
{
  "Effect": "Allow",
  "Action": "ec2:StartInstances",
  "Resource": "*",
  "Condition": {
    "IpAddress": {"aws:SourceIp": "203.0.113.0/24"}
  }
}

What happens if a user tries to start an EC2 instance from IP 198.51.100.10?
medium
A. The action is denied because the IP does not match the condition.
B. The action is allowed because the Effect is Allow.
C. The action is allowed only if the user has another policy allowing it.
D. The action is denied only if there is an explicit Deny policy.

Solution

  1. Step 1: Understand Condition effect

    The policy allows the action only if the request comes from IPs in 203.0.113.0/24 range.

  2. Step 2: Check IP address

    The user's IP 198.51.100.10 is outside the allowed range, so the condition fails.

  3. Final Answer:

    The action is denied because the IP does not match the condition. -> Option A

  4. Quick Check:

    Condition IP mismatch = Deny [OK]
Hint: Conditions restrict Allow; mismatch means Deny [OK]
Common Mistakes:
  • Ignoring condition and assuming Allow always works
  • Confusing explicit Deny with condition-based Deny
  • Assuming multiple policies needed to allow
4. You have two policies attached to a user:
Policy 1: Allows s3:GetObject on bucket my-bucket.
Policy 2: Denies s3:GetObject on bucket my-bucket if the request is from outside office IP range.

The user tries to get an object from home IP. What is the result?
medium
A. The request is allowed because Policy 1 allows it.
B. The request is allowed only if the user is in the admin group.
C. The request is denied only if there is a service outage.
D. The request is denied because Policy 2 explicitly denies it from outside IPs.

Solution

  1. Step 1: Identify explicit Deny with condition

    Policy 2 denies the action if the IP is outside the office range, which applies here.

  2. Step 2: Apply evaluation logic

    Explicit Deny overrides any Allow, so the request is denied.

  3. Final Answer:

    The request is denied because Policy 2 explicitly denies it from outside IPs. -> Option D

  4. Quick Check:

    Explicit Deny with condition blocks request [OK]
Hint: Explicit Deny with condition beats Allow always [OK]
Common Mistakes:
  • Ignoring condition in Deny policy
  • Assuming Allow always wins
  • Thinking user group affects Deny priority
5. You want to create a policy that allows ec2:StopInstances only during business hours (9 AM to 5 PM UTC) and denies it otherwise. Which policy logic correctly enforces this?
hard
A. Only use Deny with condition outside 9-17 UTC, no Allow needed.
B. Allow ec2:StopInstances with condition "DateGreaterThan": {"aws:CurrentTime": "09:00:00Z"}, no Deny needed.
C. Allow ec2:StopInstances unconditionally, and add a Deny with condition outside 9-17 UTC.
D. Allow ec2:StopInstances with condition for 9-17 UTC, and Deny unconditionally.

Solution

  1. Step 1: Understand Deny override with time condition

    Unconditional Allow permits ec2:StopInstances, but explicit Deny applies outside 9-17 UTC overriding the Allow.

  2. Step 2: Verify business hours enforcement

    During 9 AM-5 PM UTC: Deny condition false -> action allowed. Outside: Deny true -> denied.

  3. Final Answer:

    Allow unconditionally, and add a Deny with condition outside 9-17 UTC. -> Option C

  4. Quick Check:

    Allow + Deny conditions enforce time limits [OK]
Hint: Unconditional Allow + conditional Deny outside business hours [OK]
Common Mistakes:
  • Relying only on Allow conditions without Deny
  • Using unconditional Deny that blocks all
  • Missing time range in conditions