CLF-C02 Security and Compliance Guide

Study CLF-C02 Security and Compliance: key concepts, common traps, and exam decision cues.

This is the heaviest CLF-C02 domain after service technology, and it is where many candidates lose easy points by mixing security ideas that sound similar. AWS is not expecting architect-level security design here. It is expecting you to separate shared responsibility, security and compliance concepts, access management, and security resources into clean foundational lanes.

I verified the current CLF-C02 Domain 2 task statements on May 11, 2026. AWS currently expresses this domain as four task statements:

  1. understand the AWS shared responsibility model
  2. understand AWS Cloud security, governance, and compliance concepts
  3. identify AWS access management capabilities
  4. identify components and resources for security

The public guide still uses three teaching pages, but they now map cleanly to those four tasks instead of blending them too loosely.

Current weight in the exam guide

AWS currently weights Security and Compliance at 30% of scored content.

What this domain is really testing

AWS wants you to prove that you can:

  • tell what AWS secures from what the customer still secures
  • recognize basic governance and compliance concepts without overcomplicating them
  • identify IAM, MFA, least privilege, roles, and centralized access patterns
  • pick the correct broad security resource such as Artifact, CloudTrail, Config, GuardDuty, Security Hub, Shield, or WAF

Work this domain in order

Lesson AWS task fit Why it matters
2.1 Shared Responsibility & Protection Boundaries Task 2.1 This is the boundary lane: who secures the cloud, who secures what is in it, and how that changes with managed services.
2.2 Identity, Access & Root-Account Protection Task 2.3 This is the access lane: IAM, MFA, least privilege, roles, root-account safety, and centralized access.
2.3 Governance, Compliance, Logging & Security Services Tasks 2.2 and 2.4 This is the concepts-and-resources lane: compliance evidence, audit trails, logging, configuration tracking, threat detection, and managed protection services.

Fast routing inside this chapter

If the question is really about… Go first to… What to look for
who secures hardware, guest OS, data, identities, or patching 2.1 Shared Responsibility & Protection Boundaries AWS side vs customer side
users, roles, MFA, least privilege, root user, access keys, or workforce sign-in 2.2 Identity, Access & Root-Account Protection human access vs workload access
Artifact, CloudTrail, CloudWatch, Config, GuardDuty, Security Hub, Shield, WAF, encryption basics, or governance/compliance concepts 2.3 Governance, Compliance, Logging & Security Services evidence, monitoring, findings, protection controls

Common domain traps

Trap Better thinking
“AWS secures everything once the workload is in AWS.” Shared responsibility still leaves configuration, identity, and data choices with the customer.
“CloudTrail, CloudWatch, Config, and Artifact are all basically audit services.” Each one answers a different kind of question.
“Root user is just another admin identity.” Root is special and should be heavily protected and rarely used.
“Security group, WAF, and Shield are interchangeable.” They protect at different layers.

How strong CLF-C02 answers usually work

  1. Identify the lane before naming a service.
  2. Separate responsibility, identity, evidence, and protection.
  3. Prefer the broad AWS-managed control over a home-built workaround.
  4. Reject answers that normalize root use or long-lived credentials.
  5. Keep the exam at the fundamentals level: broad correct service, not deep implementation detail.

Late-stage review bias

If your misses include phrases like shared responsibility, least privilege, compliance, or most secure, protect this chapter first. It is one of the highest-yield near-miss domains on CLF-C02.

In this section

Revised on Monday, June 15, 2026