AWS Shared Responsibility Model: CLF-C02 Study Guide
The AWS shared responsibility model divides security tasks: AWS is responsible for security "of" the cloud (global infrastructure, hardware, and virtualization), while the customer is responsible for security "in" the cloud (data encryption, IAM, and OS patching). Understanding this boundary is critical for passing the CLF-C02 exam and securing your workloads.
What exactly is the AWS Shared Responsibility Model?
Think of the Shared Responsibility Model as a legal contract for security. Instead of assuming AWS handles everything once you move to the cloud, this model explicitly defines who is responsible for which security controls. If you get this wrong in a real-world scenario, you end up with a data breach; if you get it wrong on the CLF-C02 exam, you lose easy points.
The core distinction you need to memorize is the difference between security "of" the cloud and security "in" the cloud. AWS manages the foundation, while you manage how you use that foundation. We see many students struggle here because they assume "managed services" mean "zero responsibility," but that is a dangerous misconception that the exam will test aggressively.
What is AWS responsible for "of" the cloud?
AWS handles the heavy lifting of the physical and virtualization layers. This includes the physical security of the data centers—meaning the guards, cameras, and biometric locks that keep people out of the server rooms. You'll never be asked to patch a physical server or replace a failed hard drive in a rack; that is 100% on AWS.
Beyond the physical, AWS manages the software layer that runs the virtualization (the hypervisor). They ensure that the global infrastructure—Regions, Availability Zones, and Edge Locations—is resilient and available. When you see exam questions mentioning "hardware," "global infrastructure," or "physical facilities," the answer is almost always AWS. They provide the secure sandbox; you just have to make sure you don't leave the gate open.
What are you responsible for "in" the cloud?
This is where most security failures happen and where the CLF-C02 focuses its trickiest questions. You are responsible for everything you put into AWS. This starts with Identity and Access Management (IAM). If you create a user with full administrative privileges and no MFA, that's your responsibility, not AWS's.
You are also responsible for your data. This includes encrypting your data at rest (using KMS) and in transit (using TLS/SSL). Furthermore, if you launch an Amazon EC2 instance, you are the "system administrator." You must handle the guest operating system patching, firewall configurations (Security Groups), and application updates. If your EC2 instance is hacked because you didn't update Linux or Windows, AWS isn't responsible—you are.
How does responsibility shift with managed services?
The line of responsibility isn't static; it shifts based on the service model you choose. In an Infrastructure as a Service (IaaS) model like EC2, you have maximum control and maximum responsibility. However, as you move toward Platform as a Service (PaaS) or Serverless, AWS takes over more of the burden.
Take Amazon RDS as an example. AWS handles the OS patching and the database engine installation, but you are still responsible for managing your database users and the actual data within the tables. Now, look at AWS Lambda. In this serverless model, AWS manages the entire underlying stack, including the OS and the runtime. Your only responsibility is the code you upload and the IAM permissions you assign to that function. Understanding this "sliding scale" is key to scoring high on the Cloud Practitioner exam.
Which common exam scenarios will you encounter?
The CLF-C02 loves to present scenarios to see if you can distinguish between the provider and the customer. For example, if a question asks who is responsible for "patching the guest OS on an EC2 instance," the answer is the customer. If it asks who is responsible for "disposing of old hard drives," the answer is AWS.
Another common trap involves S3 buckets. AWS ensures the S3 service is available and the physical disks are secure, but if you set a bucket policy to "Public," you have created the vulnerability. To master these nuances, we recommend drilling with a high volume of questions. At Cert Sensei, we provide 1,000 expert-curated practice questions for the CLF-C02, complete with detailed reasoning that explains exactly why a task falls under the customer or AWS.
How can you ensure you've mastered this domain?
Don't just read the documentation; test your boundaries. The best way to prepare is to categorize every AWS service you study by its responsibility level. Ask yourself: "Who patches the OS here? Who manages the encryption keys? Who controls the network access?"
We suggest using a custom quiz builder to filter specifically for the "Cloud Concepts" domain. By focusing on your weak points through domain-level analytics, you can stop wasting time on what you already know and focus on the areas where you're still confusing 'of' with 'in.' Remember, the goal isn't just to pass the test, but to build a mental framework that allows you to secure any cloud environment you touch in your professional career.
❓ Frequently Asked Questions
Is patching the Guest OS the responsibility of AWS or the customer?
For Amazon EC2, patching the guest operating system is the customer's responsibility. However, for managed services like RDS or serverless options like Lambda, AWS handles the underlying OS patching for you.
Who is responsible for the physical security of AWS data centers?
AWS is entirely responsible for the physical security of the infrastructure. This includes the physical buildings, the hardware, and the personnel who manage the data centers globally.
If my S3 bucket is accidentally left open to the public, is that an AWS failure?
No. AWS provides the tools to secure the bucket (like Block Public Access), but the configuration of those tools and the resulting access permissions are the customer's responsibility.