Shared Responsibility Model practice questions

Encrypting the physical disk drives in the AWS data center that host the database.

Why it fails: The shared responsibility model assigns AWS full responsibility for physical data center security, including the encryption and destruction of physical disk drives. A healthcare startup cannot directly encrypt AWS's physical infrastructure, as it never controls or accesses the underlying hardware. This option describes a provider-side safeguard, not a customer action, so it fails to satisfy the security measure the startup must implement in the exam scenario.

Applying operating system patches to the Amazon RDS database engine.

Why it fails: In Amazon RDS, the managed service model places responsibility for applying operating system and database engine patches on AWS. The customer cannot perform these patching operations because they lack SSH access or OS-level control to RDS instances. Moreover, patching is a maintenance activity, not an encryption control, so it does not address the requirement for encrypting data at rest and in transit.

Configuring network ACLs to block all traffic except from authorized sources.

Why it fails: Configuring network ACLs is indeed a customer responsibility and helps restrict traffic at the subnet boundary, but network ACLs are a network-layer access control mechanism, not a data encryption mechanism. They do not encrypt patient records stored in the RDS database or protect data in transit with SSL/TLS. Thus, this action would not meet the specific encryption-at-rest and in-transit requirements stated in the question.

AWS is HIPAA certified, meaning all AWS services automatically comply with HIPAA

Why it fails: HIPAA is a US legal and regulatory framework, not a certification program, so no vendor can be 'HIPAA certified.' Instead, AWS provides a set of services that are designated as HIPAA-eligible, and AWS will sign a BAA only for those specific services. Even with that designation, a customer must still configure the services with appropriate controls and document its own compliance, because many AWS services are not on the HIPAA-eligible list at all.

PHI cannot be stored in the cloud because cloud environments are inherently non-compliant with HIPAA

Why it fails: The belief that PHI cannot reside in a cloud environment is incorrect. AWS provides multiple HIPAA-eligible services, such as S3 with server-side encryption, RDS with Transparent Data Encryption, and CloudTrail for audit trails, that can legally store and process PHI when a BAA is in place and the customer follows required configurations. The cloud itself is not inherently non-compliant; compliance depends on how the system is architected, secured, and maintained by both the customer and AWS under the shared responsibility model.

HIPAA compliance is automatic once a BAA is signed with AWS

Why it fails: Signing a BAA with AWS is a necessary first step, but it does not make a customer's environment HIPAA compliant by itself. HIPAA compliance is an ongoing operational outcome that requires customers to implement technical safeguards such as encrypting PHI at rest and in transit, enforcing strict IAM access controls, and maintaining audit logs. AWS secures the underlying infrastructure; the customer must still configure each service and manage its own processes, policies, and user activity to meet the HIPAA Privacy and Security Rules.

AWS is responsible for both the operating system patches and the MySQL database updates.

Why it fails: Under the shared responsibility model, AWS is responsible for the security of the cloud, which includes physical data centers, networking, and the hypervisor layer, not for OS-level patches or software like MySQL. The company's obligation covers the EC2 guest OS, the installed applications, and the MySQL database, so AWS is not responsible for either component. This option completely misassigns both responsibilities, so it is incorrect.

AWS is responsible for the operating system patches, and the company is responsible for the MySQL database updates.

Why it fails: AWS never patches the guest operating system of an EC2 instance; that is a customer responsibility because the customer has admin access to the OS. AWS does maintain the underlying hypervisor and physical host, but these are invisible to the instance and not managed through the guest OS. While assigning MySQL updates to the company is correct in this scenario, the claim about AWS handling OS patches violates the shared responsibility model, making this answer incorrect.

The company is responsible for the operating system patches, and AWS is responsible for the MySQL database updates.

Why it fails: The company does indeed need to patch the operating system on its EC2 instance, but AWS does not update MySQL databases that run on that instance. If the MySQL database were deployed on Amazon RDS, then AWS would handle database patching and minor upgrades, but since it's part of the application on an EC2 instance, the company has full responsibility. Therefore, this option incorrectly offloads MySQL update duties to AWS, which is not how the shared responsibility model works for self-managed databases.

The company, because patches for underlying infrastructure are always the customer's responsibility in EC2.

Why it fails: This is incorrect because it conflates the host OS with the guest OS. Although EC2 is an Infrastructure as a Service (IaaS) offering where customers manage the guest OS, the underlying infrastructure—including the host OS and hypervisor—is always managed by AWS. AWS patches the host OS as part of its responsibility for the physical and virtualization layer, and the customer never has access to or responsibility for patching that host OS. Therefore, the statement that the company must patch underlying infrastructure is false.

The company, because EC2 is an Infrastructure as a Service (IaaS) offering and the customer manages the OS.

Why it fails: This is a common misunderstanding. Although customers manage the guest OS on EC2 instances, the host OS is part of the underlying cloud infrastructure and is managed by AWS. The customer's OS management responsibility is limited to the guest OS.

Both the company and AWS share responsibility equally for host OS patching.

Why it fails: This is incorrect because responsibility is not shared equally; it is divided by component. AWS has sole responsibility for patching the host OS, while the customer has sole responsibility for patching the guest OS, the applications, and the data within the instance. There is no joint or equal responsibility for any single layer of the stack, and specifically the host OS patching is owned entirely by AWS. Thus, saying both 'share responsibility equally' misrepresents the clear division of the Shared Responsibility Model.

Ensuring the physical security of AWS data centers

Why it fails: Ensuring the physical security of AWS data centers is wholly AWS's responsibility under the shared responsibility model. This includes perimeter fencing, biometric access controls, 24/7 security personnel, video surveillance, and environmental systems. A customer migrating on-premises applications has no visibility into or control over these physical controls, so this task cannot be performed by the customer. Even if the customer previously managed physical security for its own data center, AWS handles all physical security once workloads run in the cloud.

Patching the hypervisor layer that runs Amazon EC2 instances

Why it fails: The hypervisor layer that runs Amazon EC2 instances is fully managed and patched by AWS because the hypervisor is part of the virtualization infrastructure that AWS controls. Customers are only responsible for patching the guest operating system and applications inside their instances, such as applying updates to Linux or Windows within the guest OS. AWS applies hypervisor security updates and often live-migrates running instances to avoid downtime during maintenance. Therefore, a customer migrating from on-premises virtualization environments must adapt to this division of responsibility but never patches AWS's hypervisor.

Replacing defective hardware components in the AWS global infrastructure

Why it fails: Replacing defective hardware components in the AWS global infrastructure is a maintenance task owned entirely by AWS as part of the 'security of the cloud.' This spans failed hard drives, faulty network switches, and degraded memory modules inside AWS data centers. Customers never touch or manage the underlying hardware; they interact only with virtualized resources such as Amazon EC2 instances, which AWS automatically migrates off failing hosts. Thus, although a customer may have replaced server hardware on premises, that responsibility does not transfer to the cloud.

Resource pooling

Why it fails: Resource pooling refers to the ability of a cloud provider to serve multiple customers from shared physical resources, with dynamic assignment of virtual and physical resources to meet demand. It does not define the split of security responsibilities.

Elasticity

Why it fails: Elasticity is the ability of a cloud environment to automatically adjust compute capacity in response to real-time demand, such as adding EC2 instances during load spikes and removing them afterward. This capability directly supports availability and cost optimization, but it does not define how security responsibilities are distributed between AWS and the customer. The division of security tasks is established exclusively by the shared responsibility model, so elasticity would be a capacity-management mechanism, not a security-governance framework.

Measured service

Why it fails: Measured service is the cloud's metered, pay-per-use billing characteristic, where resource consumption such as compute, storage, and bandwidth is continuously monitored, reported, and invoiced. This attribute provides cost transparency and usage analytics, but it is a financial and operational mechanism rather than a security-related concept. The scenario asks who is accountable for which security controls, and that accountability is determined by the shared responsibility model, not by how resource usage is measured or billed.

AWS, because they own and operate all EC2 infrastructure

Why it fails: AWS does own and operate the physical data centers, hardware, and the hypervisor that isolates EC2 instances, but infrastructure ownership does not extend to the guest operating system. The service boundary for EC2 is explicit: once an instance is launched, the OS, applications, and their patches are under the customer's control. Therefore, AWS's ownership of the physical infrastructure is irrelevant to the specific duty of OS patching, making this answer incorrect.

Both AWS and the customer equally share this responsibility

Why it fails: The shared responsibility model is not a 50/50 split; it is a layered boundary. For EC2, AWS manages everything below the hypervisor—physical hosts, storage, networking—while the customer manages everything from the guest OS upward, including patches. Saying 'equally share' implies both parties co-own the same component, but OS patching is an exclusively customer-owned task, so this option misstates the model.

A third-party managed service provider designated by AWS

Why it fails: AWS never designates a third-party provider to perform OS patching on a customer's EC2 instance. The customer may choose to use a managed service provider or AWS's own Systems Manager Patch Manager, but that is a licensed, delegated tool—not a default responsibility transfer. The underlying obligation remains with the customer, and any third-party help is a contractual arrangement, meaning this option misidentifies the accountable party.

Patching the hypervisor that hosts the EC2 instances

Why it fails: The hypervisor is the virtualization layer that runs on AWS-managed host hardware and isolates EC2 instances from one another. Because a hypervisor vulnerability could affect multiple tenants, AWS controls and patches it along with the underlying host operating system. Customers only receive a logical instance and are responsible for patching the guest operating system and installed applications, not the hypervisor or host hardware.

Physical security of the data center where the instances run

Why it fails: AWS data centers are protected by multiple layers of physical security, including perimeter fencing, 24/7 security guards, biometric access controls, and video surveillance. These controls are independently audited under compliance programs like SOC, ISO, and PCI, and customers are never granted physical access to server rooms. Therefore, maintaining physical security and data center access is exclusively AWS's responsibility, not the application owner's.

Maintaining the underlying network infrastructure

Why it fails: The physical and logical network infrastructure that carries traffic inside AWS, such as data center switches, routers, and cabling, is operated and maintained entirely by AWS. Customers never access or manage these devices, and AWS isolates VPC traffic over this managed hardware. While customers configure virtual network constructs like VPCs and subnets, they cannot patch or maintain the underlying network devices, so this is not a customer responsibility.

Patching the MySQL database engine for the Amazon RDS instance.

Why it fails: Amazon RDS is a fully managed database service, which means AWS handles the operational heavy lifting, including patching of the MySQL database engine itself, whether it is a security fix or a minor version upgrade. You are responsible for your data, managing access with IAM and security groups, and setting the maintenance window, but you never log in to the underlying host or apply engine patches. Attempting to patch the engine yourself would be unnecessary and unsupported because AWS applies and controls those changes as part of the managed service.

Providing physical security at the AWS data center facilities.

Why it fails: Physical security at AWS data centers, including guards, biometric entry systems, fencing, and surveillance, is exclusively AWS's responsibility, as customers are never granted access to the physical facilities per the shared responsibility model. This obligation protects the underlying hardware that hosts customer workloads, and it is a foundational 'security of the cloud' element. A customer's duty begins only after they authenticate to the AWS API and control plane, not at the facility gate.

Replacing failed network switches in the AWS global network.

Why it fails: Replacing failed network switches in the AWS global network is a physical layer operation performed by AWS data center engineers, not by customers. The entire networking fabric—switches, routers, cabling, and uplinks—is part of AWS's 'security of the cloud' responsibility, and its failure or replacement never becomes a customer action. Customers only interact with virtual network constructs such as VPCs, subnets, and security groups, so hardware-level switch replacement is categorically outside any customer's operational scope.

Encrypting customer data stored in Amazon S3

Why it fails: Encrypting customer data in Amazon S3 is a customer responsibility because the customer decides which encryption mechanisms to apply and who can access keys. While AWS supplies features such as SSE-S3, SSE-KMS, and client-side encryption, the customer must configure bucket defaults and manage customer-managed keys when used. AWS cannot assume responsibility for data protection choices that are unique to each workload.

Configuring security groups for EC2 instances

Why it fails: Configuring security groups for EC2 instances is a customer responsibility because these virtual firewalls implement the customer's intended network traffic rules. AWS provides the security group feature and a default initial state, but a customer must define inbound and outbound rules, associate groups with instances, and manage updates based on application architecture. AWS does not know the application requirements, so it cannot configure security groups on the customer's behalf.

Managing IAM user access policies

Why it fails: Managing IAM user access policies is a customer responsibility because AWS only provides the identity and access management service, not the policies. A customer defines users, groups, roles, permission boundaries, and service control policies (where applicable), and must grant least-privilege permissions. AWS neither creates nor maintains customer identities, and any misconfiguration is the customer's accountability under 'security in the cloud'.

Patching the Lambda execution environment and runtime

Why it fails: Patching the Lambda execution environment is the provider's responsibility under the shared responsibility model. AWS maintains the runtime, applies security updates to the underlying Firecracker microVM, and updates the execution environment automatically. Customers never patch the Lambda infrastructure; at most, they choose a newer runtime version when AWS deprecates an older one.

Managing the underlying servers that run Lambda functions

Why it fails: Lambda is a fully serverless service, so no physical or virtual servers are exposed to the customer. AWS manages the server fleet, including capacity provisioning, hardware maintenance, and the hypervisor layer that isolates functions. The customer has no ability to log in to or configure any underlying server.

Ensuring Lambda scales automatically during traffic spikes

Why it fails: Lambda's automatic scaling is a built-in capability managed by AWS; the service scales by running multiple concurrent executions of your function in response to incoming events. Customers don't configure scaling policies, provision capacity, or manage concurrency limits at the infrastructure level. Although you can set reserved concurrency to control throughput or costs, the actual scaling mechanism is fully AWS-managed.