The AWS Shared Responsibility Model

Every CLF-C02 security question eventually collapses into one sentence: who fixes this? The exam calls it Domain 2, Task 2.1, "Recognizing the components of the AWS shared responsibility model", and Domain 2 is worth 30% of your score (as of Oct 2026), so this single model is statistically the most profitable concept on the whole test. AWS states the premise flatly: "Security and Compliance is a shared responsibility between AWS and the customer." Shared does not mean split down the middle, it means two different organizations, each fully responsible for their own layer, and the boundary between those layers moves depending on which service you pick.

In this lesson you will:

• separate security OF the cloud (AWS) from security IN the cloud (you) using AWS's own wording;
• place the boundary exactly: host OS and virtualization layer down = AWS, guest OS and up = you;
• read the full responsibility breakdown table: facility, hardware, hypervisor, data, identity, encryption, compliance;
• watch the line shift across Amazon EC2, Amazon RDS, AWS Lambda and Amazon S3, including the RDS Custom and Lambda runtime-mode wrinkles;
• classify every control as inherited, shared or customer specific, and understand why shared ≠ 50/50;
• list what customers still own: data classification, identity and access, OS patching on EC2, network configuration, encryption choices, application security;
• list what AWS owns: facilities, hardware, virtualization and the managed-service infrastructure;
• recognize the classic misattribution traps that carry most of the wrong options on this topic;
• study four AWS-published security and compliance case studies: two operational, two authorization-based;
• check the 2026 guide and service-list changes (as of October 2026) that decide what Domain 2 still tests;
• practise with 12 exam-style questions plus four interactive checks.

---

1. Security OF the cloud versus security IN the cloud

1.1 AWS's own wording

AWS's compliance page defines both halves in one paragraph, and the exam quotes it almost verbatim:

The second row is the one students misread. Your duties are not fixed; they are derived from your service choice. Run Amazon EC2 and you inherit an operating system to patch; run Amazon S3 and that duty disappears while the duty to classify your data does not.

1.2 The preposition is the whole trick

1.3 Example E1: sorting six statements in under a minute

Read each statement, name the half, then decide whether it is even plausible:

The pattern in rows 3, 4 and 5 is the whole exam: AWS provides a capability; you make the decision. Provided ≠ configured, and tools ≠ responsibility.

• 📚 Did you know? The model is why cloud compliance is cheaper. AWS writes that it lets customers "shift management of certain IT controls to AWS" and inherit an audited control environment instead of building facilities and physical security; while keeping data, identity, configuration and compliance. That is also why AWS Artifact exists as a no-cost, self-service portal for on-demand access to AWS's compliance reports: the evidence for the AWS half is already written; you only have to fetch it.

---

2. Where the line sits in the stack

2.1 The boundary sentence

AWS's canonical page draws the line in a single sentence: quote it to yourself until it is automatic:

"AWS operates, manages and controls the components from the host operating system and virtualization layer down to the physical security of the facilities in which the service operates. The customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software as well as the configuration of the AWS provided security group firewall."

Two consequences appear on every exam form:

1. Amazon EC2 makes you a sysadmin. You chose IaaS, so layers 3 to 7 are yours, including "updates and security patches" for the guest OS.
2. The line is not a physical object. It is a contractual split of duties that AWS re-draws per service; which is Task 2.1's second half (Section 4).

2.2 Resiliency uses the same two prepositions

The Well-Architected Reliability Pillar repeats the split for availability, which is a favourite distractor source:

2.3 Example E2: the 124-AZ arithmetic, and what it does not buy you

AWS reports 124 Availability Zones across 39 Geographic Regions, each Region with "at least three independent, physically separate Availability Zones" (as of Oct 2026).

$$39 \times 3 = 117 \text{ AZs as the design minimum} \quad\Rightarrow\quad 124 - 117 = 7 \text{ AZs above the minimum}$$

So AWS has engineered seven more failure domains than its own floor requires, and your account still owns the difference in practice. A single-AZ deployment inside a 3-AZ Region inherits zero of that engineering. The customer-side checklist after the arithmetic:

1. deploy across at least two AZs (AWS's own design rule for availability);
2. turn on backups and test restoring them;
3. decide whether a Region-level event needs a DR strategy (that is a Region question, not an AZ question);
4. test the failover: an untested plan is a hypothesis.

• 📚 Did you know? AWS decommissions media that held customer data using techniques detailed in NIST 800-88, physical access to server rooms requires multi-factor authorization, and access to data centres is "logged, monitored, and retained", yet external auditors test AWS against more than 2,600 requirements throughout the year (as of Oct 2026). All of that sits on the AWS side, which is exactly why it is an inherited control for you: you get the assurance without operating the badge readers.

---

3. The full responsibility breakdown

3.1 Every row, every owner

This is the table Task 2.1 is built on. Learn it as three columns of logic: always AWS, always yours, and depends on the service.

3.2 Example E3: the same workload, three columns

An on-premises database team documents what each hosting option demands. The Amazon RDS User Guide publishes exactly this comparison:

Read the columns left to right and you are watching the line slide upward: three customer duties become AWS duties as you move from self-managed to managed. Read the rows and you see what never changes: nothing in this table is about your data, your IAM policies or your compliance obligation, because those live above the boundary in every column.

---

4. How the line shifts across services (Task 2.1's hardest skill)

4.1 The three exam exemplars plus one

The exam guide names Amazon RDS, AWS Lambda and Amazon EC2 as the shift examples. Add Amazon S3 (the abstracted-storage case) and you cover every shape of question.

Two invariants survive every row of that table: AWS always owns facilities, hardware and the hypervisor, and you always own data, IAM and the encryption decision. Only the middle rows move.

4.2 The patch-duty audit (worked example E4)

Who patches the operating system? Six workloads, one answer each:

The two traps in that table, RDS Custom and Lambda Manual, are worth a section each.

4.3 The RDS Custom escape hatch

Amazon RDS Custom exists because some workloads need privileged operating-system access. AWS's own wording: "With RDS Custom, you use the managed features of Amazon RDS, but you manage the host and customize the OS as you do in Amazon EC2." The published responsibility table flips OS patching and database software patching back to Customer for RDS Custom, while standard Amazon RDS keeps both on AWS.

4.4 The Lambda runtime nuance

AWS publishes runtime management as a shared responsibility topic:

• "Lambda is responsible for curating and publishing security updates for all supported managed runtimes and container images."
• "For functions configured to use the Manual runtime update mode, you're responsible for updating your function to use the latest runtime version."

4.5 Example E5: a deprecated runtime nobody patched

A function runs on a runtime version AWS has flagged for deprecation. AWS has already published the security fix (Lambda's half is done). The team's audit:

Count the failures: 0 AWS failures, 1 customer failure in each of the last two rows. The model worked exactly as designed: a published fix plus an ignored duty still equals an unpatched function, and the exam will ask you to name the owner.

4.6 Single-tenant versus multi-tenant patching

The Well-Architected Security Pillar splits managed services into two patching behaviours, and the difference is how much you still have to do:

• 📚 Did you know? The same model governs who removes the hardware: AWS's NHS-aligned guidance calls data-centre security "entirely AWS responsibility" and says disposal and deprovisioning "falls to AWS under the Shared Responsibility Model". Your obligation starts at your data, "You always own your data, including the ability to encrypt it, move it, and manage retention", and ends at your retention and deletion policies, never at the shredder.

---

5. The control taxonomy: inherited, shared, customer specific

5.1 AWS's three official categories

AWS does not split controls into "yours/mine" only. The published taxonomy has four labels, and the exam asks you to place an example in the right one:

5.2 The five-question heuristic

When an option is unfamiliar, run this order of tests; it resolves nearly every Task 2.1 item:

5.3 Example E6: bucket-sorting twelve controls

Sort the twelve controls from Section 3 into the taxonomy and count them:

Four plus three plus five equals twelve, and every one of the three "unsortable" statements fails the Section 8 trap table. If you can bucket a control in under ten seconds, you can answer the question.

5.4 Shared controls in continuous operation

A control is only real if it runs continuously, so the exam also tests the ongoing form of the three shared controls. Each row names what AWS does forever, what you must do forever, and where the evidence lands:

AWS's financial-services guidance frames the customer side of this loop as three repeating program actions: Validating (is the control designed correctly?), Demonstrating (can you show the evidence?), Monitoring (is it still working?). That is continuous monitoring in the cloud, and none of it transfers to AWS, because AWS cannot validate a decision you have not made.

---

6. What customers still own

Abstraction removes infrastructure chores, never ownership. Even on the most abstracted service, six duties are permanently yours:

6.1 The customer's monitoring duty

AWS supplies the detective tooling; enabling it and acting on it is yours. AWS's own account-security guidance puts the sharpest case first: "It's critical that you protect your root account from unauthorized access, starting with multi-factor authentication", and root should be used only in emergencies.

6.2 Example E7: the root-account exposure audit

Three findings on one account (counts are the scenario's, not AWS metrics):

Exposure = 1 + 2 + 0 = 3 customer-side gaps, 0 AWS-side gaps. Note what the arithmetic shows: every gap is a decision nobody made, and every fix uses a tool AWS already provides. Also note the AWS-side signup control that is not yours: at account creation AWS holds USD $1 (or equivalent) for 3 to 5 days to verify your account and prevent fraud (as of Oct 2026).

6.3 Check yourself: the duties that never move

• 📚 Did you know? Your compliance evidence splits down the same line. For a PCI workload you would pull AWS-side evidence, physical security, media destruction, infrastructure patching, network protection, staff training, from AWS Artifact, a "No cost, self-service portal for on-demand access to AWS' compliance reports", while supplying your own evidence for IAM least privilege, security group rules, encryption settings and log retention. AWS supports 143 security standards and compliance certifications including PCI-DSS, HIPAA/HITECH, FedRAMP, GDPR, FIPS 140-3 and NIST 800-171, and offers over 300 security, compliance and governance services and features (all as of Oct 2026).

---

7. What AWS owns

Everything from the host operating system downward, plus the machinery of running the service itself:

---

8. Classic misattribution traps

8.1 The nine wrong answers, corrected

These are the misattributions that fill the distractors. Read the wrong version, then say the right one aloud:

8.2 Example E8: rewriting three distractors

Take a practice stem: "A regulated workload is deployed on Amazon RDS. Which statement is correct?"

The pattern: each wrong option takes one true row from the Section 3 table and attaches someone else's row to it. Split the rows back apart and the option collapses.

8.3 Where the exam plants the trap

---

Real-World Case Studies

AWS publishes what shared responsibility looks like in a regulated production account. Every figure below is customer- or AWS-claimed and unaudited, with the source named so you can check it: the examinable point is the split (which controls were inherited, which the customer had to build), not the marketing number.

Case A, athenahealth: centralized network security across 120 accounts (Domain 2)

Exam lesson: this is a customer-side network configuration story running on AWS-side infrastructure. The customer quote, "By scalable, I mean it's AWS magic. We don't have to think about scalability at all.", is about the inherited half; the rules-as-code and the 120-account policy fan-out are the "in the cloud" half that no provider can do for you.

Case B, Avalon Healthcare Solutions: Zero Trust access to PHI (Domain 2)

Exam lesson: identity is always customer responsibility, and Avalon shows the pattern the exam wants: buy the access service (AWS side), own the who and the evidence (customer side). Related AWS-published example: Socure reports having "inherited over 46 FedRAMP-required security controls from AWS GovCloud (US)" (AWS Public Sector Blog, 14 Nov 2024): a clean count of inherited controls, with everything else still theirs.

What both cases share

Two more Domain 2 cases: the authorization pair

Cases A and B are operational security builds. The next two are authorization stories: same model, different evidence: AWS's half arrives pre-audited inside a compliant Region, and the customer's half is the control implementation and the authorization itself. Both are AWS-published, both are customer-claimed, and both are here because the exam loves the word inherited.

Case C, Socure: counting the 46+ FedRAMP controls you inherit (Domain 2)

Exam lesson: inheritance shrinks your evidence; it never replaces your authorization. The 46 controls are inherited (AWS's infrastructure and physical layer, already audited): everything above the line, plus the authorization package, stays customer responsibility. The examinable sentence is the one already in Section 7: FedRAMP is a government authorization, not an AWS product.

Case D, Smartsheet Gov: FedRAMP-ready in under 90 days (Domain 2)

Exam lesson: speed comes from inheritance, obligation does not. Roughly 4 to 6× faster than the typical 12 to 18 month path (90 days vs 360 to 540 days: $360 \div 90 = 4$ to $540 \div 90 = 6$), but the customer still obtains the authorization. An option saying "AWS GovCloud makes a workload FedRAMP authorized" is the same category error as "AWS is certified, so we are compliant."

What the authorization pair adds

• 📚 Did you know? ATO on AWS is the mechanism behind the 90-day story: AWS packages its own artifacts so a customer's assessor does not have to re-audit the infrastructure half, the same reason AWS Artifact exists as a "No cost, self-service portal for on-demand access to AWS' compliance reports". The inheritance is real (Socure counts 46+, Smartsheet counts weeks), yet in both cases the AWS-published figure describes how much less the customer had to build, never who is legally responsible. Dates matter too: Smartsheet's number is from 29 Aug 2019 and Socure's from 14 Nov 2024, old figures must never be presented as current, and both are customer-claimed, unaudited results.

---

What Changed for the 2026 Exam

2026 Updates (as of October 2026)

The exam guide is a moving document: the current PDF prints only "Copyright © 2026" with no version number, the only stamped artefact being the launch-era Version 1.0 CLF-C02 guide. So the defensible method is to diff that baseline against the pages AWS publishes today, and every item below is date-stamped as of Oct 2026 with its source named. Verify current before use.

Two consequences for this lesson specifically: the service names you can be quizzed on have churned (four networking services in, AWS Network Firewall out), but the model has not moved at all: OF/IN, inherited/shared/customer specific, the fixed anchors and the shift exemplars (Amazon EC2, Amazon RDS, AWS Lambda) are identical. Date-stamp every count you memorise, and re-check the live list before exam day.

• 📚 Did you know? The guide churn is measurable arithmetic: in-scope entries fell 128 → 111 (−17, −13.3%) while the explicit negative list grew 11 → 55 (+44), so the pair moved by $111 + 55 = 166$ documented entries versus $128 + 11 = 139$ before, a 27-entry expansion of explicit guidance, almost all of it naming what is out of scope. That is why prep material from 2024 confidently tells you that AWS Data Exchange, Amazon MSK, AWS Local Zones, AWS Wavelength, AWS Snow Family, AWS Audit Manager and AWS Network Firewall are in scope, and why the current list says otherwise (all checked Oct 2026, verify current before use). The meta-skill the exam rewards: the guide you download today is the exam you sit, not the PDF you revised from.

---

Practice Questions