SCS-C02 Management and Security Governance 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.

• ✗

  Use a single IAM role for all users in the account.

  Why it's wrong here

  A single shared IAM role collapses every user into one permission set, so assuming the role grants the union of all entitlements, including actions that are irrelevant to most users' job functions. This violates least privilege because the role must be broad enough to accommodate everyone, and it also degrades auditability: CloudTrail logs the role session but not which individual user initiated it unless you add extra context. Least privilege requires separate roles or policies scoped to each user's actual tasks, not one broad role for the entire account.

• ✓

  Grant permissions only for the specific actions required.

  Why this is correct

  Least privilege means constructing IAM policies that explicitly allow only the exact API actions and resources a principal needs for its job function, denying everything else by default. Each Allow statement should enumerate concrete actions such as s3:GetObject on specific resource ARNs rather than using wildcards like s3:* or Action: "*". This minimizes the blast radius if credentials are compromised and ensures that even legitimate users can only perform the minimum operations required to do their work.

• ✗

  Attach IAM policies to groups rather than individual users.

  Why it's wrong here

  Attaching policies to groups is a recommended IAM management practice for consistency and ease of administration, but it does not inherently enforce least privilege. A group can carry a broad, permissive policy like AdministratorAccess that grants far more than any individual member needs, so grouping alone does not narrow the effective permissions. Least privilege is determined by the content of the policy's Action, Resource, and Condition elements, not by the assignment mechanism; groups are simply a tool to apply tightly scoped policies at scale without duplication.

• ✓

  Use conditions in IAM policies to restrict access based on attributes like source IP or time.

  Why this is correct

  IAM Condition elements act as dynamic guardrails that restrict when an Allow statement is effective, allowing you to narrow the permission surface based on context such as aws:SourceIp, aws:CurrentTime, or aws:MultiFactorAuthPresent. For example, you can require that sensitive API calls originate from a corporate CIDR range, that changes only occur during a maintenance window, or that MFA is always present for console access. These conditions reduce standing privileges by preventing access from unexpected networks or outside approved timeframes, even when the Action and Resource fields are already specific.

• ✗

  Always use AWS managed policies instead of customer managed policies.

  Why it's wrong here

  AWS managed policies are convenient because AWS maintains them, but they are designed for broad, common use cases and often include more actions than a particular workload needs. For instance, ReadOnlyAccess grants read access to nearly all AWS services, which is excessive for a principal that only needs to read from S3 and DynamoDB. Least privilege favors scoped customer managed policies (or the least-permissive AWS managed policy that still fits) because they allow you to limit actions and resources precisely to your requirements, avoiding the extra blast radius of a generic managed policy.

Go deeper

Related to this question