Day 5 - Week 1 Review: The Chain of Trust Built by Infrastructure and IAM

A company issues IAM Users to all employees, who use access keys with the CLI. Following a security audit, the CISO has ordered "no more long-term keys". What is the most appropriate migration?

• ARotate IAM User access keys every 30 days and detect unused keys with CloudTrail to auto-deactivate them — operations improve, but long-term keys themselves remain
• BAdopt AWS IAM Identity Center (SSO) + integrate an external IdP + use the CLI with aws configure sso
• CPut MFA on the root account and have all employees share it while auditing sessions with CloudTrail — credential sharing itself is the worst possible security failure
• DIssue every employee a dedicated EC2 instance and access via instance profile Roles to eliminate keys — keys disappear, but per-employee EC2 cost and operations are unrealistic

What is the effect of the following IAM policy? ```json { "Effect": "Allow", "Action": "s3:*", "Resource": "arn:aws:s3:::project-${aws:PrincipalTag/Project}/*", "Condition": {"Null": {"aws:PrincipalTag/Project": "false"}} } ```

• As3:* is evaluated without the Condition, unconditionally allowing all actions on every S3 bucket in the account
• BPrincipals that have a Project tag are allowed all S3 actions only on buckets whose prefix matches that tag's value
• CThe ${aws:PrincipalTag} variable is not supported in Resource ARNs, so the policy always evaluates to deny at validation
• DBecause the Resource ARN contains a variable, it applies only to the root account (the account-id owner) and is void for IAM Users

After moving a workload from EC2 to Lambda, you want it to run with the same IAM policies without code changes. What changes?

• ALambda has no instance profile so it cannot use IAM Roles and keys must be injected via environment variables — in reality, Lambda uses a Role as its execution role just fine
• BThe Principal in the Lambda execution role's Trust Policy must change from ec2.amazonaws.com → lambda.amazonaws.com
• CLambda has restricted STS access, so access keys must be stored in code or Secrets Manager and loaded explicitly — Lambda receives temporary credentials automatically
• DThe Trust Policy is service-agnostic, so attaching the Role as-is works with no code or config changes — the Principal Service differs, so the assume fails

Which of the following is NOT included in an STS AssumeRole response?

• AAccessKeyId — an access key ID starting with the ASIA prefix indicating a temporary key
• BSecretAccessKey — the secret access key used for SigV4 request signing
• CSessionToken — the session token that must accompany every call made with temporary credentials, sent as a header
• DThe IAM User's console login password — a permanent password returned alongside for credential recovery

A company has set an SCP allowing "only us-east-1 and ap-northeast-2". An IAM User has AdministratorAccess. This User attempts to launch an EC2 in eu-west-1. What happens?

• AThe identity-based AdministratorAccess is an explicit Allow, which takes precedence over the Organizations SCP region restriction, so it is allowed
• BThe SCP's Deny takes precedence and it is denied
• CThe SCP only disables the console region selector, so the eu-west-1 EC2 launches normally via CLI or SDK
• DAn aws:RequestedRegion violation is a soft warning, so only a warning banner appears in the console and the instance is created

What is the most appropriate first debugging step in this scenario? "boto3 code on EC2 returns An error occurred (AccessDenied) when calling the GetObject operation."

• ADisable the S3 bucket's Block Public Access and open the bucket policy to public-read to check access — this is the road to a security incident, not root-cause diagnosis
• BRun aws sts get-caller-identity to check which Role/User is currently in effect
• CInject IAM root credentials into the instance to check whether it works — putting root keys on EC2 is absolutely forbidden
• DRestart the EC2 instance to refresh the instance profile credential cache — AccessDenied is a permission problem, not a cache problem, so this is irrelevant

A developer configured a dev profile in ~/.aws/credentials, but unless --profile dev is specified on the CLI command, the default profile's credentials are used. How can the dev profile be applied automatically to every command?

• APoint the default profile at dev with aws configure set profile dev — no such configuration key exists, so this is void
• BSet the AWS_PROFILE=dev environment variable
• COverwrite the [default] block in ~/.aws/config with dev's credentials — it works, but blurs the boundary between profiles
• DRe-run aws configure --profile dev to re-register dev as the highest-priority profile — this only updates values and does not change the default selection

In an IAM Policy's "Resource": "arn:aws:s3:::my-bucket/${aws:username}/*", when is the ${aws:username} variable evaluated?

• AIt is substituted once with the author's username at policy authoring/save time and fixed
• BIt is bound to the entity's name at the moment the policy is attached to an IAM entity
• CAt API call time (dynamically substituted with the caller's information)
• DVariables are not supported in IAM policies, so it matches the literal string ${aws:username} as-is

What error appears when SigV4 signature timestamp validation fails?

• AAccessDenied — a permission-denied error returned as an IAM permission evaluation failure
• BSignatureDoesNotMatch or RequestTimeTooSkewed
• CThrottlingException — a throttling error from exceeding request rates that triggers SDK retries
• DServiceUnavailable — a 5xx-class error indicating a transient server-side failure

A company separates prod and dev accounts with AWS Organizations, and developers can assume Roles in both accounts via IAM Identity Center. Why is prod protected even if a major incident happens in the dev account?

• AWithin the same Organizations, AWS automatically detects the blast radius and isolates the incident account from the network — no such automatic isolation feature exists
• BWith OU separation in Organizations, an IAM Principal crossing account boundaries requires explicit cross-account permissions, and SCPs can add further isolation
• CThe moment prod is registered as a member account, it is automatically locked read-only by SCP — no such default behavior exists
• DAll cross-account actions are automatically blocked and audited by CloudTrail so incidents don't propagate — CloudTrail only records, it never blocks

A Lambda function received a LimitExceededException. What is the SDK's default retry behavior?

• AThrottling-class errors have no idempotency guarantee, so the exception propagates immediately after 1 attempt with no retry
• BStandard retry mode: 3 additional attempts + exponential backoff with jitter
• CLimitExceededException is classified as recoverable, so it retries infinitely without backoff until it succeeds
• DWhen the calling region is throttled, the SDK automatically fails over to another regional endpoint in the same partition and retries

A company wants to let a SaaS monitoring tool read CloudWatch metrics from its AWS account. What is the safest configuration?

• ACreate a dedicated IAM User, grant only CloudWatchReadOnlyAccess, hand the access key to the SaaS, and rotate every 90 days — handing long-term keys to an external party is an anti-pattern
• BCreate an IAM Role, specify the SaaS's account ID + an External ID condition in the Trust Policy, and grant only ReadOnlyAccess
• CIssue a separate access key on the root account, restrict it to ReadOnly, and provide it to the SaaS — issuing/sharing root keys is the worst possible security failure
• DExpose CloudWatch metrics to the SaaS account via cross-account sharing and allow reading without authentication — unauthenticated exposure violates least privilege