AWS Certified Security – Specialty SCS-C03 IAM Pitfalls: Least Privilege Patterns and Policy Misreads to Avoid

AWS IAM questions in the AWS Certified Security – Specialty SCS-C03 exam often look simple at first. Then you read the policy twice and realize the real issue is not syntax. It is evaluation logic, hidden deny paths, or a bad mental model of how permissions are actually granted. That is why IAM trips up so many candidates and practitioners. Least privilege in AWS is not just “make the policy smaller.” It means knowing which policy type applies, how multiple policies combine, and where a request can fail even when an allow statement seems correct. This article focuses on the IAM pitfalls that matter most for the exam and for real-world AWS environments: permission boundaries, when to use roles instead of users, common policy mistakes, and how to reason through scenario questions without guessing.

Why IAM feels harder than it should

IAM is hard because AWS authorization is layered. A request is not approved just because one identity policy says Allow. AWS evaluates several controls together:

• Identity-based policies

• Resource-based policies

• Permissions boundaries

• Service control policies (SCPs) in AWS Organizations

• Session policies, if temporary credentials are used

• Explicit denies anywhere in the chain

The exam likes to test this by showing a policy that looks permissive, then hiding the real blocker in a boundary, SCP, or condition key. The safest approach is to remember one rule: effective permissions are the result of intersection and override, not just addition. Some policy types add options. Others limit them. And explicit deny beats allow.

If you keep that logic in mind, many confusing questions become easier.

Least privilege is not about tiny policies

Least privilege means granting only the actions, resources, and conditions needed for a task. But in AWS, people often get this wrong in two opposite ways.

• They grant broad access with Action: “*” or Resource: “*” because they want things to work quickly.

• They write a very narrow policy, but forget dependent actions, required resource types, or service-specific limitations. Then the workflow breaks.

A better pattern is task-based design. Start with the actual task. For example, if a developer only needs to read logs from a specific log group, grant read actions for CloudWatch Logs on that resource. Do not attach CloudWatchLogsFullAccess or broad read access to all logs in the account.

The “why” matters here. Broad permissions increase blast radius. If credentials are misused, the attacker gets everything the principal can reach. Narrow task-based permissions reduce damage and make review easier.

On the exam, least privilege questions often test whether you notice when an answer is secure and still functional. A policy that is too strict to support the use case is not the best answer. A policy that works but grants broad access is also not the best answer.

Permission boundaries: the mental model many people miss

Permission boundaries are one of the most misunderstood IAM features. A boundary does not grant permissions by itself. It sets the maximum permissions an IAM user or role can receive from its identity-based policies.

Think of it this way:

• Identity policy = what the principal is allowed to do

• Permissions boundary = ceiling on those allowed actions

The effective permissions are the overlap between the identity policy and the boundary.

Example:

• The role policy allows s3:* on a bucket

• The permissions boundary allows only s3:GetObject

Result: the role can only get objects. It cannot delete, put, or list beyond what the boundary allows.

This matters because many people assume a boundary works like a regular allow policy. It does not. If the identity policy does not allow an action, the boundary cannot add it. If the boundary does not allow an action, the identity policy cannot push past it.

A common real-world use case is delegated administration. Suppose your platform team lets application teams create roles for their own workloads. Without a boundary, those teams might create highly privileged roles by mistake or on purpose. With a boundary attached to any role they create, the platform team can say, in effect, “you may create roles, but those roles can never exceed this maximum scope.”

That is why permission boundaries show up on the exam. They are ideal for controlled delegation.

One subtle pitfall: a resource-based policy can sometimes allow access in ways people do not expect when they only think about the identity policy. The exam may test whether you understand which policy types apply to the principal and which apply to the resource. Do not reduce every scenario to “check the IAM policy only.”

Roles vs users: choose based on credential behavior

AWS wants you to prefer roles over IAM users in many cases, and for good reason. The core difference is not just “roles are modern.” It is that roles use temporary credentials. That changes risk.

Use an IAM role when:

• An AWS service needs permissions, such as EC2, Lambda, or ECS

• A human needs access through federation or AWS IAM Identity Center

• Cross-account access is needed

• You want short-lived credentials instead of long-term access keys

Use an IAM user only when you truly need a long-term identity inside one account and cannot use federation or role assumption for that use case.

The security reason is simple. Long-term access keys are easier to leak, forget, and misuse. Temporary credentials expire. That reduces exposure and supports better operational control.

Exam questions often frame this as a design choice. For example:

• An EC2 instance needs access to S3. Best answer: attach an instance profile role, not hard-coded access keys.

• A third-party auditor needs short-term read-only access to one account. Best answer: create a cross-account role with external ID if appropriate, not an IAM user with permanent credentials.

• Employees need console access across accounts. Best answer: federation or IAM Identity Center, not separate IAM users in each account.

If a question asks for the most secure and operationally simple option, roles usually win.

Common IAM policy mistakes that cause misreads

The exam often uses small policy details to separate a correct answer from a wrong one. These are the mistakes to watch closely.

Confusing explicit deny with implicit deny

Implicit deny means access is denied because nothing allows it. Explicit deny means a policy directly says deny. Explicit deny always wins, even if another policy allows the request.

Why this matters: if you see a deny statement in an SCP, identity policy, resource policy, or boundary, treat it as the likely deciding factor.

Using wildcards too broadly

Action: “*” and Resource: “*” are the classic least-privilege failure. But the deeper problem is not just broadness. It is loss of control. You cannot reason clearly about what is allowed when everything is allowed.

Better pattern:

• Specify only required actions

• Scope to the exact resource ARN when the service supports it

• Use conditions to narrow access further, such as source VPC endpoint, MFA present, or requested region

Forgetting that some actions do not support resource-level permissions

Not every AWS action can be restricted to a specific ARN. Some require Resource: “*”. Candidates often assume they can always narrow by resource. The exam may give an answer that looks stricter but is invalid or ineffective for the action in question.

This is why service authorization details matter. Least privilege is service-aware, not generic.

Missing condition logic

Conditions are where many policies become powerful and many readers get lost. A policy might allow an action only if:

• MFA is used

• The request comes from a certain IP range

• A tag matches a required value

• The principal belongs to a specific AWS account or organization

The exam may hide the answer in one condition key. Read them slowly. A single condition can narrow a broad action into acceptable least privilege, or it can block access that otherwise looks allowed.

Not understanding principal vs resource scope

Identity-based policies are attached to users, groups, or roles. Resource-based policies are attached to resources like S3 buckets, KMS keys, or SNS topics. In cross-account access, you often need both sides to line up correctly.

Common mistake: granting a user permission to access a bucket in another account but forgetting the bucket policy must also trust that principal, depending on the setup.

When a scenario involves two accounts, stop and ask:

• Who is the principal?

• Which account owns the resource?

• Which policy types must permit the action?

Overlooking role trust policies

A role has two policy dimensions:

• The trust policy, which defines who can assume the role

• The permissions policy, which defines what the role can do after assumption

People often focus only on the permissions policy. But if the trust policy is wrong, the role cannot be assumed, or worse, can be assumed by an unintended principal.

On the exam, if the problem is “the application cannot assume the role,” inspect the trust relationship first.

Scenario decision practice: how to reason like the exam expects

SCS-C03 questions are often easier when you use a fixed decision process instead of reading for intuition.

Try this sequence:

1. Identify the principal. Is it a user, role, service, federated identity, or external account?

2. Identify the resource. Is there a resource-based policy involved?

3. List the policy layers in play: identity policy, trust policy, boundary, SCP, session policy, resource policy.

4. Look for explicit deny first.

5. Check whether the requested action supports the resource scope shown.

6. Check conditions and tags.

7. Choose the answer that is both secure and operationally correct.

Here are a few short examples.

Scenario 1: A developer needs to launch EC2 instances only with approved tags and only in one region.

Best direction: allow the necessary EC2 actions with conditions on aws:RequestedRegion and tag-related condition keys. This is better than broad EC2 access plus manual review, because the policy enforces the control at request time.

Scenario 2: A team can create roles for applications, but security wants to prevent admin-level roles.

Best direction: delegated role creation with a permissions boundary. This preserves team autonomy while capping risk.

Scenario 3: A Lambda function needs access to a DynamoDB table.

Best direction: assign an execution role with only the needed DynamoDB actions on that table. Do not store access keys in environment variables. The role gives temporary credentials and a smaller blast radius.

Scenario 4: An identity policy allows S3 read access, but access still fails.

Likely next checks: bucket policy, SCP, permissions boundary, VPC endpoint policy, or condition mismatch. The exam often tests whether you know an allow in one place is not enough.

If you want more question practice in this style, the AWS Certified Security Specialty SCS-C03 practice test can help you get used to IAM wording and scenario traps.

Practical least privilege patterns worth remembering

These patterns show up often because they balance security with usability.

• Use roles for workloads. EC2, Lambda, ECS, and other services should assume roles instead of using stored access keys.

• Use federation for humans. Central identity plus temporary AWS access is cleaner and safer than many IAM users.

• Constrain by resource where possible. Use specific ARNs instead of account-wide access.

• Constrain by condition. MFA, source network, region, tags, and organization ID can sharply reduce risk.

• Use permissions boundaries for delegation. They are guardrails, not grants.

• Review trust policies separately. A perfectly scoped role is still dangerous if the wrong principal can assume it.

• Be careful with managed policies. They are convenient, but often broader than needed.

IAM pitfalls checklist

Use this quick checklist when reviewing a scenario or a real policy:

• Did I identify the principal correctly?

• Is this better solved with a role instead of an IAM user?

• Does any policy contain an explicit deny?

• Are SCPs, permissions boundaries, or session policies limiting access?

• Is a resource-based policy also required?

• Does the action support resource-level restriction, or must it use Resource: “*”?

• Are conditions narrowing access correctly?

• Is the trust policy for the role correct?

• Are wildcards broader than the use case requires?

• Does the design use temporary credentials whenever possible?

Final takeaway

The biggest IAM mistake on the SCS-C03 exam is reading policies as isolated text blocks. AWS does not evaluate them that way. You need to think in layers: who is making the request, what policy types apply, what sets the maximum, and where an explicit deny or condition changes the result. Least privilege is not just about removing permissions. It is about granting the smallest workable set with the right policy type and the right guardrails. If you build that mental model now, IAM questions become less about memorizing syntax and more about understanding how AWS authorization really works.