Task 2.1: Implement authentication and/or authorization for applications and AWS services

• AA Cognito identity pool that exchanges the token for temporary role credentials

  Correct

  An identity pool exchanges a user pool token for temporary AWS credentials. The role's policy can use the cognito-identity.amazonaws.com:sub variable to limit each user to their own prefix.

• BAn IAM user for each app user, with that user's access keys stored in the app

  Incorrect

  Access keys are long-term credentials. IAM best practices call for temporary credentials through federation and roles instead.

• CA bucket policy that allows anyone to call PutObject under an uploads/ prefix

  Incorrect

  This makes the bucket writable by the public, which S3 Block Public Access exists to prevent, and it cannot limit a user to their own prefix.

• DA Lambda authorizer that checks the user pool token before each upload to S3

  Incorrect

  Lambda authorizers control access to API Gateway methods. They play no part in requests that the app sends straight to Amazon S3.

User pools authenticate users; identity pools turn that authentication into scoped, temporary AWS credentials for direct calls to AWS services.

• AIAM authorization on every route of the HTTP API

  Incorrect

  IAM authorization requires clients to sign requests with AWS credentials using Signature Version 4. A JWT from the identity provider is not an AWS credential.

• BA Lambda authorizer that fetches the provider's keys and validates each token

  Incorrect

  A Lambda authorizer can validate JWTs, but it is code to write, test and run, which the built-in JWT authorizer makes unnecessary here.

• CA JWT authorizer set to the provider's issuer URL and the API's audience

  Correct

  A JWT authorizer validates the token's signature with the issuer's public keys and checks the issuer, audience, expiry and optional scopes before API Gateway calls the route.

• DAn Amazon Cognito user pool authorizer that points at the provider

  Incorrect

  A COGNITO_USER_POOLS authorizer is a REST API feature that accepts tokens from an Amazon Cognito user pool. These tokens come from another provider.

HTTP APIs have a built-in JWT authorizer for any OIDC or OAuth 2.0 issuer; Lambda authorizers are for logic the built-in authorizers cannot express.

• AMove the access keys from the file into environment variables on the instance

  Incorrect

  Environment variables are one of the places the SDK looks for credentials, but the keys would still be long-term credentials on the instance.

• BAttach an IAM role through an instance profile and delete the keys

  Correct

  The role's temporary credentials are delivered through instance metadata and refreshed automatically, and the SDK's default chain finds them without code changes.

• CKeep the keys in AWS Secrets Manager and read them at startup

  Incorrect

  The keys would still be long-term IAM user credentials. For workloads on AWS compute, best practice is temporary credentials from an IAM role.

• DCall GetSessionToken with the stored keys at startup and use the result

  Incorrect

  GetSessionToken must be called with the long-term credentials of an IAM user, so the keys would have to stay on the instance.

On EC2, Lambda, ECS and other AWS compute, give the workload an IAM role and let the SDK's credential chain pick up its temporary credentials.

• AIn account B, a role that can read the table and trusts the function's execution role

  Correct

  To be assumed from another account, a role must trust that account or principal in its trust policy, and its permissions policy defines what the temporary credentials can do.

• BIn account A, a trust policy on the function's execution role that names account B

  Incorrect

  A role's trust policy controls who may assume that role. Trusting account B on the execution role would let B assume it, the opposite direction.

• CIn account A, a policy on the execution role that allows sts:AssumeRole on the role in account B

  Correct

  For a role in a different account, the caller also needs permission from its own account: a policy that allows AssumeRole for that role's ARN.

• DIn account B, an IAM user whose access keys are stored in the function's environment variables

  Incorrect

  Access keys are long-term credentials and are not part of assuming a role. Workloads on AWS should use temporary credentials from roles.

• EIn account B, a permissions boundary on the role that names account A

  Incorrect

  A permissions boundary only limits the maximum permissions of a user or role. It grants nothing and does not establish trust.

Cross-account role assumption needs both sides: the role's trust policy in the resource account and an sts:AssumeRole allow in the caller's account.

• ARequire an API key on the DELETE method and give keys only to admin clients

  Incorrect

  API keys identify clients for usage plans. They say nothing about the OAuth scopes that a user was granted.

• BA token validation expression on the authorizer that checks the aud claim

  Incorrect

  Token validation checks the audience of an identity token. It applies to every method that uses the authorizer and does not check scopes.

• CA resource policy that allows DELETE only from the admin team's IP ranges

  Incorrect

  Resource policies can limit callers by account, source IP range or VPC endpoint. They cannot check scopes in a token.

• DAuthorization scopes on the DELETE method that list orders/admin

  Correct

  When a method lists authorization scopes, the Cognito authorizer accepts an access token in the Authorization header and allows the call only if the token carries one of the listed scopes.

ID tokens authorize by identity claims; access tokens with custom scopes authorize per method. Listing scopes on one method changes only that method.

• AIAM authorization that allows the task role, with SigV4-signed calls

  Correct

  With AWS_IAM authorization, callers sign requests with their AWS credentials, and API Gateway checks for execute-api:Invoke permission. The task role's credentials are temporary and delivered to the container.

• BCreate an API key for the payments service and require API keys on the method

  Incorrect

  API Gateway advises against using API keys for authentication or authorization; they are for usage plans and throttling.

• CKeep a shared password in AWS Secrets Manager and check it in the ledger code

  Incorrect

  Secrets Manager can store and rotate the password, but it is still a shared secret, which the team wants to avoid when the task role can sign requests.

• DAllow only the payments service's security group in the API's resource policy

  Incorrect

  Resource policies can allow AWS accounts, source IP ranges, VPCs or VPC endpoints. A security group is not one of them, and it is not an identity.

For service-to-service calls on AWS, IAM authorization with SigV4 uses the caller's role instead of secrets the services must share.

• ATurn off Block Public Access and allow public PutObject for the upload prefix

  Incorrect

  Public write access lets anyone upload to the bucket. S3 Block Public Access exists to keep buckets from being opened this way.

• BPost each video to the HTTP API so that the function writes it to the bucket

  Incorrect

  The video would pass through the backend, and an HTTP API accepts payloads of at most 10 MB.

• CReturn a presigned PUT URL for one object key, created by the function

  Correct

  A presigned URL lets the browser upload that object without AWS credentials of its own. It carries the signer's permissions and is valid only until it expires.

• DTurn on S3 Transfer Acceleration for the bucket and upload from the browser

  Incorrect

  Transfer Acceleration speeds up long-distance transfers through edge locations. The browser would still need permission to write.

Presigned URLs delegate one specific, time-limited S3 operation to a client that has no AWS credentials.

• AThe read is denied, because the role's identity-based policy must also allow it

  Incorrect

  Within one account, an allow in either the identity-based policy or the resource-based policy is enough.

• BThe read is denied, because bucket policies apply only to other accounts

  Incorrect

  Bucket policies grant access to principals in the same account as well as in other accounts.

• CThe read is allowed only after the role is added to an S3 access control list

  Incorrect

  ACLs are not needed; the bucket policy already allows the action.

• DThe read is allowed, because the bucket policy grants the permission

  Correct

  For a request in the same account, the effective permissions are the union of identity-based and resource-based policies, unless a Deny applies.

Same-account access needs an allow in either kind of policy; cross-account access needs an allow on both sides.

• AOptional MFA with SMS text messages as the only factor

  Incorrect

  Optional MFA lets users skip it, and SMS is not an authenticator app.

• BRequired MFA with time-based one-time passwords (TOTP)

  Correct

  With MFA required, all users must complete MFA to sign in, and TOTP codes come from an authenticator app.

• CA longer minimum password length in the password policy

  Incorrect

  A stronger password is still a single factor, not a second one.

• DAn identity pool that issues AWS credentials after sign-in

  Incorrect

  Identity pools exchange tokens for AWS credentials; they do not add a sign-in factor.

User pools support SMS, email and TOTP as MFA factors, which can be set to optional or required.

• ACreate access keys for an IAM user and use them in the script

  Incorrect

  This swaps temporary credentials for long-term ones, which the team wants to avoid.

• BRun the script from AWS CloudShell, which has no limits on role session length

  Incorrect

  Moving the script does not change how long the assumed role session lasts.

• CRaise the role's maximum session duration and request a longer session

  Correct

  A role's maximum session duration can be set from 1 to 12 hours; the default is 1 hour.

• DAttach the AdministratorAccess policy to the role

  Incorrect

  More permissions do not lengthen a session, and they break least privilege.

Long-running jobs with assumed roles need a longer maximum session duration on the role, up to 12 hours.

• AA resource policy that denies requests whose aws:SourceIp is outside the range

  Correct

  API Gateway resource policies can allow or deny API traffic based on the source IP address or range.

• BA usage plan with an API key that only staff in the office network receive

  Incorrect

  API keys can be shared and are not meant for access control; they do not check the source IP address.

• CA Cognito user pool authorizer that office staff sign in to

  Incorrect

  A user pool authorizer checks who the user is, not which network the request comes from.

• DAn edge-optimized endpoint so that every request passes through CloudFront first

  Incorrect

  The endpoint type does not restrict which IP addresses may call the API.

Resource policies with aws:SourceIp conditions limit REST APIs to known network ranges.

• AStore access keys in the application's configuration file instead

  Incorrect

  This replaces temporary role credentials with long-term keys on disk, which weakens security.

• BBlock outbound internet access from the instance

  Incorrect

  Metadata requests stay on the instance; blocking internet traffic does not change which metadata version is accepted.

• CConfigure the instances to require IMDSv2

  Correct

  IMDSv2 is the session-oriented method, and an instance can be set to accept only IMDSv2 calls so that IMDSv1 calls fail.

• DTurn off the instance profile and call AWS STS from the code

  Incorrect

  Calling STS needs credentials to sign the request, so the application would need long-term keys.

Requiring IMDSv2 adds defense in depth for instance credentials obtained from instance metadata.