The AWS Shared Responsibility Model Explained for CLF-C02 Candidates

The AWS Shared Responsibility Model is one of the most tested concepts on the CLF-C02 exam — and one of the concepts candidates most commonly get wrong. It appears across Domain 2 (Security and Compliance) directly, but its implications show up in Domain 3 questions about specific services too. Understanding it precisely, not just roughly, is essential for passing.

The core principle in plain language

AWS is responsible for the security of the cloud. You (the customer) are responsible for security in the cloud. AWS manages the underlying infrastructure. You manage everything you put on top of it.

That sounds simple. The exam makes it harder by testing whether you know exactly where the line falls for specific services — and that line moves depending on which service you are using.

What AWS is always responsible for

Regardless of which AWS service you use, AWS is responsible for the physical and foundational layer:

• Physical security of data centre facilities (buildings, access controls, environmental systems)
• Hardware (servers, storage, networking equipment)
• Global network infrastructure
• Hypervisor layer for EC2 (the software that runs virtual machines)
• Availability of the AWS global infrastructure — Regions, Availability Zones, edge locations
• Patching and managing the underlying managed service components (e.g. the RDS database engine, the Lambda runtime)

What customers are always responsible for

Regardless of which AWS service you use, you as the customer own:

• Your data — its classification, encryption choices, and retention
• Identity and access management — who has what permissions to your AWS resources
• Network traffic protection — security group rules, NACLs
• The applications you build and deploy
• Client-side encryption

Where the line shifts by service type

This is where the exam gets specific. The division of responsibility is not the same for every service:

The key insight: as you move from IaaS (EC2) to managed services (RDS) to serverless (Lambda), AWS takes on more responsibility and the customer's scope narrows. For EC2, you manage the guest OS. For RDS, AWS manages the OS and database engine but you manage the data, users, and schema. For Lambda, AWS manages everything below your function code.

Amazon S3 — a common exam scenario

S3 is frequently used in Shared Responsibility exam questions because it sits in an unusual position — it is a fully managed object storage service, meaning AWS manages the underlying hardware and the durability infrastructure (the eleven nines of durability). But:

• Customer responsibility: Encryption of objects (you choose whether to enable it and which method), bucket policies and access controls, classifying what data you store and whether it should be public or private, enabling versioning and lifecycle policies
• AWS responsibility: Physical storage infrastructure, the global replication that delivers durability, operating the S3 service endpoints

Exam question patterns to recognise

The exam tests the Shared Responsibility Model in several ways:

Direct definition questions

These simply ask "Under the Shared Responsibility Model, who is responsible for X?" These are straightforward marks if you have studied the model. Common examples: patching the EC2 guest OS (customer), maintaining physical data centre security (AWS), encrypting customer data in S3 (customer), managing the hypervisor (AWS).

Service-specific scenario questions

A scenario describes a company using RDS and asks what the customer needs to do regarding security. The answer will always be in the customer's scope — managing DB users, encrypting data — not in AWS's scope like patching the engine.

Distractors that blur the line

Exam options sometimes include statements that are plausible but wrong — for example, suggesting AWS is responsible for "ensuring applications running on EC2 are secure." AWS is responsible for the hypervisor, not the security of applications running on EC2. Anything above the OS on EC2 is customer responsibility.

How it connects to other CLF-C02 topics

Understanding the Shared Responsibility Model makes several other exam topics clearer. IAM permissions are a customer responsibility — meaning if someone in your organisation has excessive permissions, that is your problem to fix, not AWS's. Encryption keys in KMS: you choose whether to use them and which keys to assign to which data. Security group misconfiguration: your responsibility, not AWS's.

Frequently asked questions

Does the Shared Responsibility Model change for every AWS service?

The broad principle is the same — AWS manages the infrastructure, you manage what you put on it. But the specific split of responsibilities does shift as services become more managed. The exam primarily tests EC2, RDS, Lambda, and S3, so focus your study on those four.

Is patching EC2 always the customer's responsibility?

Yes — for standard EC2 instances, the guest OS (the operating system running inside the virtual machine) is always the customer's responsibility to patch. This includes Windows Server and any Linux distribution. AWS provides the hypervisor and the physical host, not the OS updates.

What about AWS Systems Manager Patch Manager?

AWS does provide tools like Systems Manager that can automate EC2 OS patching — but the responsibility to use those tools and configure them correctly still sits with the customer. Providing a tool is different from taking responsibility for the outcome.