Task 4.2: Design, implement, and troubleshoot authorization strategies

• AAn SCP on account B that allows s3:GetObject for principals in account A

  Incorrect

  SCPs never grant permissions; they only limit principals in member accounts.

• BAn identity policy on the role that allows s3:GetObject and kms:Decrypt

  Correct

  For cross-account access, the caller's own account must also allow the actions, for S3 and for the key.

• CA bucket policy in account B that allows the role to call s3:GetObject

  Correct

  The bucket owner must grant the other account's principal access in a resource-based policy.

• DTurn off the S3 Block Public Access settings for the bucket in account B

  Incorrect

  A bucket policy that grants a fixed principal is not public, so Block Public Access does not need to change.

• EA key policy statement in account B that allows the role kms:Decrypt

  Correct

  Cross-account use of a KMS key needs permission in the key policy and in an IAM policy in the external account; neither is enough alone.

• FChange the bucket's default encryption from SSE-KMS to SSE-S3

  Incorrect

  Default encryption applies to new objects. The existing objects stay encrypted with the KMS key.

Cross-account access needs an allow on both sides: the caller's identity policy and the resource owner's policy, and with SSE-KMS the key policy is a second resource owner to satisfy.

• AAttach DevBoundary as the permissions boundary of the developers' own role

  Incorrect

  That caps what developers can do themselves, but the roles they create would have no boundary.

• BAllow iam:CreateRole only if iam:PermissionsBoundary is DevBoundary; deny its removal

  Correct

  The condition makes role creation fail unless DevBoundary is set as the boundary, and the deny stops developers from removing it.

• CAttach an SCP that denies iam:CreateRole in the development account

  Incorrect

  This stops developers from creating roles at all, which they need to do.

• DRequire a project tag on each new role with the aws:RequestTag condition key

  Incorrect

  A tag on the role does not limit what the role is allowed to do.

Delegated role creation is safe when the boundary is a condition of the create call and cannot be deleted afterwards.

• AOne permission set per project whose policy lists the instance ARNs of that project

  Incorrect

  This is role-based access: every new project or instance means editing policies.

• BA permissions boundary per project that names that project's instance ARNs

  Incorrect

  Boundaries cap permissions but still list resources, so they also need changes as projects and instances are added.

• CA resource-based policy on each instance that allows that project's engineers

  Incorrect

  EC2 instances do not have resource-based policies for this kind of access.

• DOne permission set that matches aws:ResourceTag/project to aws:PrincipalTag/project

  Correct

  Attribute-based access matches the principal's tag to the resource's tag, so new projects and instances work without policy changes.

ABAC lets one policy follow the attributes. Identity Center can pass directory attributes as session tags for exactly this purpose.

• AAmazon Verified Permissions with Cedar policies

  Correct

  Verified Permissions provides fine-grained authorization for custom applications, with Cedar policies stored and evaluated outside the application code.

• BCognito user pool groups mapped to IAM roles with different permissions

  Incorrect

  Groups and IAM roles control access to AWS resources. They cannot express per-document rules inside the application.

• CAn API Gateway resource policy for each tenant

  Incorrect

  A resource policy controls who may invoke the API. It knows nothing about documents, owners or sharing.

• DIAM policies with ABAC conditions on Cognito attributes

  Incorrect

  IAM evaluates calls to AWS services. Documents stored by the application are not AWS resources that IAM can authorize.

Authorization of an application's own resources belongs in a policy decision point such as Verified Permissions; IAM covers calls to AWS.

• AIAM Roles Anywhere with the company CA as a trust anchor

  Correct

  Roles Anywhere exchanges a certificate from a trusted CA for temporary credentials of a role, so no long-term keys are needed.

• BRotate the IAM user access keys every 30 days with Secrets Manager

  Incorrect

  Rotation shortens exposure but the keys are still long-term credentials.

• CCognito identity pool guest access for the servers

  Incorrect

  Guest identities are unauthenticated, so any caller could get the credentials; that is not workload authentication.

• DSTS GetFederationToken called with each server's IAM user keys

  Incorrect

  GetFederationToken still needs the long-term IAM user keys to call it.

Workloads outside AWS that already hold certificates can trade them for role credentials through Roles Anywhere.

• AThe vendor's AWS account ID as the principal

  Correct

  The trust policy names the third party's account as the principal allowed to assume the role.

• BAn aws:PrincipalOrgID condition with the company's organization ID

  Incorrect

  The vendor's account is outside the company's organization, so this condition would block the vendor.

• CAn aws:MultiFactorAuthPresent condition set to true

  Incorrect

  The vendor's software assumes the role programmatically. MFA does not tell one customer's request from another's.

• DAn sts:ExternalId condition with a value unique to the company

  Correct

  An external ID unique to each customer addresses the confused deputy problem.

• EAn aws:SourceIp condition with the vendor's published IP ranges

  Incorrect

  Requests for every customer come from the same vendor addresses, so this does not stop the confused deputy.

Third-party roles need two things: the vendor's account as principal and an external ID unique to you. The external ID is not a secret.

• AAdd an explicit allow for s3:PutBucketPolicy to the role's identity-based policy

  Incorrect

  The identity policy already allows it. An SCP limits what the identity policy can grant, so adding more allows does not help.

• BAdd an allow for s3:PutBucketPolicy to the SCPs that apply to the account

  Correct

  The message names an implicit denial: no SCP in the account's path allows the action, so an SCP must allow it.

• CRemove a Deny statement for s3:PutBucketPolicy from the account's SCPs

  Incorrect

  An explicit deny produces a message that says "with an explicit deny in a service control policy", which is not this message.

• DGrant the role s3:PutBucketPolicy in the bucket policy

  Incorrect

  Resource-based policies cannot override SCP limits on principals in the member account.

Read the wording of the error: "no ... policy allows" is an implicit deny, "with an explicit deny in a ..." points to a Deny statement.

• AThe delete succeeds, because the identity policy allows it

  Incorrect

  An explicit deny overrides any allow.

• BThe delete succeeds, because policies are combined with OR

  Incorrect

  Allows combine, but an explicit deny still wins.

• CThe delete fails, because the explicit deny wins

  Correct

  An explicit deny in either an identity-based or a resource-based policy overrides the allow.

• DThe delete fails, because bucket policies cannot name users

  Incorrect

  Bucket policies can name IAM users as principals.

Explicit deny always wins, which makes it the tool for guardrails.

• ANo, KMS keys never consider IAM policies

  Incorrect

  The default key policy lets the account use IAM policies for the key.

• BNo, the role must be named in a grant first

  Incorrect

  Grants are one option, but not required here.

• CYes, but only when the key is an AWS managed key

  Incorrect

  This works for customer managed keys with the default key policy.

• DYes, the default key policy enables IAM policies

  Correct

  The default key policy gives the owning account permission to use IAM policies to allow access to the key.

If a custom key policy removes that statement, IAM policies alone stop working for the key.

• AThe IAM policy simulator

  Correct

  The policy simulator tests identity-based policies, boundaries and other policies against chosen actions.

• BCloudTrail event history

  Incorrect

  Event history shows calls that happened, not what a policy would do.

• CThe IAM credential report

  Incorrect

  The credential report lists credentials, not policy decisions.

• DAWS Trusted Advisor

  Incorrect

  Trusted Advisor runs checks; it does not simulate a policy.

Pair the simulator with IAM Access Analyzer policy validation to catch errors and security warnings.

• AAttach the same inline policy to each user

  Incorrect

  Copies on each user are hard to keep in sync.

• BPut the users in an IAM group with the policy

  Correct

  Groups let you specify permissions for multiple users at once, so adding or removing a user changes their access.

• CCreate one shared IAM user for all twenty people

  Incorrect

  Shared credentials remove individual accountability.

• DSet a permissions boundary on each of the users

  Incorrect

  Boundaries only limit permissions; they do not grant them.

For people, federation with groups in the identity provider is the longer-term answer.

• AUnused access findings

  Incorrect

  These report access that is granted but not used.

• BExternal access findings

  Incorrect

  These report resources shared outside a zone of trust.

• CPolicy generation from CloudTrail activity

  Incorrect

  Generation drafts a policy from activity; it does not check one.

• DPolicy validation

  Correct

  Policy validation checks policies against IAM grammar and best practices, returning errors and security warnings.

Fail the build on errors and security warnings; review general warnings and suggestions.