Task 6.1: Implement techniques for identity and access management at scale.

• AAttach an SCP to the account that denies iam:CreateRole for every principal except the security team's role

  Incorrect

  This keeps the control but takes role creation away from the developers, which is the opposite of the request.

• BAllow role creation only with iam:PermissionsBoundary set to AppBoundary, and deny edits to AppBoundary and boundary removal

  Correct

  A condition on iam:PermissionsBoundary lets the delegate create principals only with the required boundary, and denying edits to the boundary policy and its removal stops the delegate from escaping it.

• CSet AppBoundary as the permissions boundary of the developers' own role and allow them to create and pass roles without any condition

  Incorrect

  The boundary limits the developers' role, but the roles they create can carry any policy, so they could create a more powerful role and use it.

• DRequire developers to assume their role with a session policy equal to AppBoundary whenever they create a role

  Incorrect

  A session policy limits only that session. It places no limit on the permissions of the roles created during it.

Permissions boundaries are the IAM tool for delegating permission management. The delegate may create principals only if they carry the approved boundary, and must not be able to edit or detach that boundary.

• AA principal of arn:aws:iam::*:role/deploy-pipeline, so that the role with that name in every account is trusted

  Incorrect

  A wildcard cannot match part of a principal name or ARN in the Principal element, so this does not name the roles in many accounts.

• BA principal list with the account ID of every Workloads account, kept up to date by a Lambda function that runs when an account joins the OU

  Incorrect

  The trust policy would change every time an account joins or leaves the OU, which the platform team does not want, and the function is extra code to maintain.

• CA principal of "AWS": "*" with a condition that matches the Workloads OU path in aws:SourceOrgPaths

  Incorrect

  aws:SourceOrgPaths is in the request context only when an AWS service principal calls on behalf of a resource. A role that assumes another role does not carry it, so the condition never matches.

• DA principal of "AWS": "*" with conditions on aws:PrincipalOrgPaths for the Workloads OU path and on aws:PrincipalArn for deploy-pipeline

  Correct

  aws:PrincipalOrgPaths holds the organization path of the caller's account, so a path that ends in /* covers the OU and its child OUs, and aws:PrincipalArn narrows the trust to the deploy-pipeline roles.

A trust policy cannot name roles across many accounts with a wildcard in the Principal element, but it can trust every principal and then restrict access in the Condition element. aws:PrincipalOrgPaths follows the organization's structure, so an account that joins or leaves the Workloads OU gains or loses access without a policy change, and aws:PrincipalArn keeps other roles in those accounts out. The organization ID belongs at the start of the path, because OU IDs are unique only within one organization.

• AMove the password to a Secrets Manager secret with a seven-day rotation schedule, and allow the task role to read the secret

  Incorrect

  The application would still use a long-lived password, now stored in a secret, and the rotation schedule is the kind of process security wants to remove.

• BTurn on Kerberos authentication for the DB instance with AWS Managed Microsoft AD, and create app_rw in the directory

  Incorrect

  Kerberos authenticates users that are stored in a directory, so access would depend on directory credentials, not on the task's IAM role, and it adds a directory to run.

• CTurn on IAM database authentication, grant rds_iam to app_rw, and allow the task role rds-db:connect on that database user

  Correct

  The application then connects with an authentication token that is generated from the task role's credentials and lasts 15 minutes, so no database password is stored or rotated.

• DAllow the task role rds-db:connect on app_rw, and keep the password in the parameter for the application to connect with

  Incorrect

  The rds-db:connect permission is used only by IAM database authentication. A connection with the stored password ignores it, and the long-lived password stays.

IAM database authentication replaces the database password with a short-lived token that is signed with AWS credentials, here the ECS task role's. Access is controlled in IAM through rds-db:connect on a resource ARN for one database user, so removing the permission from the role revokes access. On PostgreSQL the database user needs the rds_iam role, and IAM authentication then takes precedence over password authentication for that user. The feature needs extra memory on the DB instance.

• ARegister the internal CA as an IAM Roles Anywhere trust anchor and use the servers' certificates to get temporary role credentials

  Correct

  IAM Roles Anywhere gives workloads outside AWS temporary credentials for an IAM role, using X.509 certificates from a CA registered as a trust anchor.

• BKeep the access keys and rotate them every 30 days with a scheduled script that stores new keys in the configuration files

  Incorrect

  Rotated access keys are still long-term credentials, which the review wants removed.

• CAssign the servers' service accounts to users in IAM Identity Center and let the batch jobs sign in through the AWS access portal

  Incorrect

  IAM Identity Center is for workforce users signing in. Batch servers need a machine credential flow, not an interactive portal.

• DStore the access keys in AWS Secrets Manager and have each server read them before every upload, using a second set of access keys

  Incorrect

  The servers would still need long-term keys to read the secret, so the long-term credentials remain.

For workloads outside AWS, IAM Roles Anywhere replaces stored access keys with short-lived role credentials, trusting the company's existing PKI. AWS best practice is that workloads use temporary credentials with IAM roles.

• APass a session policy for each job when the scheduler assumes the role

  Correct

  A session's permissions are the intersection of the role's policies and the session policy, which scopes down each session.

• BAttach a permissions boundary to the shared role that allows only bucket reads

  Incorrect

  A boundary on the shared role limits every job the same way.

• CAdd an inline policy to the role before each job and remove it after

  Incorrect

  Editing the shared role per job affects other jobs running at the same time.

• DUse the role session name to describe what each job may access

  Incorrect

  A session name identifies a session; it does not limit permissions.

Session policies are passed when a role is assumed. They cannot grant more than the role allows, and they narrow each session to the job's needs.

• AReplace the account list with an aws:SourceOrgPaths condition that matches the path of the Workloads OU

  Incorrect

  OU paths suit delivery from part of an organization, but this path leaves out the Sandbox and Security accounts.

• BReplace the account list with an aws:ResourceOrgID condition that equals the organization ID

  Incorrect

  This key describes the organization that owns the bucket being accessed, which is always the company's, so flow logs from outside accounts could still write.

• CKeep the account list, but have a weekly Lambda function rewrite it from the Organizations ListAccounts API

  Incorrect

  This automates the list, but delivery from a new account still fails until the next run, and the team maintains the function.

• DReplace the account list with an aws:SourceOrgID condition that equals the organization ID

  Correct

  The calling service passes the organization of the account that owns the flow log, so accounts that join or leave are covered without editing the policy, and outside flow logs are denied.

When an AWS service principal writes to a resource on behalf of resources in many accounts, aws:SourceOrgID matches the organization of the originating resource, here each flow log, so the policy needs no account list. aws:SourceOrgPaths applies the same check to chosen OUs, and aws:ResourceOrgID describes the resource being accessed rather than where the request came from.

• AReplace the variable with each user's name in separate policies

  Incorrect

  Separate policies per user remove the benefit of one shared policy.

• BAdd "Version": "2012-10-17" to the policy so the variable works

  Correct

  Without a supporting Version element, variables such as ${aws:username} are treated as literal strings.

• CAdd an s3:prefix condition that lists every user's folder name

  Incorrect

  Listing every folder replaces the variable with a manual list.

• DAttach the policy to a group instead of to each user

  Incorrect

  Attaching to a group does not make the variable work.

Policy variables were introduced with policy language version 2012-10-17. Policies without that Version element treat variables as plain text.

• AIn the function's execution role, allow s3:GetObject on that bucket

  Incorrect

  The execution role governs what the function can do, not who can invoke it.

• BIn the bucket policy, allow lambda:InvokeFunction on the function's ARN for S3

  Incorrect

  Invocation permission is granted on the function's resource-based policy.

• CIn the function's resource policy, allow S3 with bucket and account conditions

  Correct

  S3 needs permission from the function's resource-based policy, which can be limited to a bucket and account.

• DIn an SCP for the account, allow Amazon S3 to invoke every Lambda function

  Incorrect

  SCPs do not grant permissions.

For S3 triggers, Lambda's resource-based policy allows Amazon S3 to invoke the function, scoped to the bucket and account. The execution role covers the function's own access to S3.

• ADelete the analyzer and create it again at the start of each month

  Incorrect

  Recreating the analyzer does not stop the expected findings.

• BRemove the partner account's access to the log bucket permanently

  Incorrect

  The access is intentional and must stay.

• CArchive these findings by hand in the console each time that new ones appear

  Incorrect

  Manual archiving does not cover future findings automatically.

• DCreate an archive rule for the bucket and partner, applied to existing findings

  Correct

  Archive rules archive new findings that match the criteria and can be applied retroactively to existing ones.

Archive rules suit regularly granted access to a specific bucket or principal. They archive matching findings automatically so reviewers focus on unexpected access.