AWS Shared Responsibility Model Complete Guide — CLF-C02 Domain 2 (Security & Compliance, 30%)

The AWS Shared Responsibility Model sits at the core of CLF-C02’s highest-weighted domain, and misreading it costs you multiple questions on test day. The naive mental model — “AWS handles security” — will lose you half of Domain 2: Security and Compliance (30% weight, around 15 questions). This article frames the responsibility model as a “dynamic model where the boundary shifts by service type,” then systematizes IAM, the major security services, and compliance frameworks to a CLF-C02 passing standard.

With Domain 1 Cloud Concepts (published 2026-05-26) and the overall cloud picture (published 2026-05-25) already locked in, this article walks straight into Domain 2, the highest-weighted domain of the exam.

Why Domain 2 Carries the Highest Weight (30%)

Among the four CLF-C02 domains, Security and Compliance takes the top weight at 30% for a clear reason. “Is the cloud safe?” is the question every enterprise asks at the moment of cloud adoption. For executives, legal, and security teams to approve AWS, the responsibility boundary, data protection, and compliance posture must be systematically explainable. CLF-C02 is the certification that guarantees “minimum cloud understanding,” and this domain is where that bar is set.

Out of 50 scored questions, roughly 15 belong to Domain 2. Score better than half here and you close in on a pass; score only 5 of 15 and you’ll need near-perfect performance on the other domains to clear 700 / 1000.

Within Domain 2, the AWS Shared Responsibility Model itself accounts for an estimated 3–4 questions, making it the highest-ROI topic to lock in completely.

AWS Shared Responsibility Model — Two “Securities”

The AWS Shared Responsibility Model splits responsibility into two layers expressed in AWS’s official phrasing.

“Security of the Cloud” is what AWS takes on — physical security of the data center, the hypervisor that drives virtualization, the underlying global network, and the patching and operation of managed services. Customers cannot touch this layer.

“Security in the Cloud” is what the customer owns — guest OS patching, application security, data encryption, IAM policy design, network configuration (Security Groups, NACL). AWS provides the tools but does not operate them on the customer’s behalf.

Responsibility Boundaries by Service Type

The most important point is that the boundary moves depending on which service type you use. Failing to grasp this point causes the most exam mistakes.

On EC2, the customer owns the guest OS, so OS patching, vulnerability response, and antivirus are all the customer’s job. On RDS (managed database), AWS handles the DB engine patching, but database user management, encryption settings, and access policy remain the customer’s responsibility.

Lambda is interesting — there’s no OS for the customer to manage, so the responsibility shrinks to “function code + IAM execution role + environment variables.” This is the cleanest model among AWS’s compute services and is the route of choice for security-sensitive workloads.

Shared Controls — Overlapping Responsibilities

Beyond the AWS-only and customer-only spaces sit Shared Controls — areas where both sides hold responsibility for different aspects.

The representative examples are patch management, configuration management, and awareness & training. Patch management: AWS handles patching the host OS, while customers patch the guest OS. Both sides own their own layer’s patching duty. Configuration management: AWS holds responsibility for the data center configuration, customers for the application configuration. Awareness & training: AWS trains its employees on security, while customers must train their own employees on AWS usage policies.

CLF-C02 exam questions like “Which of the following is a shared control?” expect patch management or configuration management as the answer. “Which one is fully the customer’s responsibility?” — application security or data encryption.

IAM — The Relationship of Users / Groups / Roles / Policies

AWS IAM (Identity and Access Management) is the foundation of “Security in the Cloud” and consists of four primitives.

The standard pattern for new AWS users is the cycle of “create Groups (Developers, Admins, etc.) → attach policies to Groups → assign Users to Groups.” Avoid attaching policies directly to individual users — it leads to permission drift and audit difficulty.

Roles are the centerpiece of security best practice. EC2 instances receive Roles via Instance Profiles, applications get temporary credentials through the AWS SDK without ever embedding access keys in code. Cross-account access is also built on Role assumption.

The Principle of Least Privilege is IAM’s first directive. Grant only the minimum permissions needed for a job, no more. The IAM Access Analyzer flags excessive permissions and surfaces unused access automatically — designing with this tool is the standard for safe operation.

MFA and Identity Center

Multi-Factor Authentication (MFA) is a configuration that adds a second authentication factor beyond username + password. AWS supports virtual MFA (Google Authenticator, Authy, etc.), U2F security keys (YubiKey, etc.), and hardware MFA devices. Always enable MFA on the root user — there is no exception. For IAM users, enabling MFA on accounts with management permissions (administrative roles) is the minimum line.

AWS IAM Identity Center (formerly AWS SSO) is the central management identity service for multi-account environments. With AWS Organizations, you achieve single sign-on across many AWS accounts and integrate with external identity providers like Azure AD, Okta, and Google Workspace. For enterprise users, this is the de facto standard.

The AWS Security Service Family

CLF-C02 tests the names and primary purpose of the major security services. Memorize the categories.

“GuardDuty is for threat detection, Inspector is for vulnerability scanning” is the most-confused pair on the exam. GuardDuty observes ongoing activity (API calls, network flows), while Inspector evaluates static configurations and dependencies (EC2 OS configurations, ECR images). Both are important but cover different timing.

AWS Shield Standard is free and applied automatically to all customers. AWS Shield Advanced costs $3,000/month and adds advanced DDoS protection plus 24/7 DDoS Response Team (DRT) support. CloudFront, ALB, Route 53 all gain protection. CLF-C02 includes the question “Is Shield Standard paid or free?” — the answer is always free.

Audit and Compliance Services

Audit-side services are equally important. CloudTrail records every API call made within an AWS account. Who, when, what was operated — this is the prerequisite for any forensic investigation after a security incident. Enabling Multi-region trails is the default. The first 5GB of storage per month is free.

AWS Config records the configuration history of AWS resources and detects deviations from desired configurations (Rules). For example, “S3 buckets must not be public” can be defined as a Rule, and any newly created bucket that doesn’t comply will be automatically flagged. Audits and continuous compliance both run on Config.

AWS Trusted Advisor is a free best-practice diagnostic service covering Cost Optimization, Performance, Security, Fault Tolerance, and Service Limits across five areas. Free tier users get 7 core security checks, Business / Enterprise Support plans unlock the full set.

Compliance Frameworks and AWS Artifact

AWS holds certifications for the world’s major compliance frameworks. CLF-C02 asks about which frameworks AWS supports and what role customers play.

Common frameworks: SOC 1 / 2 / 3 (audit-firm-issued internal control reports), PCI DSS Level 1 (credit card industry highest standard), HIPAA (US medical information protection), ISO 27001 / 27017 / 27018 (international security standards), FedRAMP (US federal government cloud standard), GDPR (EU general data protection regulation). AWS holds certifications for all of these and customers can use them.

The point is that “AWS holding a HIPAA cert does not automatically make a customer’s application HIPAA-compliant.” Customers must individually configure their applications to meet HIPAA requirements. AWS provides the foundation; the application’s own compliance posture is the customer’s responsibility. This is exactly a Shared Responsibility Model topic.

AWS Artifact is a free service where audit reports for major frameworks (SOC reports, ISO certificates, PCI DSS attestation, etc.) can be downloaded as PDFs. Customers attach these to vendor audits and security questionnaires. Access requires sign-in, and IAM permission scoping is recommended.

Encryption and AWS KMS

Encryption is at the core of data protection, and at the center of encryption on AWS sits KMS (Key Management Service). KMS is a managed service that centralizes key generation, storage, rotation, and access permission — and integrates with S3, EBS, RDS, Secrets Manager, and nearly all other AWS services.

Encryption comes in two types. Encryption at Rest protects S3 objects, EBS volumes, RDS snapshots, etc., with AES-256. Encryption in Transit uses TLS / SSL to protect client-server communication.

KMS Customer Master Keys (CMK) come in two flavors: AWS Managed Keys (managed by AWS, free) and Customer Managed Keys (customer controls fully, $1/month/key plus per-API-call charges). Secrets Manager ($0.40/month/secret plus per-API-call charges) is the higher-tier service for safely storing and auto-rotating API keys and database connection strings.

Network Isolation and VPC Security

VPC-level security mechanisms are organized in two tiers.

Security Groups are instance-level stateful firewalls. You define allow rules only; return traffic is automatically permitted.

Network ACL (NACL) is the subnet-level stateless firewall. You can define both allow and deny rules, and return traffic must also be explicitly allowed.

“SG guards instances, NACL guards subnet boundaries” — this double layer implements Defense in Depth, so a breach in one layer is still blocked by the other. CLF-C02 examiners reliably ask for the contrast “SG is stateful, NACL is stateless.”

Practice Questions (Domain 2 — 8 Sample Items)

Q1. Who is responsible for patching the EC2 instance’s guest OS?
A. AWS B. Customer C. Shared by AWS and customer D. Automatically applied at instance launch
Answer: B

Q2. How much does AWS Shield Standard cost?
A. $0 (free, automatically applied to all customers) B. $3,000/month C. $100/month D. Pay-per-DDoS-event
Answer: A

Q3. Which is the correct difference between Security Groups and NACLs?
A. SG is stateless, NACL is stateful B. SG is stateful, NACL is stateless C. Both are stateful D. Both are stateless
Answer: B

Q4. Which AWS service is appropriate for downloading SOC reports?
A. CloudTrail B. AWS Artifact C. Trusted Advisor D. Macie
Answer: B

Q5. Which is responsible for the GuardDuty service?
A. AWS responsibility (security of the cloud) B. Customer responsibility (security in the cloud) C. Shared control D. None
Answer: A (GuardDuty is a managed service; AWS handles operation. The customer’s task is just enabling it.)

Q6. Which is the most appropriate way to grant EC2 instances permissions to access AWS services?
A. Embed access keys in code B. Save credentials to environment variables C. Attach a Role via Instance Profile D. Use the same access keys across all instances
Answer: C

Q7. Which service automatically detects PII (personally identifiable information) in S3?
A. GuardDuty B. Inspector C. Macie D. Detective
Answer: C

Q8. To configure MFA on the root user, what is the minimum needed?
A. Hardware MFA device only B. Virtual MFA (smartphone app) C. Multiple authentication factors D. Cannot configure MFA on the root user
Answer: B (Virtual MFA alone is sufficient.)

Understanding Responsibility Splits Through Attack Scenarios

Real attack scenarios make the Shared Responsibility Model concrete.

Scenario 1: SSH brute-force attack on EC2. Was the SSH port (22) open to the public? Were the IAM key permissions appropriate? Were the SSH password (or key) strength sufficient? All customer-side issues. AWS provided the firewall (Security Groups), but its configuration is the customer’s responsibility. GuardDuty would have detected this attack.

Scenario 2: Data leak from a public S3 bucket. Did S3 Block Public Access fail to apply? Were the IAM policies properly defined? Both customer-side issues. AWS provides Block Public Access by default; whether the customer enables it is their responsibility. Macie would have flagged the PII in the bucket.

Scenario 3: Compromised internal admin account leading to data deletion. Was MFA enabled? Was the principle of least privilege applied? Was CloudTrail enabled? All customer responsibility. AWS provides all the tools — IAM, MFA, CloudTrail, Config — but their configuration is the customer’s. The standard for restoring deleted data is to operate cross-region replication.

Misunderstandings of the AWS Shared Responsibility Model

Common misunderstandings to watch for.

Misunderstanding 1: “AWS does my application security.” AWS provides infrastructure security. The OWASP Top 10 (SQL injection, XSS, etc.) is fully the customer’s responsibility. Use WAF to defend, but writing safe code is still the customer’s job.

Misunderstanding 2: “Managed services need no customer security configuration.” RDS, DynamoDB, Lambda are all managed services, but IAM policies, encryption settings, network isolation are the customer’s responsibility. Convenience does not equal automatic safety.

Misunderstanding 3: “AWS holds a HIPAA cert, so my app is HIPAA-compliant.” AWS provides HIPAA-eligible infrastructure. Customers must individually configure their applications to meet HIPAA requirements (BAA contract, encryption, access controls, audit logs). The cert is the floor, not the finish.

Conclusion — Next Up Is Domain 3: Core Services

The AWS Shared Responsibility Model — its two layers, the boundary shifts by service type, shared controls, IAM, security services, audit / compliance, KMS, VPC security, attack scenarios, common misunderstandings — covered in one read. Locking in Domain 2 (Security and Compliance, 30%) puts you in clear sight of CLF-C02 pass territory.

Next comes Domain 3 (Cloud Technology and Services, 34%) — the highest-weighted domain. Specific service knowledge across EC2 / S3 / RDS / Lambda / IAM / VPC and 30+ services is condensed into one article.

References

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.