SCS-C02 Security Logging and Monitoring 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.

• ✗

  Write a script that runs in each account using AWS Lambda to enable CloudTrail and point to the central bucket.

  Why it's wrong here

  A script running per account via Lambda cannot enforce compliance across all accounts in AWS Organizations because it lacks the organisational-level governance to prevent accounts from disabling or altering CloudTrail after deployment. This approach is tempting because it automates initial configuration in individual accounts, and it would be correct for a single-account environment or a non-Organizations setup where centralised policy enforcement is not required.

• ✗

  Use AWS Config rules in each account to check CloudTrail status and remediate via Lambda.

  Why it's wrong here

  AWS Config rules operate within a single account's scope and are fundamentally detective, not preventative. A custom rule like cloud-trail-enabled can flag accounts where the service is off, and a Lambda remediation function can attempt to re-enable it, but that function must be deployed and maintained in every account and can still be overridden by account administrators. More importantly, Config cannot enforce an organization-wide trail or prevent a member account from disabling CloudTrail after remediation. A single organization trail managed at the management account is the native control that provides continuous, central enforcement.

• ✓

  Use AWS CloudTrail with Organizations to create an organization trail that logs all accounts to the central bucket.

  Why this is correct

  Creating an organization trail in the management account (with isOrganizationTrail set to true) automatically provisions CloudTrail for every current and future member account in AWS Organizations, delivering logs to a single central S3 bucket. Member account users—even those with administrative rights—cannot disable or alter the trail because ownership rests with the management account, eliminating the need for per-account configuration or remediation. This native, centralized governance model is exactly why recommended architectures consistently select this option over per-account scripts, roles, or Config checks.

• ✗

  Create an IAM role that each account assumes to enable CloudTrail and log to the central bucket.

  Why it's wrong here

  Using a pre-provisioned IAM role that each member account assumes to call the StartLogging or CreateTrail API relies on custom automation and is inherently fragile. The role-based approach does not prevent a member account from using its own AdministratorAccess to delete the role, stop logging, or repoint the trail to a different bucket, so it cannot enforce compliance at the organization level. It also adds cross-account role setup, trust policy configuration, and a scheduler or orchestration layer—all of which must be tested in every account. AWS Organizations-native CloudTrail attributes solve the same problem without this operational burden.

Go deeper

Related to this question