AWS SCS-C03: Identity and Access Management

Topic snapshot

Sample questions

These original IT Mastery practice questions are aligned to this topic area. Use them for self-assessment, scope review, and deciding what to drill next.

Question 1

Topic: Identity and Access Management

A CI pipeline successfully assumes DeploymentRole in a production account. The next API call fails with AccessDenied for cloudformation:CreateChangeSet. A security engineer verifies the following:

The CI job passes this session policy when calling AssumeRole:

{
  "Effect": "Allow",
  "Action": ["cloudformation:Describe*"],
  "Resource": "*"
}

Which change should correct the failure while preserving least privilege?

Options:

• A. Attach another identity policy that allows cloudformation:*

• B. Remove the permissions boundary from DeploymentRole

• C. Add cloudformation:CreateChangeSet to the session policy for the required resources

• D. Add the CI principal again to the role trust policy

Best answer: C

Explanation: For an assumed role session, AWS evaluates the effective permissions as the intersection of several policy layers, including the role identity policy, permissions boundary, applicable SCPs, and any session policy passed to AWS STS. In this scenario, the role assumption already succeeded, so the trust policy is not the cause. The identity policy, boundary, and SCP are also not blocking the action. The session policy only allows cloudformation:Describe*, so it down-scopes the temporary credentials and omits cloudformation:CreateChangeSet. The least-privilege correction is to add only the required action and resources to the session policy, rather than broadening unrelated layers.

• Trust policy change fails because AssumeRole already succeeded, so authentication into the role is not the failing layer.
• Broader identity policy fails because an additional allow cannot overcome a restrictive session policy intersection.
• Removing the boundary fails because the boundary already permits the action and removing it unnecessarily weakens guardrails.

Question 2

Topic: Identity and Access Management

A security team is reviewing authentication for a new customer-facing mobile application.

Audit note:

Users: external customers, not employees
Needs: self-service sign-up, sign-in, password reset, MFA
Federation: social identity providers
Tokens: OIDC-compatible tokens for application APIs
AWS access: no console access or long-lived AWS credentials

Which next action is best supported by this evidence?

Options:

• A. Configure AWS STS AssumeRole for customers

• B. Create IAM users for each customer

• C. Create an Amazon Cognito user pool

• D. Use IAM Identity Center permission sets

Best answer: C

Explanation: Amazon Cognito is appropriate when an application needs to authenticate external application users, especially with self-service registration, password recovery, MFA, and federation to social or enterprise identity providers. A Cognito user pool can act as the user directory and issue standards-based tokens that the application or API layer can validate. The audit note specifically excludes employee workforce access and direct AWS console access, so workforce identity and AWS permission-management services are not the primary fit. The key distinction is application user authentication, not granting AWS account access.

• IAM users are not appropriate for large-scale customer identities and would create unnecessary AWS principals.
• IAM Identity Center fits workforce access to AWS accounts and applications, not customer self-service app sign-up.
• AWS STS roles provide temporary AWS credentials, but the evidence asks for application authentication and OIDC tokens.

Question 3

Topic: Identity and Access Management

A security engineer reviews an AccessDenied event for an application that assumes ReportWriterRole and writes to an S3 bucket. No explicit deny is present.

Audit note:

Which interpretation is best supported by the evidence?

Options:

• A. The role trust policy is blocking S3 authorization.

• B. The bucket policy overrides the session restriction.

• C. The STS session policy is limiting the role session.

• D. The permissions boundary replaces the role identity policy.

Best answer: C

Explanation: For an assumed role, AWS evaluates the effective permissions from multiple policy types. Identity and resource policies can allow the action, but permissions boundaries and session policies constrain the maximum permissions available to the session. In this evidence, the identity policy, bucket policy, and boundary all allow s3:PutObject, and no explicit deny exists. The remaining limiting factor is the STS session policy, which allows only list and read actions. Because s3:PutObject is outside that session policy, the request is denied. The fix would be to change the session policy used with AssumeRole if write access is intended.

• Resource policy overreach fails because a bucket policy allowing the role ARN does not make the missing session permission irrelevant.
• Boundary misunderstanding fails because the boundary allows the action and does not replace the role identity policy.
• Trust policy confusion fails because the role was already assumed; the trust policy governs assumption, not the later S3 action.

Question 4

Topic: Identity and Access Management

A security team must allow a third-party SaaS provider to scan objects in one S3 bucket prefix in the company’s AWS account. The provider runs from its own AWS account. Access must be short-lived, auditable, and must not use long-lived access keys. The team also wants to reduce confused deputy risk. Which authentication mechanism best meets these requirements?

Options:

• A. IAM Identity Center assignment for the provider account

• B. S3 presigned URLs for the bucket prefix

• C. STS AssumeRole with a trusted role and ExternalId

• D. IAM user credentials for the provider with key rotation

Best answer: C

Explanation: For short-lived cross-account or third-party access, the usual pattern is an IAM role in the resource-owning account that the external AWS principal assumes through AWS STS. The role’s permissions policy grants only the required S3 prefix access, and the trust policy allows the provider’s AWS account or role to call sts:AssumeRole. Requiring an ExternalId helps ensure the provider can assume the role only for the intended customer relationship, reducing confused deputy risk. STS credentials expire automatically and are logged in CloudTrail, avoiding long-lived shared secrets.

Presigned URLs are useful for temporary access to specific object operations, but they are not the best mechanism for recurring third-party scanning across a prefix.

• Long-lived keys fail because IAM users create persistent credentials that increase leakage and rotation risk.
• Presigned URLs are too narrow for managed cross-account scanning and do not establish a reusable trusted role boundary.
• Identity Center is for workforce federation and account access, not service-to-service third-party AWS account delegation.

Question 5

Topic: Identity and Access Management

A company uses IAM Identity Center with an external IdP. The SecOps group is assigned the SecOpsReadOnly permission set in the Prod account. Yesterday, an administrator added securityhub:GetFindings to the permission set. A user in the group signs out and back in, can still choose the Prod account and permission set, but receives AccessDenied for securityhub:GetFindings. What should the security engineer do?

Options:

• A. Create a new SAML provider in the Prod account

• B. Reprovision the permission set to the Prod account

• C. Attach an IAM policy directly to the IdP user

• D. Edit the trust policy of the AWSReservedSSO role

Best answer: B

Explanation: IAM Identity Center permission sets act as templates for IAM roles that are created in assigned AWS accounts. If the user can see the account and permission set in the access portal, the account assignment and federation path are already working. The failure is tied to a newly added action that has not taken effect in the target account. Reprovisioning the permission set updates the corresponding AWSReservedSSO role policy in the Prod account. Editing generated roles directly is not durable and bypasses the Identity Center control plane.

• Trust policy edit is the wrong layer because the user is already able to assume the Identity Center role.
• Direct IAM policy fails because external IdP users receive AWS permissions through Identity Center assignments, not IAM user policies.
• New SAML provider is unnecessary because authentication and portal access are already functioning.

Question 6

Topic: Identity and Access Management

A security engineer reviews a user report that an application returned AccessDenied when the user tried to view an invoice.

Evidence:

CloudTrail event: verifiedpermissions.amazonaws.com IsAuthorized
Caller: arn:aws:sts::<account-id>:assumed-role/AppRuntimeRole/api-session
errorCode: -

Application authorization log:
principal: User::"alice"
action: Invoice::"View"
resource: Invoice::"893"
Verified Permissions decision: DENY
context: userTenant=tenant-a, invoiceTenant=tenant-b

Which interpretation is best supported by the evidence?

Options:

• A. An SCP blocked the application role from calling Verified Permissions.

• B. The IAM call succeeded; Verified Permissions denied the application action.

• C. IAM denied Alice direct access to the invoice data store.

• D. Verified Permissions denied the Lambda role’s AWS API permissions.

Best answer: B

Explanation: IAM and Amazon Verified Permissions enforce different authorization decisions. IAM controls whether an AWS principal, such as the application runtime role, can call AWS APIs like IsAuthorized. The evidence shows that AWS API call completed without an IAM error. The DENY appears in the application authorization log, where Verified Permissions evaluated Alice’s requested application action against invoice attributes and tenant context. The tenant mismatch supports an application-level authorization denial, not an AWS resource access denial. The next investigation should focus on the Cedar policies, entity data, or request context used by Verified Permissions.

• Direct IAM access overstates the evidence because Alice is shown as an application principal, not an IAM principal accessing a data store.
• SCP blocking is not supported because the CloudTrail event has no error and the IsAuthorized call reached the service.
• Runtime role denial confuses layers because Verified Permissions evaluates application permissions, not the Lambda role’s AWS API permissions.

Question 7

Topic: Identity and Access Management

A company lets application teams assume IAM roles through IAM Identity Center to deploy Lambda functions. Teams must be able to create and pass Lambda execution roles for their own applications, but security found that developers could attach broad policies to those roles and escalate privileges. Which policy design best reduces overprivilege while preserving deployment access?

Options:

• A. Allow full IAM access only when Lambda functions have team tags.

• B. Deny iam:CreateRole and iam:PassRole with an SCP in developer accounts.

• C. Require a permissions boundary on created roles and restrict iam:PassRole to bounded roles.

• D. Use IAM Access Analyzer policy generation after each deployment.

Best answer: C

Explanation: Permissions boundaries are the right control when trusted builders need to create or manage IAM roles but must not exceed a security-approved maximum. The identity policy can allow developers to create Lambda execution roles only if the required boundary is attached, and can limit iam:PassRole to roles that carry that boundary and meet naming or tagging conditions. This preserves the required deployment workflow while preventing developers from granting the created role permissions outside the boundary. SCPs can set account-level guardrails, but a broad deny would break the required access instead of safely constraining it.

• Broad SCP deny fails because it removes the required ability to create and pass Lambda execution roles.
• Analyzer-only approach is detective and advisory; it does not prevent privilege escalation during deployment.
• Team tags alone do not cap the permissions that developers can attach to newly created IAM roles.

Question 8

Topic: Identity and Access Management

A company uses AWS Organizations with separate accounts for development, security, and production. Access decisions are based on stable job functions such as Developer, SecurityAuditor, and ProductionOperator. The security team wants centralized workforce access, consistent permissions across accounts, and minimal per-user IAM management. Which approach best satisfies these requirements?

Options:

• A. Use IAM user groups in each AWS account

• B. Use SCPs to grant job-function permissions

• C. Use IAM Identity Center groups with permission sets per job function

• D. Use ABAC with principal tags for every resource

Best answer: C

Explanation: Role-based access control fits this scenario because permissions are driven by stable job functions rather than dynamic attributes. In AWS, the centralized pattern for workforce RBAC across multiple accounts is IAM Identity Center: map users from the identity provider into groups such as Developer or SecurityAuditor, create permission sets for each job function, and assign those permission sets to groups in target accounts. IAM Identity Center provisions the appropriate account roles and keeps access managed centrally. SCPs can restrict maximum permissions in accounts, but they do not grant user access. ABAC is better when access varies by attributes such as project, environment, or data classification.

• Per-account IAM groups create duplicated administration and do not provide centralized multi-account workforce access.
• ABAC everywhere is unnecessary when access is primarily based on stable job functions rather than changing attributes.
• SCP grants are a misconception because SCPs set guardrails; they do not grant permissions to principals.

Question 9

Topic: Identity and Access Management

An application runs as an Amazon ECS task in Account A. It must write daily report files to only s3://central-reports/app1/ in Account B. The security team requires temporary credentials and wants to avoid giving the task broader access to other prefixes or buckets. Which authorization control best supports least privilege?

Options:

• A. Use a cross-account IAM role scoped to the S3 prefix

• B. Create an IAM user in Account B for the application

• C. Use an SCP to allow writes only to the reports bucket

• D. Attach an S3 full-access policy to the ECS task role

Best answer: A

Explanation: For a workload identity that needs cross-account access, use AWS STS with an IAM role trusted by the application’s existing task role. The role’s permissions policy should allow only the required action, such as s3:PutObject, on the specific destination prefix. The destination bucket policy can also be limited to that role. This keeps credentials temporary and applies authorization at the workload identity boundary instead of using broad account-level permissions or long-lived secrets. SCPs can set guardrails, but they do not grant the application access by themselves.

• Broad task role fails because S3 full access exceeds the single-prefix requirement.
• IAM user keys fail because they introduce long-lived credentials for a workload.
• SCP guardrail fails because SCPs limit maximum permissions but do not grant application access.

Question 10

Topic: Identity and Access Management

A security team is reviewing failed deployment attempts from an external CI system. The CI job presents an OIDC token and must deploy to one AWS account without storing AWS access keys.

Evidence:

CloudTrail event: AssumeRoleWithWebIdentity
Issuer: https://token.actions.example.com
Audience: sts.amazonaws.com
Subject: repo:example/app:ref:refs/heads/main
Result: AccessDenied
Note: No matching trusted OIDC provider or role trust condition

Which next action best supports the required access pattern?

Options:

• A. Configure IAM Identity Center permission sets for the CI job

• B. Create an OIDC provider and role trust for AssumeRoleWithWebIdentity

• C. Create an IAM user and require the job to call GetSessionToken

• D. Use a presigned URL for the deployment role

Best answer: B

Explanation: The access pattern is workload federation from an external OIDC issuer to AWS without long-lived access keys. For this pattern, configure an IAM OIDC identity provider for the issuer and an IAM role trust policy that allows sts:AssumeRoleWithWebIdentity with conditions that match the token audience and subject. STS then exchanges the valid web identity token for temporary role credentials scoped by the role permissions. The CloudTrail evidence does not indicate that the deployment permissions are wrong yet; it shows the trust path for issuing credentials is not established.

• IAM user tokens still require long-lived IAM user credentials before GetSessionToken can issue temporary credentials.
• IAM Identity Center is intended for workforce federation, not a CI workload presenting an OIDC web identity token.
• Presigned URLs delegate access to a specific request, not general temporary credentials for assuming a deployment role.

Continue with full practice

Use the AWS SCS-C03 Practice Test page for the full IT Mastery practice bank, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.

Try AWS SCS-C03 on Web View AWS SCS-C03 Practice Test

Related focused pages

• Free AWS SCS-C03 Full-Length Practice Exam
• Detection
• Incident Response
• Infrastructure Security
• Data Protection
• Security Foundations and Governance

Practice next step

Use the practice page above for mixed-topic practice, timed mocks, explanations, and app access.