The AWS Shared Responsibility Model divides security obligations between AWS and the customer. AWS secures the infrastructure—physical data centers, hardware, host operating systems, and the virtualization layer. You, as the customer, are responsible for everything you deploy and configure on top of that layer. Getting this boundary clear is essential for answering Security and Compliance questions on the exam.
EC2 and the Guest OS Boundary
With Amazon EC2, the division is straightforward in principle but easy to misread under exam conditions. AWS manages the physical host, the hypervisor, and the underlying network hardware. Once your instance launches, the guest operating system becomes your responsibility. That means you must apply OS-level patches, configure firewalls through security groups and network ACLs, manage IAM credentials, and protect any customer data stored on attached EBS volumes.
Study example: Imagine a company runs a web application on an EC2 instance using a supported Linux distribution. A new kernel vulnerability is disclosed. Who must patch it? The customer patches the guest OS; AWS patches the physical host and hypervisor. The customer chooses appropriate EBS encryption configuration and manages any long-lived IAM access keys it creates. AWS operates the underlying encryption capability; workloads should use appropriate temporary credentials where possible.
This is the pattern behind dozens of practice items. When you work through AWS Cloud Practitioner practice questions, filter for Security and Compliance scenarios and note every distractor that tries to shift a customer task onto AWS.
How Managed Services Shift the Boundary
The boundary moves when you use managed services. With Amazon RDS, for instance, AWS handles the underlying OS on the managed host and hardware maintenance, and many engine patching tasks are handled through the managed service model. You still remain responsible for how you configure and operate the database features available to you. You retain responsibility for database user permissions, encryption-at-rest settings you choose at creation, network access rules, and the data itself. You do not log into the RDS host OS—that layer belongs to AWS.
Similarly, with AWS Lambda you never manage a server OS at all. Your responsibility shrinks to your function code, the libraries you package with it, IAM execution roles, and your data inputs and outputs. The boundary is narrower, not absent.
A concise review resource such as the AWS Cloud Practitioner cheat sheet can help you keep these service-level distinctions organized before exam day.
Practice Question
A company stores sensitive records in Amazon S3. Its policy requires a particular customer-managed KMS key and defined key-access permissions. Who is responsible for choosing and configuring those customer-specific settings?
- A: AWS, because S3 is a managed service and AWS controls all storage settings
- B: The customer, because its key selection and access configuration must meet its own requirements
- C: AWS, because physical storage security falls under the AWS side of the model
- D: Neither party; default encryption automatically satisfies every customer-specific key policy
Correct answer: B. S3 automatically encrypts new object uploads at rest with a default baseline. That does not select this company’s required customer-managed KMS key or design its key permissions. The customer must configure and verify those requirements, while AWS operates the underlying service. D overstates what the default establishes; automatic encryption and customer-specific key governance are different questions.
Official exam reference: AWS Cloud Practitioner exam guide. These study examples are independently written.