4.2 - Design, implement and troubleshoot authorization (identity and resource policies, ABAC, permissions boundaries, Access Denied)
AWS Certified Security Specialty objective 4.2 covers granting exactly the right permissions and diagnosing the refusals that follow. Everything starts with policy evaluation: an explicit Deny anywhere always wins, a Service Control Policy and a permissions boundary only cap what an identity policy may grant and never grant anything themselves, and a cross-account call needs an Allow on both the resource policy and the caller's identity policy. You attach a permissions boundary so a team leader can create roles that can never exceed read-only, scope a session down further with a session policy at AssumeRole time, and express attribute-based access control with aws:ResourceTag, aws:RequestTag and aws:TagKeys so engineers manage only the instances tagged for their team. Resource policies are narrowed with aws:PrincipalOrgID, aws:PrincipalOrgPaths, s3:prefix and aws:SourceVpce, while KMS access needs its own path: the key policy decides, kms:ViaService restricts use to one service, and a grant lends temporary revocable permission without editing the key policy. Troubleshooting means decoding an encoded authorization failure message, reading policy variables such as the user name, and running the policy simulator, IAM Access Analyzer and last accessed data. Expect Access Denied scenarios and questions on which control expresses a rule.
Permissions boundary or SCP allows s3:* but the identity policy allows nothing = the principal can do nothing, a cap never grants. Admin role fails on an encrypted resource = the KMS key policy does not allow it. Encoded authorization failure message = decode it with sts decode-authorization-message.
Practice questions
1. An IAM identity policy grants s3:GetObject on a bucket, but the bucket policy explicitly denies the same action for that principal. What is the result when the principal calls GetObject?
- Access is allowed, because identity policies take precedence over resource policies
- Access is allowed, because the two policies are evaluated independently and one allows it
- Access is denied (correct answer)
- Access depends on which policy was attached most recently
An explicit Deny anywhere in policy evaluation always wins, whatever the source. There is no precedence of identity over resource policies: AWS unions all applicable policies, and a single explicit Deny overrides every Allow. Attachment order is never considered.
2. A Service Control Policy attached to an organizational unit denies ec2:RunInstances outside eu-west-1. An account in that OU has an administrator with the AdministratorAccess policy. What can that administrator do?
- Launch instances in any region, since AdministratorAccess grants full access
- Launch instances anywhere after detaching the SCP from within the member account
- Launch instances in any region, because SCPs only apply to IAM users and not to roles
- Launch instances only in eu-west-1 (correct answer)
An SCP sets the maximum available permissions for an account: it never grants anything, it only caps. AdministratorAccess cannot exceed that cap, SCPs are managed from the management account and cannot be detached from inside a member account, and they apply to every principal in the account including roles. The root user of a member account is bound by them too.
3. You want an IAM policy to apply only when the caller signed in with multi factor authentication. Which condition key expresses this?
- aws:SecureTransport
- aws:MultiFactorAuthPresent (correct answer)
- aws:PrincipalServiceNamesList
- aws:TokenIssueTime
aws:MultiFactorAuthPresent is true when the request was signed with credentials obtained through MFA. aws:SecureTransport only tells whether TLS was used, aws:PrincipalServiceNamesList lists the service principals behind a call, and aws:TokenIssueTime gives the age of the temporary credentials rather than how they were obtained.
4. A developer must be able to pass a role to an EC2 instance but must not be able to attach any role they like. Which permission controls this?
- ec2:AssociateIamInstanceProfile alone, with no other restriction
- sts:AssumeRole on every role in the account
- iam:CreateRole limited by a permissions boundary
- iam:PassRole scoped to specific role ARNs (correct answer)
iam:PassRole is the guard that decides which roles a principal may hand to a service, and restricting its Resource to specific ARNs is what prevents privilege escalation. Associating a profile without a PassRole limit would let the developer attach an administrator role, AssumeRole is about assuming a role themselves, and CreateRole concerns creating roles rather than passing them.
5. A team leader may create IAM roles for their squad, but no role they create should ever exceed read only access. Which feature enforces that ceiling?
- A permissions boundary required on every role they create (correct answer)
- A Service Control Policy applied to the whole organization
- An IAM group containing the roles, with a read only policy attached to the group
- A session policy passed at the time each role is assumed
A permissions boundary caps what a created identity can ever do, and the creator can be forced to attach one via a condition on iam:PermissionsBoundary. An SCP would cap the entire account rather than just this team's roles, IAM groups cannot contain roles at all, and session policies apply only to one session and cannot be imposed at creation time.
6. You need to grant a Lambda function access to exactly one DynamoDB table, with no possibility of reaching others. Where should the restriction live?
- In the function's environment variables, which name the allowed table and are read at startup
- In application code that checks the table name before every call and logs any mismatch
- In the Resource element of the execution role policy, naming the table ARN (correct answer)
- In a VPC endpoint policy attached to the subnet where the function runs its network calls
Only the IAM policy is enforced by AWS itself, so scoping Resource to the table ARN makes any other call fail regardless of what the code does. Environment variables and application checks are advisory and fall away the moment the code is changed or compromised, and endpoint policies are attached to the endpoint rather than to a subnet.