SCS-C02 Practice Questions

These questions cover logging, monitoring, and data protection — the domains where SCS-C02 goes well beyond the associate exams and tests your ability to distinguish between services that look similar but serve different compliance purposes.

Question 1

A security engineer suspects CloudTrail logs in an S3 bucket may have been tampered with by a user with S3 write access. Which control provides cryptographic proof that log files have not been modified?

• A) Enable CloudTrail Log File Validation to generate SHA-256 digest files
• B) Apply S3 Object Lock in Compliance mode with a retention period
• C) Enable S3 Versioning on the CloudTrail bucket
• D) Use S3 Replication to copy logs to a separate account immediately

Answer: A — CloudTrail Log File Validation

CloudTrail Log File Validation creates an hourly digest file containing the SHA-256 hash of every log file delivered in that period, and the digest file itself is signed with CloudTrail's private key. To verify integrity:

aws cloudtrail validate-logs \
  --trail-arn arn:aws:cloudtrail:us-east-1:123456789012:trail/MyTrail \
  --start-time 2026-01-01T00:00:00Z

If any log file was deleted or modified, the hash comparison fails and validation reports the discrepancy — providing cryptographic evidence of tampering.

Why the other options fall short:

• Object Lock (Compliance mode): Prevents deletion during the retention period but doesn't prove files weren't modified before the lock was applied
• S3 Versioning: Preserves previous versions but doesn't prove the current version is the original
• Replication: Copies logs off-site but doesn't provide integrity proof for either copy

Question 2

A compliance team needs an audit trail of every GetObject and PutObject API call on a specific S3 bucket containing customer PII. Which feature captures this?

• A) Enable S3 Server Access Logging — it records all requests to the bucket
• B) Enable CloudTrail Data Events for the S3 bucket
• C) Enable Amazon S3 Inventory — it provides a list of all objects in the bucket
• D) Enable Amazon Macie — it logs all access to sensitive data

Answer: B — CloudTrail Data Events for the S3 bucket

CloudTrail has two event types:

• Management events (default): Control-plane actions — CreateBucket, DeleteBucket, IAM changes
• Data events (optional, extra cost): Data-plane actions — GetObject, PutObject, DeleteObject on specific resources

Data events for S3 capture exactly who accessed which object, when, from which IP, with which credentials. This is what compliance and forensics require.

The key difference between S3 logging options:

S3 Server Access Logging is best-effort and doesn't include the IAM principal — it's not suitable for compliance audit trails.

Question 3

A KMS CMK must be usable only by a specific Lambda function role, and no other principal — including root — should be able to use the key for encryption/decryption. Which configuration achieves this?

• A) Set a KMS key policy that grants kms:* only to the Lambda role
• B) Remove the default key policy and rely on IAM policies to restrict access
• C) Set a key policy granting kms:Decrypt and kms:GenerateDataKey only to the Lambda role, with a Deny for all other principals
• D) Enable KMS key rotation and set the Lambda role as the only rotation principal

Answer: C — Key policy with explicit allow for Lambda role and Deny for others

KMS key policies are resource-based policies. By default, a key policy includes a statement allowing the root account full access — removing this entirely locks everyone out, including administrators who need to manage the key.

The correct pattern is:

{
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
      "Action": "kms:*",
      "Resource": "*",
      "Condition": {"StringEquals": {"kms:CallerAccount": "123456789012"}}
    },
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:role/LambdaRole"},
      "Action": ["kms:Decrypt", "kms:GenerateDataKey"]
    },
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
      "Condition": {"StringNotEquals": {"aws:PrincipalArn": "arn:aws:iam::123456789012:role/LambdaRole"}}
    }
  ]
}

The Deny with a StringNotEquals condition blocks all principals other than the Lambda role from using the key, even if their IAM policies would otherwise allow it.

Key Takeaways

• CloudTrail Log File Validation = SHA-256 hashes + signed digest files — the only option that proves tampering cryptographically
• CloudTrail Data Events capture object-level S3 access with identity; Server Access Logging is best-effort and lacks IAM principal info
• KMS key policy Deny statements override IAM allows — use them to restrict key usage to specific principals even against root