AWS Shared Responsibility Model for CLF-C02: Who Secures What on EC2, RDS, Lambda and S3

Task statement 2.1 of the CLF-C02 exam guide, unchanged in version 1.3, is only one line of knowledge, but it reaches into many question styles. It asks you to recognize the parts of the AWS shared responsibility model, describe what AWS is responsible for, what the customer is responsible for and what both share, and explain how the split shifts "depending on the service used," with Amazon RDS, AWS Lambda and Amazon EC2 as AWS's own examples. It sits in Security and Compliance, the domain worth 30% of scored content.

Security "of" the cloud and security "in" the cloud

AWS's shared responsibility model page draws the line in two phrases:

• AWS: security of the cloud. AWS protects the infrastructure that runs all of its services, which it describes as the hardware, software, networking and facilities. It operates and controls everything "from the host operating system and virtualization layer down to the physical security of the facilities."
• You: security in the cloud. Your share "will be determined by the AWS Cloud services that a customer selects." AWS adds that it also depends on how those services fit into your IT environment and on the laws and regulations that apply to you.

A practical reading, which is Passy's heuristic rather than AWS wording: anything you could never touch, such as a data center door, a physical disk or the hypervisor, belongs to AWS. Anything you can configure, such as an operating system, a firewall rule, a permission or an encryption setting, is a candidate for your side.

How the line moves for EC2, RDS, Lambda and S3

The exam expects you to see that "managed" moves work to AWS without moving all of it. AWS's documentation describes each case:

• Amazon EC2 (infrastructure as a service). AWS says you manage the guest operating system "including updates and security patches," any software you install, the configuration of security groups, the credentials used to connect to your instances, and the IAM roles attached to them.
• Amazon RDS (managed database). AWS takes over the operating system and the database software. RDS documentation says AWS hosts "the software components and infrastructure," while you own query tuning and application optimization.
• AWS Lambda (serverless). Lambda "automatically manages the underlying infrastructure – including server maintenance, capacity provisioning, scaling, and patching," which AWS says is "so you can focus on your application logic." Lambda publishes patched runtime versions and, in the default Auto update mode, applies them to your functions. The function code, the libraries you package with it and the function's IAM permissions are not on AWS's list.
• Amazon S3 and Amazon DynamoDB (abstracted services). AWS operates "the infrastructure layer, the operating system, and platforms." You manage your data, including encryption options, classify your assets and set permissions with IAM. For S3, AWS also lists enabling detective controls, such as AWS CloudTrail or Amazon GuardDuty, as your job.

For databases, AWS publishes its own side-by-side comparison in the Amazon RDS user guide:

One nuance from the Well-Architected Security Pillar: for managed services on single-tenant architectures, such as RDS, AWS identifies vulnerabilities and releases patches, while you "facilitate patching" by choosing maintenance windows or scheduling restarts. On multi-tenant services such as DynamoDB and S3, AWS applies patches without customer action.

What stays yours on every AWS service

Some responsibilities never move to AWS, whatever the service. AWS's service security pages repeat them:

• Your data, including how sensitive it is, who owns it and whether it is encrypted
• Identity and access, meaning IAM users, roles and policies and who can reach what
• Configuration you control, such as security group rules on EC2 and RDS
• Your legal and organizational obligations, which AWS lists as part of your share on its RDS, Lambda and S3 security pages

These four lines answer a large share of shared responsibility questions on their own. To rehearse them across many services, you can drill the 165 Security and Compliance questions planned for CLF-C02 prep once full prep launches.

Inherited, shared and customer-specific controls

AWS extends the model to IT controls and sorts them into three groups:

"Shared" here does not mean split 50/50. For patching, AWS patches the infrastructure and you patch your guest operating system and applications. For training, AWS trains its employees and you train yours.

Compliance follows the same pattern. AWS provides its own audit evidence through AWS Artifact, which offers on-demand downloads of reports such as ISO certifications, PCI reports and SOC reports. Those documents describe AWS's controls. Meeting your own compliance obligations for what you build remains your work.

Five shared responsibility traps on CLF-C02

These are Passy's reading of where the task statement's wording catches people:

1. "AWS patches everything in the cloud." Not on EC2. The guest operating system is yours, and so is any software you install on it.
2. "A managed service means AWS owns the data." No service moves data ownership, classification or IAM permissions to AWS.
3. "Security groups are an AWS feature, so they're AWS's job." AWS provides the firewall; configuring its rules is your responsibility.
4. "Encryption is AWS's responsibility." AWS offers the encryption options. Choosing and managing them for your data is part of your share, as the S3 security page puts it.
5. "Physical security is shared." It isn't. AWS lists physical and environmental controls as fully inherited.

Two shared responsibility practice examples, written by Passy

These are original examples, not AWS exam items.

Example 1. A company moves its self-managed PostgreSQL database from an on-premises server to Amazon RDS for PostgreSQL. Which task does the company still own after the move?

• A. Applying operating system patches to the database host
• B. Replacing failed storage hardware
• C. Controlling which users and applications can connect to the database
• D. Installing database engine software on the host

Keyed answer: C. AWS's RDS comparison lists operating system patching and database software installation as AWS tasks on RDS, and hardware is AWS's on every service. Access, through IAM, security groups and database users, stays with the customer. D is the near miss: you may choose a maintenance window, but AWS performs the installation.

Example 2. A team runs its application on AWS Lambda. Which two tasks are the team's responsibility? (Select two.)

• A. Patching the servers that run the functions
• B. Writing the function code and choosing its dependencies
• C. Granting the function only the IAM permissions it needs
• D. Maintaining the physical network in the data center
• E. Adding servers when traffic grows

Keyed answers: B and C. Lambda manages server maintenance, patching, capacity and scaling, which rules out A and E, and the physical network is always AWS's. Code and permissions remain the customer's.

If a responsibility question still doesn't click after the explanation, you can ask the planned AI Rescue for a memory trick on that responsibility split when full prep opens.

Studying shared responsibility for CLF-C02

Build a one-line "AWS does / I do" note for each service as you study it, starting with the three AWS names in the task statement: EC2, RDS and Lambda. Then add S3 and DynamoDB as the abstracted case. That table is short enough to review the night before the exam.

Next, learn the services that help with your side of the line. The CLF-C02 security services guide separates AWS WAF, AWS Shield, Amazon GuardDuty, Amazon Inspector and the other look-alikes. To see the style of scenario questions first, try Passy's free CLF-C02 practice questions, and use the CLF-C02 study time guide to place Domain 2 in your weeks.

Once the line between AWS and customer feels automatic, you can practice responsibility scenarios across every domain with the full CLF-C02 question bank planned for launch.