SCS-C03 · Domain 4 of 6

SCS-C03 Domain 4: Identity and Access Management

Domain 4 is the largest on SCS-C03. It tests how people, applications and systems prove who they are on AWS and how you grant, limit, troubleshoot and clean up what they can do.

Exam weight
20%
Official task statements
2
Estimated questions estimate
~10
Suggested study time estimate
16–22 hrs

About 11 min read Reviewed October 2026

Overview

Identity and Access Management has two task statements. Task 4.1 covers authentication: designing identity for humans, applications and systems with IAM Identity Center, Amazon Cognito, MFA and external identity providers, issuing temporary credentials with AWS STS and S3 presigned URLs, and troubleshooting sign-in problems using CloudTrail, Cognito, Identity Center permission sets and AWS Directory Service.

Task 4.2 covers authorization: designing controls with Amazon Verified Permissions, IAM paths, IAM Roles Anywhere, cross-account resource policies and role trust policies, building ABAC and RBAC models, writing least-privilege policies with permission boundaries and session policies, analyzing denied requests with the IAM Policy Simulator and IAM Access Analyzer, and removing unintended access.

How it's tested

Domain 4 items describe users, workloads or partner accounts that need access and ask you to design, evaluate or repair it. Expect JSON policy snippets or prose summaries, multi-policy evaluation and questions where the most secure working answer beats the simplest one.

  • Evaluate the request

    Several policies are shown, and you decide whether an action is allowed and which statement or policy type decides the result.

  • Choose the identity pattern

    Workforce users, customers, on-premises servers or partner accounts need access, and you pick Identity Center, Cognito, Roles Anywhere or a cross-account role.

  • Reduce excess access

    Unused or external access exists, and you use Access Analyzer findings, last-accessed data and boundaries to remove it safely.

Reasoning it through

A developer in account A can assume a role in account B, but reading an S3 bucket in account B fails. The role's trust policy works because assumption succeeds. The next checks are the role's identity policy for s3:GetObject, the bucket policy for an explicit deny, a KMS key policy if objects use SSE-KMS, and any SCP or RCP on account B that blocks the call.

Task statements 2

Official task statements from the Amazon Web Services outline, in outline order.

4.1 Design, implement, and troubleshoot authentication strategiesWorkforce, customer and workload identity, temporary credentials and sign-in troubleshooting.
What it means
This task statement covers designing identity solutions for human, application and system authentication with IAM Identity Center, Amazon Cognito, MFA and IdP integration, configuring mechanisms that issue temporary credentials such as AWS STS and S3 presigned URLs, and troubleshooting authentication using CloudTrail, Cognito, Identity Center permission sets and AWS Directory Service.
What to understand
IAM Identity Center is the workforce entry point: connect an external IdP through SAML and SCIM, assign permission sets to accounts and let users get short-lived role credentials. Cognito user pools authenticate customers of your apps, and identity pools exchange those tokens for AWS credentials. STS AssumeRole, AssumeRoleWithSAML and AssumeRoleWithWebIdentity issue temporary keys. Presigned URLs grant time-limited object access using the signer's permissions. Failed sign-ins and AssumeRole errors appear in CloudTrail, often caused by trust policy conditions, MFA requirements or expired SAML assertions.
How it shows up
Expect to choose between Identity Center for employees and Cognito for app users, and to prefer temporary credentials over IAM user keys.
Common confusion
Thinking a presigned URL grants its own permissions; it only carries the signer's permissions and stops working if those are removed.
4.2 Design, implement, and troubleshoot authorization strategiesAuthorization design, ABAC and RBAC, least privilege, denied requests and unintended access.
What it means
This task statement covers designing and evaluating authorization for human, application and system access with Verified Permissions, IAM paths, IAM Roles Anywhere, cross-account resource policies and role trust policies, designing ABAC and RBAC strategies, writing least-privilege IAM policies with permission boundaries and session policies, analyzing failures with the Policy Simulator and IAM Access Analyzer, and correcting unintended permissions.
What to understand
Policy evaluation starts from implicit deny. An explicit deny in any applicable SCP, RCP, resource policy, boundary, session policy or identity policy ends the evaluation. Within one account, an allow in either the identity or the resource policy can be enough; across accounts, both sides must allow. Permission boundaries and session policies only cap permissions and never grant them. ABAC compares principal tags with resource tags so one policy scales as teams grow. Access Analyzer reports external access, unused access and validates policies before deployment.
How it shows up
Look for the policy type that limits rather than grants; many wrong answers add an allow where a boundary, SCP or deny is the actual blocker.
Common confusion
Believing a permission boundary grants access; it only sets the maximum and still needs an identity policy allow.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • Explicit deny wins

    Any matching deny overrides every allow.

    Remember
    Check SCPs, RCPs, boundaries and resource policies for denies.
    Tested as
    Policy evaluation questions.
    Trap
    Adding more allows to fix a deny.

  • Cross-account access

    Needs an allow in the caller's identity policy and the resource or trust policy.

    Remember
    Both sides must agree.
    Tested as
    Multi-account scenarios.
    Trap
    Fixing only one side.

  • Permission boundary

    Managed policy that caps an IAM entity's maximum permissions.

    Remember
    Grants nothing on its own.
    Tested as
    Delegated administration.
    Trap
    Treating it as a grant.

  • Session policy

    Policy passed when assuming a role to narrow that session.

    Remember
    Intersection with role permissions.
    Tested as
    Temporary scoped access.
    Trap
    Expecting it to add permissions.

  • ABAC

    Access based on matching principal and resource tags.

    Remember
    Fewer policies as teams grow.
    Tested as
    Scaling permission design.
    Trap
    Letting users change their own tags.

  • IAM Identity Center

    Central workforce sign-in with permission sets across accounts.

    Remember
    Integrates external IdPs with SAML and SCIM.
    Tested as
    Workforce identity.
    Trap
    Creating IAM users per account.

  • Amazon Cognito

    User pools authenticate app users; identity pools give AWS credentials.

    Remember
    Customer-facing identity.
    Tested as
    App authentication.
    Trap
    Using it for employee console access.

  • IAM Roles Anywhere

    On-premises workloads use X.509 certificates to get temporary AWS credentials.

    Remember
    Removes long-term keys outside AWS.
    Tested as
    Hybrid workload identity.
    Trap
    Storing access keys on servers.

  • IAM Access Analyzer

    Finds external and unused access and validates policies.

    Remember
    Supports policy generation from CloudTrail.
    Tested as
    Least privilege cleanup.
    Trap
    Confusing it with Network Access Analyzer.

  • Amazon Verified Permissions

    Fine-grained authorization for your own apps using Cedar policies.

    Remember
    App-level, not AWS API-level.
    Tested as
    Custom app authorization.
    Trap
    Using IAM policies for in-app permissions.

  • Role trust policy

    Defines who can assume a role, with optional conditions.

    Remember
    Use sts:ExternalId for third parties.
    Tested as
    Confused deputy questions.
    Trap
    Leaving the principal as the whole account without conditions.

  • S3 presigned URL

    Time-limited URL using the signer's credentials.

    Remember
    Expires at the earlier of URL expiry or credential expiry.
    Tested as
    Temporary object sharing.
    Trap
    Making the bucket public instead.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

Policy types in evaluation

ConceptMeaningKey differenceCommon trap
Identity policy Attached to a user, group or role Grants permissions Assuming it alone works cross-account
Resource policy Attached to a resource such as a bucket or key Can grant to other accounts Forgetting the caller also needs an allow
Permission boundary Caps an entity's maximum Never grants Using it to give access
SCP or RCP Organization guardrail on principals or resources Never grants; filters Expecting it to affect the management account
Session policy Narrows a single assumed session Intersects with role permissions Expecting it to widen access

Identity options

ConceptMeaningKey differenceCommon trap
IAM Identity Center Workforce SSO across accounts Permission sets Choosing it for customer apps
Amazon Cognito Customer identity for apps User and identity pools Using it for console access
IAM Roles Anywhere Certificates for workloads outside AWS Temporary credentials Using IAM user keys on servers
Cross-account role Role assumed from another account Trust policy controls who Skipping ExternalId for vendors

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. Allow fixes deny

    What candidates pick
    Attach AdministratorAccess to see if the error goes away.
    Why it looks right
    It quickly proves whether it is a permission issue.
    Why it's wrong
    An explicit deny in an SCP, boundary or resource policy still wins, and granting admin breaks least privilege.

    Clue to watch for The error persists for a user who already has an allow.

  2. One-sided cross-account grant

    What candidates pick
    Add the other account to the bucket policy only.
    Why it looks right
    The bucket now names the account.
    Why it's wrong
    The calling role also needs an identity policy allow for the action and resource; both sides must allow.

    Clue to watch for Principal and resource are in different accounts.

  3. Boundary as a grant

    What candidates pick
    Attach a permission boundary that includes s3:* so the developer can use S3.
    Why it looks right
    The boundary lists the action.
    Why it's wrong
    Boundaries only define a maximum; without an identity policy allow, the request is still implicitly denied.

    Clue to watch for The scenario mentions delegated admins creating roles.

  4. Cognito for employees

    What candidates pick
    Use a Cognito user pool for staff console access.
    Why it looks right
    Cognito handles sign-in.
    Why it's wrong
    Cognito is for application users; workforce access to accounts belongs in IAM Identity Center with the corporate IdP.

    Clue to watch for Employees, accounts and permission sets.

  5. Keys on servers

    What candidates pick
    Create an IAM user and store keys on on-premises servers.
    Why it looks right
    It works immediately.
    Why it's wrong
    Long-term keys leak and need manual rotation; IAM Roles Anywhere issues temporary credentials using existing certificates.

    Clue to watch for Workloads run outside AWS with a PKI.

  6. No ExternalId for vendors

    What candidates pick
    Trust the vendor's account in the role without conditions.
    Why it looks right
    The vendor is trusted.
    Why it's wrong
    Without sts:ExternalId, another customer of the vendor could trick it into accessing your account, the confused deputy problem.

    Clue to watch for A third-party SaaS provider assumes a role.

  7. Ignore the key policy

    What candidates pick
    Grant s3:GetObject and expect encrypted objects to download.
    Why it looks right
    S3 permission is in place.
    Why it's wrong
    SSE-KMS objects also need kms:Decrypt allowed by the key policy and the caller's policy.

    Clue to watch for Objects are encrypted with a customer managed key.

Answer framework

Use these steps for any Domain 4 question that involves granting, evaluating or fixing access.

  1. Identify the principal, the action, the resource and whether they sit in the same account or different accounts.
  2. List every policy type that applies: identity, resource, trust, boundary, session, SCP, RCP and KMS key policy that could affect the request.
  3. Look for an explicit deny first, since one deny anywhere decides the result regardless of allows elsewhere in the chain.
  4. Confirm that an allow exists where required, and on both sides of the request when the resource is in another account.
  5. Pick the fix that grants the narrowest access, using roles, temporary credentials, tags and Access Analyzer instead of broad allows or keys.

Practice question

A company's security team lets developers create IAM roles for Lambda functions but must stop developers from giving any role more permissions than the developers have. Developers must not be able to remove the restriction. Which approach meets this requirement?

Want more like this? The SCS-C03 practice test has questions for every domain.

Checklist

0 of 13

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Start with policy evaluation, because it underlies most of the ten or so questions in this domain. Draw the evaluation flow once from memory: explicit deny, organization policies, resource policy, identity policy, boundary, session policy. Then work through at least twenty small policy puzzles by hand, deciding allow or deny and naming the statement that decides it.

Next, build the identity patterns in a sandbox. Set up IAM Identity Center with a permission set, assume a cross-account role with an ExternalId condition, create a presigned URL and watch it fail after you remove the signer's permission. Try an ABAC policy using a team tag on both a role and an S3 bucket.

Then practice least privilege. Use IAM Access Analyzer to find a bucket shared outside your organization, generate a policy from CloudTrail activity and review unused access findings. Read about Verified Permissions and Roles Anywhere so you can explain where each fits. Finish with timed questions and, for every wrong answer, write down which policy type you overlooked.

FAQ

How much of SCS-C03 is Domain 4?

Identity and Access Management is 20% of scored content, about ten of the fifty scored questions, the largest share of any SCS-C03 domain. It has two task statements.

Did the IAM weight change from SCS-C02?

Yes. It rose from 16% in SCS-C02 to 20% in SCS-C03, according to the official comparison appendix in the exam guide.

Do I still need to know policy elements such as Principal and Condition?

The appendix removed policy components as a separate item, but you still need them to design, interpret and troubleshoot policies under skills 4.2.3 and 4.2.4.

What is the difference between an SCP and an RCP?

An SCP limits what principals in member accounts can do. An RCP limits what can be done to resources in member accounts, including by external principals. Neither grants permissions.

When should I use Verified Permissions instead of IAM?

Use Verified Permissions for authorization inside your own application, such as which user can view which record. IAM controls access to AWS APIs and resources.

How do I find who has unintended access?

Use IAM Access Analyzer for external and unused access findings, last-accessed data to trim permissions, and policy validation before deploying changes.

Other Cybersecurity certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 4 knowledge

You have covered authentication, temporary credentials, policy evaluation, ABAC, boundaries and access cleanup. Check whether you can call allow or deny quickly and correctly.

Take the SCS-C03 practice test Check your SCS-C03 readiness

Keep going