Shared responsibility, service by service
Lesson 1 of 3 in Shared Responsibility and the Security Map.
Everyone can recite the headline: AWS is responsible for security of the cloud, and you are responsible for security in the cloud. Almost nobody loses marks on that sentence. They lose marks on the next one, which the recitation hides: the line moves depending on the service.
Security of the cloud is the part you cannot inspect — Regions and Availability Zones, physical access, hardware and disk decommissioning, the hypervisor, the network backbone, and the code of managed services. You do not audit it by walking the floor; you consume AWS's audit evidence instead, which is why AWS Artifact is the right answer to "give the auditor evidence of data-centre controls" and why any option asking you to patch a hypervisor is a distractor.
Security in the cloud is everything you configure. And this is where the model gets teeth: on EC2 you patch the guest operating system; on Fargate you never see the host but you own the container image; on Lambda AWS patches the managed runtime but you decide when to migrate off a deprecated runtime version; on RDS AWS supplies the patches but you choose and apply the maintenance window; on S3 there is no operating system to argue about at all. Read the stack bottom-up and watch where the line sits.
The responsibility stack — AWS at the base, you at the top, one tier that moves
- Global infrastructure — AWS, always
Regions, Availability Zones, edge locations, physical and environmental controls, media and disk decommissioning. These are inherited controls: you satisfy them by running on AWS and evidence them from AWS Artifact — SOC reports, ISO certificates, PCI attestations. An option that asks you to test them yourself is wrong by construction.
- Hardware, hypervisor, and managed-service software — AWS, always
Host hardware, the virtualization layer, the network fabric, and the code behind managed services — the RDS engine automation, the Lambda execution environment, the KMS hardware security modules, the S3 storage layer. You cannot log into any of it, which is exactly why reaching for a managed service moves work across the line and is why "least operational overhead" so often selects one.
- Guest OS, runtime, and dependencies — the line that moves
On EC2 this is entirely yours: golden AMIs built by EC2 Image Builder, Systems Manager Patch Manager, the packages Amazon Inspector keeps finding. On Fargate the host is AWS's and the image is yours. On Lambda AWS patches the runtime, but you own your layers and dependencies and you own the migration when a runtime version is deprecated. On RDS AWS supplies engine and OS patches and you choose the maintenance window. On S3 the tier does not exist. One question — "whose software is it?" — resolves every variant.
- Network and firewall configuration — you, always
Security groups, network ACLs, subnet routing, whether anything has a public address, VPC endpoints, Network Firewall and Route 53 Resolver DNS Firewall rules, WAF web ACLs, load-balancer TLS policies. AWS gives you the controls; which port is open to the internet is a decision you made. Every "exposed to the internet" scenario on the exam is a configuration you own.
- Identity, resource policies, and encryption choices — you, always
IAM and resource policies, trust policies, permission boundaries, SCPs and RCPs, which KMS key encrypts what and who its key policy admits, whether credentials are temporary, whether MFA is enforced. AWS cannot tell you what least privilege means for your business, so the correctness of a policy is never shared — it is yours in every service, in every account, on every exam question.
- Data and its classification — you, always
What the data is, how sensitive it is, where it may live, how long it must be kept, and who may see it. Amazon Macie can discover and classify it for you, but the classification scheme and the retention requirement come from your organization. The top of the stack is the part no AWS service can own on your behalf.
Now the same information as an exam-usable table. Read down a column to see what never changes, and across a row to see what the service model bought you.
| Service | Guest OS / host | Runtime & dependencies | Encryption at rest | Network exposure | IAM & resource policy |
|---|---|---|---|---|---|
Amazon EC2 | You. Golden AMIs, EC2 Image Builder, Systems Manager Patch Manager. | You. Everything above the OS, including the packages Inspector flags. | You. EBS encryption and which KMS key. | You. Security groups, NACLs, subnet, public IP, IMDSv2. | You. The instance profile and how narrowly it is scoped. |
AWS Lambda | AWS. There is no host you can reach. | Shared. AWS patches the managed runtime; you own layers, dependencies, and the migration off a deprecated runtime version. | You. The key for environment variables, and the keys on whatever it reads and writes. | You. VPC attachment, security groups, and the function resource policy. | You. The execution role — and |
AWS Fargate | AWS. You never see or patch the host. | You. The container image: base image, packages, and what the entrypoint runs. | You. Keys on EFS volumes, secrets, and the data stores it touches. | You. Task networking mode, subnets, security groups. | You. Task role and task execution role — two different things, and the exam knows it. |
Amazon RDS | Shared. AWS supplies OS and engine patches; you choose and approve the maintenance window. | AWS for the engine. You for schema, database users, and in-database grants. | You. Chosen at creation with its KMS key — you cannot encrypt an unencrypted instance in place. | You. Subnet group, security groups, and the public accessibility flag. | You. The IAM policy, plus whether you use IAM database authentication at all. |
Amazon S3 | AWS. No operating system exists in this model. | Not applicable. | You. SSE-S3, SSE-KMS, SSE-C, or client-side — and the key policy behind it. | You. Block Public Access, bucket policy, access points, VPC endpoint policy. | You, entirely. AWS has never misconfigured anyone's bucket policy. |
Interactive sorting exercise: Whose job is it? Sort each responsibility to AWS, to you, or to the genuinely shared middle.
The exam monetises one consequence above all others: AWS never misconfigures your resource policies. When a stem describes data exposure — a public bucket, an over-shared snapshot, a cross-account role anyone can assume, an unencrypted volume — the cause is on your side of the line by definition, and the correct answer is a control you own. That is why so many Data Protection and IAM items resolve to a resource policy, Block Public Access, an SCP or RCP, a KMS key policy, or a Macie or Access Analyzer finding, and why "contact AWS Support" is never the key.
The second consequence is subtler and worth money: moving up the service stack moves work across the line, but never all of it. Choosing Fargate deletes host patching from your plate and leaves image hygiene. Choosing RDS deletes engine installation and leaves the maintenance window, the subnet group, and the encryption decision you can only make at creation. Choosing S3 deletes the operating system entirely and leaves you the whole policy surface. "Least operational overhead" is the phrase that invites you to make that trade — and it is never a licence to assume AWS took over your policies too.
The RDS trap: encryption at creation
You own the encryption decision for an RDS instance, and you can only make it when the instance is created. An unencrypted instance cannot be encrypted in place; the supported path is a snapshot, a copy of that snapshot with encryption and a KMS key, and a restore. Expect a stem that describes an existing unencrypted production database and a requirement to encrypt it — the distractor is "enable encryption on the instance".
The Fargate trap: no host does not mean no patching
Removing the host removes host patching. It does not remove the vulnerable OpenSSL in your base image, the secret baked into a layer, or the root user your container still runs as. Scan images with Amazon Inspector in the registry, rebuild from minimal bases, and keep the task role separate from the task execution role — the execution role pulls the image and writes logs; the task role is what your code uses.
The Lambda trap: two kinds of runtime responsibility
AWS patches the runtime; you own the version. When a runtime reaches end of support, functions on it stop receiving patches, and the remediation is your deployment, not AWS's. Your dependencies and layers were always yours — Inspector scans Lambda functions and layers for known CVEs precisely because that is customer-side software.
Managed services still have customer-side identity
Every managed service question eventually becomes an identity question: which role does the service assume on your behalf, and who is allowed to hand it that role? A training job, a Lambda function, a Fargate task, a Config remediation and a Systems Manager automation all act through a role you wrote. An iam:PassRole permission scoped to the specific role, with an iam:PassedToService condition naming the service, is how you stop someone attaching a powerful role to a service they control.
What AWS Artifact is actually for
Artifact is on-demand access to AWS's compliance reports and agreements — SOC 1, SOC 2, SOC 3, ISO certificates, PCI documents — plus the ability to accept agreements such as a BAA. It is the answer to "evidence the controls AWS owns". It is not evidence about your configuration: that comes from Config, Security Hub, Audit Manager, and CloudTrail.
Key terms: Shared responsibility model, Security “of” the cloud, Security “in” the cloud, Inherited controls, Least privilege