CLF-C02 Security and Compliance Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  IAM Conditions

  Why it's wrong here

  IAM conditions are optional clauses within a policy statement that evaluate request context, such as source IP address, user principal, MFA status, or time of day, to determine whether a permission applies at request time. They enable fine-grained control over when and from where a permission can be used, but they never restrict the overall breadth of permissions granted to an IAM entity. A condition can block a specific request (e.g., deny access unless MFA is present), but it does not set an upper bound on the set of actions a user or role can perform across all possible contexts. Thus, conditions are contextual gates, not maximum-permission caps, making them incorrect for the scenario described.

• ✓

  Permission Boundaries

  Why this is correct

  A permission boundary is a managed policy that is explicitly attached to an IAM user or role to define the absolute maximum permissions that entity can be granted. When evaluating an entity's effective permissions, AWS takes the intersection of the identity-based policies (which may grant broad access) and the permission boundary; any action not allowed by the boundary is blocked even if explicitly allowed by an attached policy. This creates a hard ceiling on the entity's permissions, ensuring that even if more permissive policies are attached, the boundary limits what the principal can actually do. Because the question asks for the mechanism that caps the maximum permissions of an IAM entity, permission boundaries are precisely the correct answer.

• ✗

  Service Control Policies (SCPs)

  Why it's wrong here

  Service control policies (SCPs) are an AWS Organizations feature that applies to member accounts, organizational units, or the entire organization, and they set maximum permission limits for all IAM principals (users and roles) within those scopes. However, SCPs do not attach to individual IAM users or roles within an account; they operate at the account or OU level as a guardrail on the overall account's allowable permissions. In contrast, permission boundaries are attached directly to a specific IAM user or role, allowing per-entity customization of maximum permissions. Because the question targets an individual IAM entity's maximum permissions rather than an account-wide restriction, SCPs are not the correct mechanism.

• ✗

  Resource-based policies

  Why it's wrong here

  Resource-based policies are attached directly to resources such as S3 buckets, KMS keys, or SNS topics, and they specify which principals (IAM users, roles, or AWS services) can access that specific resource. These policies grant cross-account or cross-service access, but they do not place any cap on the maximum permissions that an IAM entity can hold. Instead, they expand who can use a resource, while the requesting principal's effective permissions are still governed by its own identity-based policies and any permission boundary that may be attached. Therefore, resource-based policies cannot limit an entity's maximum permission level; they only define resource access.

Go deeper

Related to this question