Task 1.1: Design secure access to AWS resources.

• ACreate an IAM role in each member account that trusts the function's execution role, and assume each of those roles with AWS STS

  Correct

  The role's trust policy names the central account's execution role as a principal, and assuming the role returns temporary credentials for that account. No long-term keys exist anywhere.

• BIn each member account, create an IAM user with EC2 permissions, and keep the users' access keys in AWS Secrets Manager centrally

  Incorrect

  It would work, but access keys are long-term credentials, which the security team forbids. AWS recommends that workloads use IAM roles with temporary credentials instead.

• CAttach a service control policy to the organization root that allows the central function to stop instances in all member accounts

  Incorrect

  An SCP never grants permissions. It only sets the maximum permissions available to users and roles in member accounts, so it cannot give the central function access.

• DAttach a resource-based policy to each EC2 instance that allows the central execution role to call the ec2:StopInstances action

  Incorrect

  Amazon EC2 does not support resource-based policies, so an instance cannot carry a policy that grants a principal in another account access to it.

Cross-account automation uses a role in each target account plus AssumeRole from the caller. SCPs only limit, they never grant, and EC2 has no resource-based policies to grant access from the resource side.

• AAttach a permissions boundary that allows only the two Regions to every IAM user and role that currently exists in the accounts

  Incorrect

  A boundary limits only the entities it is attached to, and administrators with full IAM permissions can create new roles or remove boundaries, so it is not a guardrail they cannot bypass.

• BDeploy an AWS Config rule to every account in the OU that flags any resource created outside the two approved Regions

  Incorrect

  AWS Config evaluates resource configurations and flags noncompliant resources after they exist. It does not stop the API call that creates them.

• CAttach an SCP to the OU that denies requests when aws:RequestedRegion is outside the two Regions, exempting global services

  Correct

  An SCP sets a guardrail for every IAM user and role in the member accounts below the OU, administrators included. The aws:RequestedRegion key compares the Region that was called, and global services need an exemption.

• DCreate an IAM Identity Center permission set that allows only the two Regions and assign it to every user in the accounts

  Incorrect

  A permission set governs the access that users get when they sign in through IAM Identity Center. IAM users and roles created inside the accounts are not limited by it.

"Nobody, including administrators" points to a preventive control above the accounts: an SCP with a Region condition. Boundaries can be changed by IAM administrators, and Config only detects.

• ACreate a SAML identity provider and federated roles in each of the 40 accounts, and map AD groups to the roles

  Incorrect

  SAML federation through IAM works, but a provider and roles must be configured and maintained in every account, which is far more effort than one central assignment.

• BConnect IAM Identity Center to the directory through AD Connector and assign permission sets to AD groups per account

  Correct

  IAM Identity Center can use a self-managed AD, connected through AWS Directory Service, as its identity source and centrally assign access to many accounts with permission sets.

• CCreate an Amazon Cognito user pool that federates with the directory and sign employees in to the accounts through it

  Incorrect

  Cognito user pools handle sign-up and sign-in for the users of your own applications. Workforce access to AWS accounts is the job of IAM Identity Center.

• DCreate IAM users in each account that match the AD user names, and keep their passwords in sync with a scheduled script

  Incorrect

  This creates long-term credentials in 40 accounts and a custom sync job to maintain. AWS recommends federation with temporary credentials for human users.

For workforce access to many accounts from an existing directory, IAM Identity Center with the directory as identity source is the central, low-effort option. Per-account SAML works but multiplies the setup.

• ATurn on MFA for the management account's root user and use it only for tasks that need root credentials

  Correct

  AWS recommends protecting the root user with MFA and signing in as root only for the tasks that require it.

• BAttach an SCP to the organization root that denies every action by the management account's root user

  Incorrect

  SCPs don't affect users or roles in the management account; they apply only to member accounts.

• CTurn on centralized root access for member accounts and remove the member accounts' root credentials

  Correct

  Centralized root access lets the management account remove member accounts' long-term root credentials and prevent their recovery.

• DCreate root access keys in each member account and keep them in AWS Secrets Manager for emergencies

  Incorrect

  Root access keys are long-term credentials with full access. AWS recommends relying on temporary credentials and removing root credentials from member accounts.

• ERemove the management account's root credentials so that only IAM roles can administer the organization

  Incorrect

  Centralized root access covers member accounts. The management account keeps its root user, which you protect with MFA.

Protect the one root user you keep (the management account's) with MFA, and remove the long-term root credentials of member accounts centrally. SCPs do not reach the management account.

• AAn IAM policy on the application's role that allows s3:GetObject only for requests that use the endpoint

  Incorrect

  This restricts only that one role. Any other principal with S3 permissions could still read the objects through another network path.

• BAn endpoint policy on the gateway endpoint that allows s3:GetObject only on this particular bucket

  Incorrect

  An endpoint policy controls what may pass through the endpoint. It cannot stop requests that reach the bucket by another path; the bucket policy controls that.

• CA network ACL on the application subnets that blocks S3 traffic that does not go through the endpoint

  Incorrect

  A network ACL filters traffic for its own subnets only. It cannot make the bucket refuse requests that come from other networks or accounts.

• DA bucket policy that denies all requests unless their aws:SourceVpce value matches the endpoint ID

  Correct

  A bucket policy is evaluated for every request to the bucket. A Deny with an aws:SourceVpce condition refuses any request that does not arrive through that endpoint, whoever makes it.

"Whatever IAM permissions a principal has" means the control must sit on the resource. A bucket policy with aws:SourceVpce covers every caller; identity and endpoint policies cover only their own side.

• AAttach an SCP to the developer account that denies every action outside DynamoDB and CloudWatch Logs, for all users and roles in it

  Incorrect

  The SCP would also block the developers themselves from creating functions and roles, and every other workload in the account. It limits the whole account, not only the roles developers create.

• BDefine those permissions in a managed policy and allow role creation only when that policy is set as the role's permissions boundary

  Correct

  A permissions boundary sets the maximum permissions an identity-based policy can grant. IAM documents this pattern for delegating role creation while keeping the result inside a limit.

• CValidate each new role with IAM Access Analyzer policy checks, then delete any role whose policy grants more than the allowed actions

  Incorrect

  Access Analyzer reports findings about policies; deleting roles afterwards leaves a window in which an over-permissive role exists and can be used.

• DGrant developers iam:CreateRole and iam:PutRolePolicy, then review every new role policy in the CloudTrail event history each week

  Incorrect

  A weekly review is a detective control. Nothing stops a broad policy from working until someone notices it, which is exactly what a boundary prevents.

"Can ever have more than" asks for a preventive ceiling on roles that others create. Permissions boundaries are built for delegated administration; SCPs limit the whole account, and reviews only detect.

• ACreate an IAM role that trusts the vendor's account, and require the vendor's external ID in its trust policy

  Correct

  The vendor assigns each customer a unique external ID. Requiring it in the trust policy lets the vendor assume the role only when it is acting for this company.

• BCreate an IAM user for the vendor with a read-only policy, and send the user's access key to the vendor securely

  Incorrect

  Long-term access keys given to a third party are what AWS advises against. Third-party access is granted through a role that issues temporary credentials.

• CCreate an IAM role that trusts the vendor's account, with an aws:SourceIp condition for the vendor's servers

  Incorrect

  The vendor calls AWS from the same servers for all its customers, so the source IP cannot show which customer the vendor is acting for.

• DCreate an IAM role that trusts the vendor's account, and keep the role's ARN private so others can't use it

  Incorrect

  Role ARNs are not secrets. Another customer of the vendor could submit this ARN, and without an external ID the vendor would assume the role for them.

The confused deputy problem is about the vendor being tricked into acting for the wrong customer. A per-customer external ID in the trust policy is the documented guard.

• AMove the access key into AWS Secrets Manager and have the app fetch it at startup

  Incorrect

  The key is better protected, but it is still a long-term credential. AWS recommends temporary credentials from roles for workloads.

• BPut the access key in an environment variable instead of the configuration file

  Incorrect

  An environment variable is just another place on the instance to store the same long-term key.

• CAttach an IAM role to the instance through an instance profile and remove the key

  Correct

  A role delivers temporary credentials to the instance automatically, and its policy can allow only that one bucket.

• DKeep the key but rotate it every 30 days with a scheduled script on the instance

  Incorrect

  Rotation shortens the exposure window, but the application still depends on a long-term key on the instance.

Workloads on AWS should use IAM roles with temporary credentials. Storing or rotating a long-term key better is still storing a key.

• ATag principals and resources by project and allow actions only when the tags match

  Correct

  Attribute-based access control compares principal and resource tags, so new projects need new tags, not new policies.

• BWrite one customer managed policy per project and attach it to that project's IAM roles

  Incorrect

  This is the traditional role-based model: every new project or resource means writing or updating a policy.

• CAttach a permissions boundary for each project to every developer role in the account

  Incorrect

  Boundaries cap permissions but still have to be written per project, and they grant nothing on their own.

• DGive each project its own SCP that lists the resource ARNs its developers may use

  Incorrect

  SCPs apply to whole accounts or OUs and never grant permissions, so they cannot separate projects that share an account.

When resources and teams grow faster than policies can be written, use ABAC: one policy that compares tags.

• ACreate the accounts in AWS Organizations by hand and write all SCPs from scratch

  Incorrect

  It can be done, but the company would design, build and maintain every account and guardrail itself.

• BTurn on IAM Identity Center and give each team permission sets in one account

  Incorrect

  Identity Center manages workforce access; it does not build a multi-account structure with guardrails.

• CDeploy AWS Config rules in a single account to flag resources that break policy

  Incorrect

  Config rules detect noncompliant resources but do not create accounts or preventive guardrails.

• DSet up an AWS Control Tower landing zone with its controls and Account Factory

  Correct

  Control Tower builds a best-practice multi-account landing zone, applies controls, and provisions accounts through Account Factory.

A ready-made, governed multi-account setup is what AWS Control Tower orchestrates on top of AWS Organizations.

• AAdd an object ACL that grants account B read access to each of the objects

  Incorrect

  With ACLs disabled, the bucket owner manages access only through policies; ACLs no longer affect access.

• BAdd a bucket policy in account A that allows account B's role to read

  Correct

  The bucket owner must grant cross-account permission in the bucket policy.

• CGrant account B access to the encryption key in the key's key policy

  Incorrect

  SSE-S3 uses keys that Amazon S3 manages; there is no KMS key policy to edit.

• DAttach an IAM policy to the role in account B that allows s3:GetObject

  Correct

  The caller's own account must also allow the action; a bucket policy alone is not enough for a role in another account.

• EAttach an SCP to account B that allows s3:GetObject on that bucket

  Incorrect

  SCPs never grant permissions; they only limit what identity policies can allow.

Cross-account S3 access needs both sides: the bucket policy in the owning account and an identity policy in the caller's account.

• ATurn on Amazon Macie across all accounts and review its findings for each bucket

  Incorrect

  Macie focuses on S3 data security and sensitive data. It does not analyze KMS key policies or IAM role trust policies.

• BCreate an IAM Access Analyzer analyzer with the organization as its zone of trust

  Correct

  Access Analyzer reviews resource policies and creates a finding for each resource shared outside the zone of trust, re-checking changed policies within about 30 minutes.

• CRun AWS Trusted Advisor checks in the management account and review the results

  Incorrect

  Trusted Advisor gives best-practice recommendations; it is not a policy analyzer for external access across these resource types.

• DQuery CloudTrail Lake each day for API calls made by principals in other accounts

  Incorrect

  CloudTrail records activity that already happened. It does not show access that a policy grants but that nobody has used yet.

"Which policies grant outside access" is a question about policies, not activity. IAM Access Analyzer answers it with logic-based analysis.