Security and Compliance practice questions

Workloads should obtain AWS credentials from IAM roles — for EC2, via an instance profile — instead of long-term access keys stored in files, AMIs, or user data.

An instance profile role gives the application short-lived credentials that AWS rotates automatically, removing the long-term keys entirely. Rotating keys or encrypting the file still leaves durable secrets in an artifact, and user data is even more exposed because it is readable via instance metadata — on this exam, any option that keeps access keys on an instance loses to a role.

1. Create an IAM role with the S3 permissions the application needs.
2. Attach the role to the EC2 instance as an instance profile.
3. Update the application to use the default credential chain instead of the configuration file.
4. Verify the application works, then deactivate and delete the IAM user's access keys.

Exam tip: Replace access keys on EC2 with an instance profile role — short-lived credentials beat any scheme for protecting long-term keys.

Within one account an allow from either an identity-based or a resource-based policy is enough; across accounts, both sides must allow — the caller's identity policy and the target resource's policy.

The identity side is already satisfied, so the missing piece is the bucket policy in account B naming the account A role (or its account) as a principal. Role assumption is an alternative pattern, not a requirement, so options invoking sts:AssumeRole are wrong, and there is no organization-membership prerequisite for cross-account S3 access.

1. Confirm the account A role's identity policy allows s3:PutObject on arn:aws:s3:::bucket/*.
2. Add a bucket policy statement in account B allowing s3:PutObject for the account A role's ARN.
3. Check for explicit denies in the bucket policy that could still override the allow.
4. Retry the upload and confirm success in CloudTrail.

Exam tip: Cross-account access needs an allow on both sides — the caller's identity policy and the resource-based policy on the target.

The aws:PrincipalOrgID condition key, used in resource-based policies, grants access to every principal in an AWS Organizations organization without listing account IDs.

A single condition on the organization ID automatically covers future accounts and excludes external principals. Enumerating account IDs creates permanent maintenance, a public bucket cannot be protected by SCPs (they only apply to your own org's principals), and aws:SourceIp tests where a call comes from rather than who is calling.

1. Find the organization ID in the AWS Organizations console.
2. Write a bucket policy allowing s3:GetObject for Principal "*" with the condition aws:PrincipalOrgID equals the organization ID.
3. Keep S3 Block Public Access enabled — the condition means the policy is not public.
4. Test access from a member account and from an external account to confirm the boundary.

Exam tip: Use aws:PrincipalOrgID in a resource policy to grant org-only access that automatically covers new accounts.

IAM condition keys scope when a policy statement applies; aws:SourceIp restricts requests to a set of source IP CIDR ranges.

Only aws:SourceIp evaluates the caller's IP address, so a Deny when aws:SourceIp is outside the corporate CIDR enforces the office-network rule. The distractors test other request attributes: target Region (aws:RequestedRegion), organization membership (aws:PrincipalOrgID), and MFA context (aws:MultiFactorAuthPresent).

1. Identify the corporate network's public CIDR ranges.
2. Write a Deny statement on the relevant actions with the condition NotIpAddress aws:SourceIp matching those ranges.
3. Attach the policy to the IAM users or their group.
4. Test from inside and outside the corporate network to confirm the boundary, noting that requests through a VPC endpoint will not match a public-IP condition.

Exam tip: aws:SourceIp is the condition key for restricting API calls to specific source networks.

Permissions boundaries cap the maximum permissions of an individual IAM user or role — the effective permission is the intersection of the identity policy and the boundary, and the boundary itself grants nothing.

The standard delegation pattern is to let a team create roles while requiring — via a condition on iam:CreateRole — that every role carries an approved boundary, so even AdministratorAccess attached to the role is capped. Limiting the developers' own permissions does not constrain the roles they mint, and the policy simulator and Access Analyzer are assessment tools that cannot prevent anything.

1. Author the boundary policy defining the approved maximum permissions.
2. Grant developers iam:CreateRole and iam:AttachRolePolicy with a condition requiring the iam:PermissionsBoundary to equal the approved boundary's ARN.
3. Deny iam:DeleteRolePermissionsBoundary so the cap cannot be removed.
4. Test by creating a role with AdministratorAccess attached and confirming its effective permissions stay inside the boundary.

Exam tip: Delegate role creation safely by requiring a permissions boundary — the role's effective permissions can never exceed it.

In IAM policy evaluation, an explicit deny in any applicable policy — identity-based, resource-based, SCP, or boundary — immediately ends evaluation and overrides every allow.

The bucket policy's explicit Deny on the finance/ prefix matches the request, so it is denied despite the user's broad allow. There is no precedence order that favors identity policies, same-account convenience only applies to allows, and a deny never needs to appear in more than one place to take effect.

1. Check whether any applicable policy explicitly denies the action on the resource — if so, the request is denied.
2. Only if no deny matches, check the gates: SCPs and any permissions boundary must allow the action.
3. Finally, look for an allow in an identity-based or resource-based policy.
4. Here, step 1 already resolves it: the bucket policy's explicit deny wins.

Exam tip: An explicit deny anywhere always wins — no allow in any policy can override it.