Task 2.3: Identify AWS access management capabilities.

• AClose the AWS account

  Correct

  Closing a standalone account requires root user credentials. Accounts in an organization can be closed from the management account instead.

• BChange the account name

  Incorrect

  The account name is one of the settings that does not require root user credentials.

• CActivate IAM access to the Billing and Cost Management console

  Correct

  Turning on IAM access to the billing console is on the list of tasks only the root user can perform.

• DCreate an IAM group and attach a managed policy to it

  Incorrect

  Everyday administration like this is done by an administrative user, not the root user; it is not a root-only task.

• EUpdate the account's alternate contacts

  Incorrect

  Alternate contacts are one of the account settings that do not require root user credentials.

The root user should do only the few tasks that require it. Everything else, including most account settings, belongs to IAM identities with the right permissions.

• AAttach the AWS managed policy AmazonS3FullAccess to her IAM identity

  Incorrect

  That policy allows every Amazon S3 action on every bucket, including writing and deleting — far more than reading one bucket.

• BLet her sign in with the account root user for this task

  Incorrect

  The root user has complete access to every service and resource in the account and should be used only for the few tasks that require it.

• CGive her team's group a policy that only allows reading that bucket's objects

  Correct

  Least privilege means granting only the permissions required for a task, on only the resources it needs. Granting through a group keeps the permission easy to review and remove.

• DGive her read access to every bucket in the account so she will not need to ask again

  Incorrect

  Convenience is not a reason to grant access to data she does not need. Every extra bucket is extra exposure if her credentials leak.

Start from the task: which actions, on which resources. Write exactly that into a policy, and attach it where it can be reviewed and removed.

• ACreate an IAM user for the application and save its access keys in a configuration file on the instance

  Incorrect

  These are long-term credentials stored on the instance, which someone must distribute, protect and rotate by hand — what the team wants to avoid.

• BAttach an IAM role to the instance and let the application use the role's temporary credentials

  Correct

  The role supplies temporary credentials through the instance profile. They are updated automatically, so there are no long-term keys to store or rotate.

• CUse access keys created for the account root user

  Incorrect

  AWS strongly recommends not creating access keys for the root user at all, because the root user has full access to everything in the account.

• DMake the bucket public so the application needs no credentials

  Incorrect

  That would expose the files to anyone on the internet. S3 Block Public Access exists to prevent exactly this.

For code running on AWS compute, the answer is almost always a role: temporary credentials, rotated for you, with only the permissions the application needs.

• AAWS IAM Identity Center

  Correct

  IAM Identity Center connects an existing identity provider, gives workforce users one point of sign-in, and centrally manages their access to multiple AWS accounts through an access portal.

• BAn IAM user for each employee in each of the 40 accounts

  Incorrect

  That creates hundreds of sets of long-term credentials. Best practice is federation with an identity provider and temporary credentials for human users.

• CAmazon Cognito

  Incorrect

  Cognito provides sign-up and sign-in for the users of your web and mobile applications, not workforce access to AWS accounts.

• DService control policies (SCPs) in AWS Organizations

  Incorrect

  SCPs set the maximum permissions available in member accounts. They do not sign anyone in or assign accounts to employees.

Workforce access to many accounts is the IAM Identity Center use case: federate once with the company directory, then assign accounts and permissions centrally.

• AUse the root user for daily administration so that fewer identities exist

  Incorrect

  The recommendation is the opposite: create an administrative user for everyday tasks and use the root user only for tasks that require it.

• BRegister multi-factor authentication (MFA) for the root user

  Correct

  Because the root user can perform privileged actions, MFA adds a second factor to the email address and password. AWS recommends registering more than one MFA device.

• CShare the root password with every administrator so it is never lost

  Incorrect

  Root credentials should not be shared with anyone except those with a strict business need; account recovery mechanisms exist for lost passwords.

• DDo not create access keys for the root user

  Correct

  AWS strongly recommends against root access keys, because the root user has full access to every service and resource, including billing.

• EAttach the AdministratorAccess policy to the root user

  Incorrect

  The root user already has complete access to everything in the account. Protecting it is about limiting its use, not granting it more.

Treat the root user as a break-glass identity: strong password, MFA, no access keys, used only for the handful of tasks that need it.