SCS-C02 Management and Security Governance Practice Question

Which THREE are best practices for managing security in a multi-account AWS environment? (Choose three.)

⚠ Common exam trap

SCS-C02 often tests the misconception that cost optimization justifies disabling CloudTrail or that root user access is acceptable for admin tasks — both are anti-patterns that violate core security best practices.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Use SCPs to restrict permissions across accounts.

Option A is correct because AWS Organizations Service Control Policies (SCPs) are applied at the OU or account level and set the maximum available permissions for all IAM principals in member accounts, providing a centralized guardrail to restrict permissions across accounts. Option C is correct because a dedicated security account isolates security tooling (such as GuardDuty, Security Hub, and IAM Access Analyzer) and audit activities from production workloads, following AWS's recommended multi-account security structure. Option D is correct because centralizing logs in a dedicated security account (often via AWS Organizations CloudTrail organization trails and cross-account log destinations) protects audit data from tampering by account owners and enables unified monitoring and retention. Option B is incorrect because disabling CloudTrail removes the audit trail needed for incident response, compliance, and forensics; CloudTrail is a foundational detective control, not an optional cost to cut. Option E is incorrect because the root user has unrestricted access that cannot be limited by SCPs or IAM policies, so it should be locked away with MFA and never used for routine administrative tasks; least-privilege IAM roles or federated identities should be used instead.

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 SCPs to restrict permissions across accounts.
Why this is correct
SCPs provide central control over every account's permissions by acting as a permission filter on all IAM principals in AWS Organizations' organizational units. They can deny services or actions even if the account's own IAM policies allow them, but they do not grant access themselves; instead, SCPs set a boundary that effects only the accounts they are attached to, ensuring that even root users of member accounts cannot perform unauthorized operations.
✗
Disable AWS CloudTrail in production accounts to reduce costs.
Why it's wrong here
CloudTrail is essential for auditing, so disabling it in production accounts destroys the record needed to investigate security incidents, compliance violations, and unauthorized access. While CloudTrail has a cost, you can minimize expenses by enabling organization trails, filtering data events, and applying S3 lifecycle rules to move logs to cheaper storage—not by turning the service off entirely. Without audit logs, you lose the ability to detect attacks, troubleshoot access issues, or prove compliance with regulatory requirements.
✓
Use a dedicated security account for security tools and audits.
Why this is correct
A dedicated security account establishes a strong isolation boundary for security tools such as AWS GuardDuty, IAM Access Analyzer, and AWS Config, preventing the security tooling from sharing an environment with production workloads. This account centralizes cross-account security roles so that security administrators have a single privileged access point, reducing the blast radius if a workload account is compromised. It also simplifies auditing by consolidating security configurations and permissions in one place, far from the accounts that the tools are designed to monitor.
✓
Centralize logging in a dedicated security account.
Why this is correct
Centralizing logging in a dedicated security account aggregates logs—including CloudTrail events, VPC Flow Logs, and AWS Config snapshots—from all accounts into a single S3 bucket or CloudWatch Logs destination. This design allows you to apply uniform retention, encryption, and access control policies, correlate events across accounts to detect multi-account attacks, and protect logs from tampering by separating the logging pipeline from the accounts being audited. It also reduces duplication, simplifies operational monitoring, and streamlines integration with SIEM tools while keeping log data out of the hands of normal application teams.
✗
Use the root user of each account for administrative tasks.
Why it's wrong here
The root user of an AWS account has unrestricted access and should never be used for routine administrative tasks because its credentials cannot be scoped by SCPs, and any leak or accidental misuse can result in full account compromise. Root access is intended only for a small set of account management actions, such as changing support plans, closing the account, or recovering the account after an IAM misconfiguration. Instead, administrators should assume IAM roles with least privilege and require MFA for all human interaction, and the root account itself should have MFA enabled and no static access keys.

Go deeper

SCS-C02 Management and Security Governance Practice Question

Why each option matters

Option-by-option breakdown

Related to this question