AWS 4: Identity and Access Management: 178 practice questions

12 of the 178 4: Identity and Access Management questions in the Certsqill AWS bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AWS? Take the free 5-min readiness check →

1. Use IAM Identity Center permission sets: Select TWO designs that satisfy these requirements.

Select two. More than one option is correct — every correct one is ticked below.

1. Use one administrator role for engineers and workflows, relying on separate application logging to distinguish activity.

   A shared administrator role violates least privilege and does not separately constrain human and workflow permissions.
2. Use Cognito identity pools for engineers and workflows without configuring an external OIDC provider or role conditions.

   Identity pools can issue credentials, but omitting the external provider and claim conditions fails the stated workflow trust requirements.
3. Create long-term IAM users for workflows and store their access keys in the external provider's encrypted secrets.

   Encrypted storage does not remove long-term credential exposure and violates the requirement to avoid persistent AWS keys.
4. Use IAM Identity Center permission sets with an MFA-capable identity provider for engineers. ✓

   IAM Identity Center provides federated human access, while permission sets define account permissions and MFA can be enforced by the identity provider.
5. Configure an IAM OIDC provider with aud and sub conditions, mapping approved workflow claims to a least-privilege role. ✓

   OIDC federation exchanges workflow tokens for temporary role credentials while claim conditions restrict trusted repositories and branches.

Use Identity Center for federated humans and constrained OIDC role assumption for short-lived workflow credentials.

2. Use customer-specific OIDC roles with constrained aud/sub: Which mechanism should be configured?

1. Issue every customer a presigned PUT URL for the same fixed artifact object.

   An object-specific URL neither provides customer-isolated prefixes nor temporary role credentials for each job’s required object operations.
2. Create one IAM user per customer and distribute its access key through each job environment.

   This can separate customers but creates long-term credentials outside AWS, violating the requirement.
3. Use customer-specific OIDC roles with constrained aud/sub trust and prefix-scoped S3 permissions. ✓

   OIDC federation issues temporary credentials without stored AWS keys. Trust conditions restrict which tokens can assume the role, and customer-scoped S3 permissions prevent cross-customer access.
4. Use an S3 bucket policy allowing the provider's public IP range.

   A source IP restriction does not authenticate individual jobs or issue temporary AWS credentials with customer-specific authorization.

Use OIDC federation with constrained claims and customer-scoped S3 permissions.

3. Align the API audience validation or client flow: Which troubleshooting action should the team take?

1. Align the API audience validation or client flow with the intended enabled app client. ✓

   The token audience identifies a different app client from the one accepted by the API, so the validation configuration or client flow must be aligned.
2. Replace the user pool with an identity pool so the application receives temporary AWS credentials.

   Identity pools provide AWS credentials but do not correct the API's existing JWT audience mismatch.
3. Enable unauthenticated identity-pool access for the requests.

   Guest identity-pool access does not make the API accept a JWT issued for the wrong app client.
4. Rotate the external OIDC provider certificate and leave the API audience configuration unchanged.

   The issuer has already passed the stated check; certificate rotation does not resolve an audience mismatch.

Align the API's accepted audience with the Cognito app client that issued the token.

4. Use IAM Identity Center and OIDC role assumption: Which design best satisfies these requirements?

1. Use IAM Identity Center for engineers and static access keys for the external pipeline.

   Static keys violate the temporary-credential and no-long-term-keys requirements.
2. Use IAM Identity Center and OIDC role assumption. ✓

   Identity Center centralizes workforce assignments and permission sets, while OIDC supplies temporary credentials to the compatible CI/CD pipeline. Configure phishing-resistant MFA in the workforce identity path.
3. Use IAM Roles Anywhere for CI/CD and federate engineers through IAM Identity Center.

   This provides temporary certificate-based credentials but does not use the pipeline's required OIDC integration.
4. Use IAM users with hardware MFA for engineers and OIDC only for pipeline notifications.

   IAM users do not provide the required centralized federated workforce assignments, and OIDC is not used to obtain pipeline role credentials.

Use IAM Identity Center for people and OIDC role assumption for CI/CD.

5. Allow analyst start/stop actions only when controlled: Which TWO controls best implement this model?

Select two. More than one option is correct — every correct one is ticked below.

1. Attach AdministratorAccess to analysts and review CloudTrail after cross-department inspection.

   AdministratorAccess grants excessive permissions and detects misuse after the fact rather than enforcing department-level least privilege.
2. Create one read-only role for all EC2 resources and rely on console filters for department separation.

   Console filters change presentation, not authorization; analysts could still retrieve information about every department's instances.
3. Create department-specific IAM roles and update each role whenever a department adds resources.

   This creates unnecessary role sprawl and requires continual updates as resources change.
4. Allow analyst start/stop actions only when controlled principal and instance Department tags match. ✓

   EC2 start and stop actions support resource-scoped tag conditions. Controlled principal/resource tags can enforce the department restriction for those actions; this does not imply tag-filtered DescribeInstances visibility.
5. Use a commander read-only permission set, remove departed-user assignments, and limit session duration. ✓

   A centrally managed permission set supplies the separate cross-department role. Removing the assignment prevents new sessions, while a short configured duration limits the lifetime of existing sessions; it does not terminate tracked sessions immediately.

Use controlled ABAC for analysts and a separate Identity Center incident role with assignment removal and short sessions.

6. Replace the role policy with scoped S3 object permissions: Which policy change is best?

1. Grant the service AmazonS3ReadOnlyAccess and allow iam:PassRole on roles matching the processing account.

   The managed policy is broader than required, and an account-wide role pattern still permits unintended delegation.
2. Keep s3:* but add a bucket policy denying requests unless the source service uses the research VPC endpoint.

   A network condition does not restrict object actions, prefixes, or PassRole delegation, leaving excessive permissions effective.
3. Remove the permissions boundary because the role policy will define the service’s exact permissions.

   Removing the boundary eliminates a maximum-permission safeguard and does not itself scope the existing role policy.
4. Replace the role policy with scoped S3 object permissions and iam:PassRole conditioned on the approved role ARN. ✓

   Resource-scoped S3 actions and an iam:PassRole condition limit both data access and delegation to required operations.

Scope S3 actions to required object paths and constrain PassRole with the exact approved processing-role ARN.

7. Inspect whether a permissions boundary or session policy: What should the responder inspect first?

1. Inspect whether the SCP must explicitly grant s3:GetObject in addition to allowing Amazon S3 actions.

   An SCP constrains permissions; it does not need to grant the action when the identity and resource policies provide the grant.
2. Inspect whether the object key requires a separate bucket policy because wildcard resources cannot match object paths.

   The resource arn:aws:s3:::lab-data/* correctly matches objects in the bucket.
3. Inspect whether a permissions boundary is required before a bucket policy can grant object access.

   Permissions boundaries are optional constraints, not prerequisites for resource-based authorization.
4. Inspect whether a permissions boundary or session policy omits s3:GetObject for the role session. ✓

   The stated bucket condition matches the confirmed role ARN, and the SCP permits S3. A boundary or session policy can still constrain the identity policy and cause AccessDenied.

The confirmed principal matches the bucket condition, so inspect remaining constraining policies, especially a boundary or session policy.

8. Require a unique external ID in the trust policy: Which correction best addresses the unintended authorization

1. Trust the partner account root and retain the S3 prefix restriction.

   Trusting the account root broadens who can assume the role and increases the unintended-assumption risk.
2. Add a permissions boundary to limit the role’s S3 prefix.

   A boundary limits actions after assumption and does not prevent an unintended principal from assuming the role.
3. Add an S3 resource-account condition to the role policy.

   That condition would constrain S3 authorization, not prevent an unintended AssumeRole request.
4. Require a unique external ID in the trust policy. ✓

   A customer-specific external ID helps prevent a third-party confused-deputy scenario while preserving the existing principal and S3 restriction.

Require a unique external ID in the trust policy to mitigate the third-party confused-deputy risk.

9. Use an ECS task role for AWS service calls and remove: Which TWO designs correct the architecture?

Select two. More than one option is correct — every correct one is ticked below.

1. Use an ECS task role for AWS service calls and remove the embedded access key from the image. ✓

   ECS task-role credentials are temporary and scoped, eliminating long-lived application credentials from the container image.
2. Use Amazon Cognito identity pools for every ECS task and assign authenticated employee roles to containers.

   Identity pools provide application-user AWS credentials, but they do not replace the ECS task role or centralize API authorization.
3. Use Amazon Verified Permissions with corporate OIDC identities to evaluate employee actions on documents and API resources. ✓

   Verified Permissions externalizes fine-grained application authorization after OIDC authentication identifies the employee.
4. Use the corporate OIDC provider directly as an IAM role for the ECS task and authorize documents through S3 policies.

   OIDC federation can serve external workloads, but an ECS task should use its task role and S3 policies cannot express application decisions.
5. Use an IAM user access key in ECS and rotate it automatically through AWS Secrets Manager.

   Automated rotation reduces exposure duration but retains long-term credentials where an ECS task role is supported.

Use an ECS task role for temporary workload credentials and Verified Permissions for employee-aware application authorization.

10. Restore the matching private key and certificate chain: Which change restores temporary credential issuance?

1. Generate a presigned URL and configure the scanner to use it for the scan.

   A presigned URL is an alternative transfer mechanism, but it does not restore the failed certificate-based credential flow.
2. Restore the matching private key and certificate chain for the configured Roles Anywhere profile. ✓

   The external workload must prove possession of the certificate’s private key, and the certificate chain must be trusted by the configured trust anchor.
3. Attach an EC2 instance profile to the on-premises server and restart the scanner.

   Instance profiles provide credentials to supported AWS compute environments, not arbitrary on-premises servers.
4. Create an IAM user access key and protect it in the scanner’s credential store.

   This uses long-term credentials despite the explicit prohibition on storing AWS access keys.

Restore the matching private key and trusted certificate chain so IAM Roles Anywhere can issue temporary credentials.

11. Correct time synchronization on the application server: What should the team investigate first?

1. Configure a Cognito identity pool so the application can ignore ID-token expiration during sign-in.

   Identity pools exchange valid provider tokens for AWS credentials and do not disable expiration checks in the application.
2. Replace the SAML provider with an OIDC provider because Cognito cannot validate federated user-pool tokens.

   Cognito user pools support SAML federation and issue tokens; the observed failure is clock skew, not federation incompatibility.
3. Add an IAM permissions policy to the Cognito user pool so users can complete token validation.

   Application token validation occurs before AWS API authorization, and user-pool tokens do not require an IAM policy for validation.
4. Correct time synchronization on the application server and verify token expiration using synchronized UTC clocks. ✓

   The token is structurally valid, but the server clock makes an otherwise acceptable token appear expired during validation.

The application server clock is twelve minutes ahead, so it rejects the token as expired despite correct issuer and audience.

12. Narrow the SCP deny for the approved production bucket: Which action resolves the failure?

1. Add a wildcard-principal S3 allow to the production bucket policy while leaving the organizational restriction unchanged.

   A broader resource grant cannot override an explicit organizational deny.
2. Narrow the SCP deny for the approved production bucket. ✓

   An explicit SCP deny overrides the role and bucket-policy allows. Narrowing the deny for the approved bucket allows the existing compatible grants to take effect.
3. Change the bucket policy principal to the role-session ARN and retain the existing SCP deny.

   Changing the resource-policy principal cannot override the caller’s explicit SCP deny.
4. Attach a permissions boundary that allows the production bucket object action while retaining the SCP deny.

   A permissions boundary limits maximum permissions but cannot override an explicit SCP deny; it also does not grant access by itself.

Narrow the SCP deny for the approved production bucket.

Other AWS domains

• 3: Infrastructure Security — 160 questions →
• 5: Data Protection — 160 questions →
• 1: Detection — 142 questions →
• 2: Incident Response — 125 questions →
• 6: Security Foundations and Governance — 125 questions →
• All 890 AWS questions →
• AWS certification: requirements, cost and exam format →