Amazon AWS CLF-C02: Shared Responsibility Model

The AWS shared responsibility model is simple enough to summarize in one sentence and easy to misunderstand in practice. AWS secures the infrastructure that runs the cloud, while customers remain responsible for the way they configure and use cloud services. The exam challenge is recognizing that the customer side changes with the service model. Managing an EC2 instance creates different duties from storing objects in Amazon S3 or running code in a serverless service.

For the current Amazon AWS CLF-C02 exam, shared responsibility belongs inside the 30% Security and Compliance domain. That makes it more than a vocabulary item. Candidates need to reason about who patches what, who controls identities, who protects data, and which tasks AWS absorbs as a service becomes more managed. Across AWS CLF-C02, shared responsibility becomes clearer when each scenario is broken into layers.

Start with security of the cloud and security in the cloud

AWS is responsible for security of the cloud: the physical facilities, hardware, networking infrastructure, virtualization layer, and foundational services used to deliver AWS. Customers are responsible for security in the cloud: their data, identities, configurations, operating systems when applicable, application controls, network rules, encryption choices, and compliance settings. The exact boundary moves depending on the service being used.

The fastest way to reason about a scenario is to ask who owns the layer where the control lives. If the issue is a physical data center door, AWS owns it. If the issue is an overly permissive S3 bucket policy, the customer owns it. If the issue is a guest operating system on EC2 that has not been patched, that is generally a customer responsibility. The service boundary tells you where control changes hands.

EC2 leaves more operational responsibility with the customer

Amazon EC2 provides virtualized compute, but the customer still manages much of what runs inside the instance. That commonly includes the guest operating system, installed software, application configuration, host-based firewall rules, credentials, and data. AWS operates the physical servers, facilities, hypervisor, and underlying infrastructure. This makes EC2 a strong example of why cloud does not mean “AWS secures everything.”

When a question describes malware on a server, an unpatched guest OS, a weak application configuration, or an exposed security group, look first at the customer side of the model. If the problem concerns a failed physical disk in the AWS fleet or facility power, it belongs to AWS. Managed services shift some of these duties upward to the provider, but customers still own how they configure access and protect their information.

Managed services move the boundary, not the accountability

With a managed database or serverless service, AWS operates more of the underlying stack. Customers may no longer patch an operating system or database engine directly, yet they still decide which identities can connect, what data is stored, how encryption is configured, which networks are allowed, and how application code behaves. The operational burden shrinks without eliminating customer accountability.

This is a common exam trap: seeing “managed” and assuming “AWS responsibility.” A better question is: which control has become invisible to the customer because AWS now runs it, and which configuration remains exposed to the customer? Serverless functions, managed databases, and object storage remove infrastructure work, but access policies, data classification, secrets, application logic, and monitoring can still create serious customer-side risk.

Identity remains a customer responsibility across service models

AWS runs the IAM service, but customers decide which principals exist, which permissions they receive, how credentials are protected, and whether least privilege is enforced. That distinction matters across virtually every AWS service. A highly managed service can still be compromised by a badly designed identity policy. Root-user protection, MFA, role use, credential hygiene, and access review remain customer concerns.

For CLF-C02, do not dive too deeply into policy language. Focus on the responsibility principle: AWS makes identity services available and secures the infrastructure behind them; the customer configures access correctly. When permissions are excessive, inactive users remain enabled, or an application is given long-lived credentials unnecessarily, the customer owns the corrective action.

Data responsibility follows the customer even when storage is managed

Customers decide what data enters AWS, how sensitive it is, who may access it, how long it is retained, and which encryption or backup choices apply. AWS provides durable storage services and security capabilities, but it does not automatically know the business classification or legal importance of a customer’s information. Data governance therefore remains a customer function even when hardware and storage software are fully managed.

Shared responsibility also means understanding default behavior. A service may encrypt data by default or offer public-access blocking, but the customer is still responsible for validating that the configuration satisfies the organization’s requirements. Data deletion, retention, key management, replication choices, and recovery testing can all remain customer decisions. “AWS provides the capability” and “the customer has configured it correctly” are different statements.

Network security is divided across layers

AWS operates the global network and the underlying infrastructure that connects services. Customers configure many logical network controls inside their environments, including VPC design, security groups, network ACLs, routing, private connectivity, and application exposure. If a workload is reachable from the internet because the customer allowed broad inbound traffic, the shared responsibility model places that configuration on the customer side.

The exam does not require deep network engineering, but it does expect candidates to recognize the boundary. AWS can provide resilient networking and security services while the customer still chooses an unsafe architecture. Cloud security is collaborative: provider infrastructure can be secure and the customer’s environment can still be poorly configured at the same time.

Compliance responsibilities are also shared

AWS maintains certifications, audits, and compliance programs for the cloud infrastructure and many services. Customers use that evidence as part of their own compliance programs, but they remain responsible for the data, workloads, configurations, and business processes they operate. Using a compliant cloud provider does not automatically make a customer’s application or organization compliant.

Think in terms of evidence. AWS may provide reports and attestations through services such as AWS Artifact, while customers must show how their own access controls, retention settings, logging, risk management, and operating procedures meet applicable requirements. The provider supplies evidence about its layer; the customer supplies evidence about theirs. Many real compliance outcomes require both.

Responsibility changes during incidents, but the boundary still matters

During an incident, customers investigate their workloads, identities, data access, and configurations using the telemetry available to them. AWS investigates provider-side infrastructure when appropriate. The boundary helps teams know what evidence they can collect directly and when they need provider support. It also prevents wasted effort, such as trying to patch a platform layer the customer does not control.

A mature incident process maps each control and log source to an owner before an emergency happens. If an application credential is abused, the customer revokes or rotates it. If an AWS service experiences a regional impairment, AWS restores the service while the customer executes its own resilience plan. Shared responsibility does not mean the parties wait for each other; it means each knows which actions are theirs.

Use scenario questions to identify the moving boundary

CLF-C02 questions often become easier when you ignore the product names for a moment and identify the layer. Ask whether the scenario concerns facilities, hardware, virtualization, guest operating systems, application code, identities, data, or configuration. Then ask how managed the service is. The more infrastructure AWS manages, the fewer low-level operational tasks remain with the customer, but customer decisions about data, identity, and access remain prominent.

A useful study exercise is to compare EC2, a managed database, S3, and a serverless function. For each, write who patches the operating environment, who defines access, who manages application code, who classifies data, and who chooses encryption or retention settings. The purpose is not to memorize four tables; it is to build the reasoning pattern that transfers to unfamiliar services.

Shared responsibility explains why cloud security requires both a trustworthy provider and disciplined customer configuration. AWS absorbs physical and platform responsibilities that organizations would otherwise operate themselves. Customers gain speed and managed capability, but they still own the decisions closest to their business: identities, information, applications, policies, and service configuration.

For CLF-C02, remember the boundary is dynamic. Start from the layer, then consider the service model, then identify the configuration or operational decision being tested. That method is more reliable than memorizing “AWS versus customer” examples because it continues to work as new managed services are introduced.

Another useful comparison is responsibility for software updates. AWS patches the infrastructure and managed platform layers it operates. Customers patch guest operating systems and applications when those layers remain under their control. As services become more managed, some patching duties move to AWS, but customers still decide when their own application dependencies, container images, or code must be updated. The responsibility boundary follows control.

Billing and support do not change the model either. Paying AWS for a managed service does not transfer responsibility for customer data classification, IAM permissions, or business continuity planning. Support can assist with provider-side issues and service behavior, but the customer must still design secure configurations and recovery plans. That distinction helps eliminate exam answers that imply AWS assumes business ownership simply because a service is managed.

When in doubt, identify the control surface. If the customer can configure the setting in its account or application, customer responsibility is usually involved. If the control belongs to AWS facilities or the managed platform layer and is not exposed to the customer, AWS responsibility is usually involved. This simple test resolves many foundational exam scenarios.