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 wildcards (*) to simplify policy management

  Why it's wrong here

  Using wildcard characters such as 's3:*' in the Action element or '*': '*' in the Resource element may simplify policy creation by removing the need to enumerate every ARN and action, but this directly violates least privilege by granting access to all current and future resource types, including those the workload does not require. Wildcards also make it difficult to perform security reviews and compliance audits because the effective permission boundary is ambiguous, and they increase the blast radius if a principal's credentials are compromised. AWS best practice is to avoid wildcards entirely except in tightly controlled cases, such as allowing 's3:GetObject' on a prefix pattern, never for the whole service or account.

• ✗

  Use inline policies instead of managed policies

  Why it's wrong here

  Inline policies are bound to a single principal and cannot be reused across multiple users, roles, or groups, whereas managed policies are standalone objects that can be attached to multiple principals and centrally versioned, making them the recommended approach for scalable permission management. This option is tempting because inline policies offer precise, one-off customisation for a specific resource, and they are the correct choice when you need to enforce a policy that must never be inadvertently attached to another principal, such as a tightly scoped permissions boundary for a single service account.

• ✗

  Use SCPs to enforce permissions

  Why it's wrong here

  Service Control Policies (SCPs) are a feature of AWS Organizations that centrally restrict the maximum permissions available to accounts within an organization, but they are not IAM policies and cannot be attached to users, groups, or roles. SCPs never grant permissions; they act as a filter on top of IAM policies, only denying or allowing what IAM policies would otherwise permit, and they apply only to accounts under an organization root or OU. Therefore, using SCPs to 'enforce permissions' is not a valid IAM policy management practice because IAM remains the authoritative layer for identity-based and resource-based permission assignment for individual principals.

• ✓

  Grant least privilege by using specific actions and resources

  Why this is correct

  Granting least privilege means constructing IAM policies so that every Action and Resource element is scoped to the specific operations and ARNs the principal actually needs, and where applicable adding condition keys such as 'aws:PrincipalTag' or 'aws:RequestedRegion' to further constrain access. For example, instead of allowing 's3:ListBucket' on all buckets, the policy should list the exact bucket name in the Resource and restrict the action to relevant key prefixes, while also avoiding overly broad Principal elements in resource policies. This practice reduces the attack surface, limits the impact of compromised credentials, and is a foundational requirement of the AWS Well-Architected Framework's security pillar.

• ✓

  Use AWS managed policies when possible

  Why this is correct

  AWS managed policies are standalone policies created and maintained by AWS, such as 'AmazonS3ReadOnlyAccess' or 'AWSLambdaBasicExecutionRole', and AWS updates them automatically as services add new actions, which reduces the burden of tracking API changes. Because they are detached from any single IAM principal, they can be attached to multiple users, groups, or roles and are centrally versioned and updated, unlike inline policies that are embedded in one principal and become difficult to reuse or audit at scale. AWS recommends managed policies over inline policies as a best practice because they simplify administration and help ensure permissions stay current, provided you still review each policy's scope to confirm it aligns with least privilege for the intended use case.

Go deeper

Related to this question