Conditions, Wildcards, and Policy Variables

Beyond action and resource, IAM offers powerful tools to make policies precise and dynamic: conditions, wildcards, and policy variables. Mastering these lets you grant exactly the access needed under exactly the right circumstances, which is the essence of least privilege and a recurring exam theme.

A Condition block contains one or more tests that must all be true for the statement to apply. Each test pairs an operator with a condition key and a value, for example StringEquals on aws:PrincipalTag. Multiple keys in one block are ANDed together; multiple values for one key are ORed.

Global condition keys appear constantly on the exam:

• aws:SourceIp — restrict by caller IP range.
• aws:SecureTransport — require TLS.
• aws:MultiFactorAuthPresent — require MFA.
• aws:PrincipalOrgID — restrict to your organization.

Service-specific keys (like s3:prefix) add even finer control.

A classic pattern denies access unless the request uses TLS. This bucket-policy condition blocks any non-HTTPS call, ensuring data in transit is always encrypted. The exam loves this as the answer to "require encryption in transit for S3."

Operators define how values are compared: StringEquals, StringLike (supports wildcards), IpAddress, DateGreaterThan, Bool, and Null among others. Adding IfExists to an operator makes it pass when the key is absent. Choosing the right operator is essential to get the intended logic.

Wildcards (* for any sequence, ? for one character) make policies concise but can over-grant. s3:Get* covers all read-style operations; s3:* covers everything in S3. Use the narrowest wildcard that meets the need, and be suspicious of broad wildcards in any policy you review.

Resource ARNs also accept wildcards, for example arn:aws:s3:::logs/2024/* to scope to one prefix. This lets a policy target a folder or pattern without listing every object. But a Resource of just "*" grants account-wide reach, so always question whether such breadth is truly required.

Policy variables insert request context at evaluation time using the syntax ${...}. The most useful is ${aws:username}, letting one policy give each user access only to their own resources. Variables make a single reusable policy behave differently per principal, scaling least privilege elegantly.

This statement lets each user manage only objects under a folder named after their username, a powerful one-policy-for-everyone pattern.

Attribute-Based Access Control (ABAC) uses tags in conditions, comparing the principal's tags (aws:PrincipalTag) to a resource's tags (aws:ResourceTag). When they match, access is granted. ABAC scales beautifully: you grant access by tag rather than writing a new policy for every project, a modern best practice the exam highlights.

Combine these tools deliberately: use conditions to gate access on MFA, IP, TLS, or org membership; use wildcards sparingly and narrowly; use policy variables and tags for scalable, per-principal least privilege. Together they let one well-crafted policy enforce precise, context-aware access across many identities and resources.

Test conditions and variables.

Conditions gate statements on context keys (aws:SourceIp, aws:SecureTransport, aws:MultiFactorAuthPresent, aws:PrincipalOrgID) using operators like StringLike and Bool. Wildcards (* and ?) keep policies concise but can over-grant. Policy variables like ${aws:username} and tag-based ABAC deliver scalable, per-principal least privilege.