4.1 - Design, implement and troubleshoot authentication (Identity Center, SAML, OIDC, Cognito, MFA, Roles Anywhere)

AWS Certified Security Specialty objective 4.1 covers designing, implementing and troubleshooting authentication for people and for workloads. You keep the account root user for the rare tasks that require it, protect it with a phishing-resistant hardware MFA device such as a FIDO2 security key, and pull the IAM credential report to see every user's MFA state, password age and access key age. Temporary credentials come from AWS STS: sts:AssumeRole returns a session valid one hour by default, a SAML 2.0 sign-in calls AssumeRoleWithSAML with the RoleSessionName attribute driving the name that appears in CloudTrail, and an expired identity provider signing certificate is the classic reason a federation that worked for months suddenly rejects every assertion. IAM Identity Center synchronises users and groups from an external directory over SCIM, a Cognito user pool authenticates application users while an identity pool exchanges that token for temporary IAM credentials, and compromised credentials detection catches passwords known from breach data. Workloads authenticate without any stored key through IAM roles for service accounts on EKS, GitHub OIDC federation narrowed by the repository claim, IAM Roles Anywhere with an X.509 trust anchor and a certificate revocation list, and IMDSv2 against server side request forgery. Expect scenarios naming an identity source and asking which authentication mechanism fits.

Memory hook
Invalidate every active session of a role at once = attach a deny policy conditioned on aws:TokenIssueTime. Stop one compromised IAM Roles Anywhere certificate = import a CRL into the trust anchor. MFA that survives a real-time phishing relay = FIDO2 hardware security key.

Practice questions

1. An application running on an EC2 instance needs to read from DynamoDB. Which approach follows AWS security best practice?

  • Store an IAM user's access key and secret key in a configuration file on the instance
  • Attach an IAM role to the instance through an instance profile (correct answer)
  • Embed long lived credentials in the application source code at build time
  • Create an IAM user per instance and rotate its keys manually every quarter

An instance profile delivers temporary credentials that AWS rotates automatically, so nothing durable is ever stored on disk or in code. All three other options keep long lived secrets somewhere they can be read, copied from a snapshot, or committed to a repository, and manual rotation fails as soon as someone forgets.

2. A partner company must access one of your S3 buckets from their own AWS account. Which mechanism avoids creating any credential in your account?

  • A cross account IAM role they assume with sts:AssumeRole (correct answer)
  • An IAM user created for them, whose access keys you send by encrypted email
  • A shared root account password held by both security teams
  • A permanent access key stored in your Secrets Manager and read by their application

Cross account role assumption issues short lived credentials on demand and leaves nothing durable to leak or rotate. The other three all create a long lived secret that must be transmitted and stored somewhere, and sharing a root password is never acceptable under any circumstance.

3. Your company already runs Active Directory on premises and wants employees to reach the AWS console without a second password. Which approach fits?

  • Create one IAM user per employee and synchronise passwords with a nightly script
  • Export the directory to a CSV file and import it into IAM every month
  • Federate identities into AWS IAM Identity Center using SAML 2.0 (correct answer)
  • Give each department a shared IAM user whose password the manager distributes

Federation keeps the corporate directory as the single source of truth and issues temporary credentials, so a departure handled in AD immediately removes AWS access. Duplicating users into IAM creates a second password store that drifts, and shared accounts destroy any ability to attribute an action to a person.

4. Which statement about the AWS account root user is correct?

  • Its permissions can be reduced by attaching a restrictive IAM identity policy to it
  • It should have MFA enabled and be used only for the few tasks that require it (correct answer)
  • It is the only principal allowed to create IAM roles in the account
  • Deleting it is recommended once an administrator IAM user exists

The root user keeps full account access and cannot be limited by IAM policies, which is exactly why it needs MFA and near zero day to day use. It is not required to create roles, and it can never be deleted because it is the account itself. Only an SCP can constrain it, and only in a member account of an organization.

5. An access key belonging to a departed employee may have leaked. What is the correct immediate action?

  • Rotate the key and email the new one to the team that used the integration
  • Open a support case and wait for AWS to confirm whether the key was misused
  • Attach a deny all policy to the user and revisit the situation next sprint
  • Deactivate the key, then delete it once nothing depends on it (correct answer)

Deactivating stops the key working immediately while leaving it visible for investigation, and deletion follows once dependencies are cleared. Rotating and mailing a new key spreads a fresh secret through an insecure channel, waiting on AWS leaves the window open, and deferring to a later sprint leaves a live credential in the hands of someone outside the company.

6. A mobile application must let users sign in with Google and then upload to S3 under their own identity. Which service handles the identity exchange?

  • AWS Directory Service, joined to a managed Microsoft AD domain that every mobile device trusts at enrolment
  • IAM Identity Center, with one permission set created and assigned per individual mobile user account
  • Amazon Cognito identity pools, exchanging the provider token for AWS credentials (correct answer)
  • AWS Resource Access Manager, sharing the bucket directly with each end user of the mobile application

Cognito identity pools take a token from a social or enterprise provider and return temporary AWS credentials scoped to that user, which is exactly the mobile pattern. Directory Service targets Windows workloads, Identity Center is built for workforce access rather than millions of consumers, and RAM shares resources between accounts, not with end users.

Related objectives