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.

• ✗

  Enable AWS CloudTrail in all accounts and aggregate logs.

  Why it's wrong here

  Enabling AWS CloudTrail in all accounts and aggregating logs into a central bucket or account provides critical detective visibility, but it cannot enforce least privilege. CloudTrail only records API activity as event history; it does not evaluate, limit, or deny actions at runtime. A principal with overly broad permissions can still take harmful actions, and the logs merely record that the action occurred, making this a necessary but insufficient control for a governance framework.

• ✗

  Grant full administrative access to a central security group.

  Why it's wrong here

  Creating a central IAM group and granting it full administrative access (for example, via the AdministratorAccess managed policy) violates the least-privilege principle by giving every member of that group sweeping, standing permissions across all resources. Even though the group is centrally managed, the permissions are not scoped by resource, action, condition, or sensitivity, so a single compromised identity or insider can perform any operation in the account. Centralizing broad rights is not the same as governing them; least privilege requires narrow, conditional, and often temporary permissions.

• ✗

  Use a single IAM user across all accounts for administrative tasks.

  Why it's wrong here

  Using a single IAM user across all accounts for administrative tasks forces the sharing of long-lived static credentials (passwords or access keys), which are not tied to a single human or workload and create severe auditability gaps. If those shared credentials are compromised, attackers gain access to every account the user can reach, and AWS CloudTrail logs cannot reliably attribute events to a specific individual. This approach also violates least privilege because the shared user must hold the union of all necessary permissions across accounts, far exceeding what any one task or administrator actually needs.

• ✓

  Use IAM roles with specific permissions and trust policies for cross-account access.

  Why this is correct

  IAM roles with specific permission policies and trust policies enable cross-account access by allowing principals from a trusted account to assume the role and receive temporary, scoped AWS credentials through the AWS STS AssumeRole API. The role's trust policy specifies which accounts or principals may assume it, while the permission policy limits what those principals can do after assuming it, providing a true least-privilege mechanism. This is the correct approach because it avoids long-lived credentials, enforces the principle of least privilege, and supports conditions such as MFA, source IP, or session tags for further restriction.

• ✓

  Define service control policies (SCPs) that restrict the maximum permissions per account.

  Why this is correct

  Service control policies (SCPs) act as central guardrails that define the maximum permissions available to every principal within an AWS organization account or organizational unit, without granting any permissions themselves. They operate by filtering out actions that cross the SCP boundary, so even if an IAM role or policy grants a permission, that action is denied when the SCP does not allow it. SCPs are account-level permission boundaries and are foundational for governance frameworks because they let a central security team enforce consistent, organization-wide restrictions while delegating day-to-day permission management to account owners.

Go deeper

Related to this question