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"}} } ```

• A`s3:*` 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
• C`LimitExceededException` 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