A company stores sensitive customer files in Amazon S3. It assumes AWS will prevent inappropriate disclosure because the service is managed. An employee then makes an access policy too broad, allowing information to be read by people who were never approved. The physical data center remains secure, but the information is exposed through a customer-controlled configuration. This illustrates the central shared responsibility lesson: AWS manages the security of its cloud infrastructure, while customers retain important responsibilities for how they configure, access, and use services within it.
The AWS Certified Cloud Practitioner CLF-C02 exam places shared responsibility in its Security and Compliance domain, which contributes 30 percent of scored content. The exam expects learners to recognize how responsibility shifts among service models, without assuming that managed services eliminate all customer work. A reliable mental model starts by asking what the provider operates and what the customer chooses.
Distinguish security of the cloud from security in the cloud
AWS is responsible for protecting the infrastructure that operates its services, including important physical and foundational technology layers. Customers are responsible for their data, identities, configurations, and applicable workload controls according to the services they use. The exact split differs; it should never be interpreted as one party owning ‘security’ while the other owns everything else. Both sides have material roles.
Cloud adoption does not transfer legal or business accountability for customer records to the provider. A company still needs to determine which information can be collected, retained, transferred, and disclosed. It must configure appropriate access and comply with relevant obligations. Provider assurance reports and certifications can supply supporting evidence, but they do not establish that a particular customer’s application is compliant.
An employee who gives broad access to a storage resource may create a customer-side problem even when the provider’s underlying storage systems operate correctly. Similarly, a secure building and healthy hardware cannot prevent an application from accepting an unauthorized money transfer due to faulty business logic. Shared responsibility is about control boundaries, not blame after an incident.
See how EC2 changes customer obligations
Amazon EC2 provides virtual compute resources, but customers manage substantial aspects of the guest operating system, installed software, application configuration, and identity permissions. Security updates, service exposure, data protection, and application code require customer attention. AWS operates underlying infrastructure components according to its model, yet a neglected guest system can still become vulnerable to known attacks.
Imagine a virtual machine running a customer-facing web application. The team must decide which ports are open, who can administer it, how credentials are stored, how the operating system is patched, and which logs are collected. These choices are not made safe merely because the instance appears under a managed cloud account. Change control and vulnerability response remain essential operational practices.
The team also needs backup and recovery procedures. A virtual machine instance can fail, data can be deleted accidentally, or an application update can corrupt records. Responsibility for business continuity depends on the architecture and selected services. The provider’s durable infrastructure does not replace the customer’s decisions about snapshots, retention, recovery testing, and application design.
Understand what managed databases change
Managed database offerings such as Amazon RDS can take on some infrastructure and maintenance responsibilities that a customer would otherwise perform directly. This can reduce the operational burden, but customers still define database users, application privileges, data retention, network exposure, schema, and business queries. A managed database with a permissive access role can disclose information just as an improperly configured self-managed database can.
Availability options also require deliberate selection and understanding. The fact that a service is managed does not guarantee that every configuration includes cross-zone or cross-region redundancy. Business continuity depends on the chosen setup, service capabilities, backups, and application behavior. Customers should test recovery instead of reading ‘managed’ as a promise that no outage can happen.
Updates can affect application compatibility. The provider may perform supported maintenance under service arrangements, but the customer still needs to understand timing, connection handling, and application readiness. Shared responsibility includes planning for change at the boundary where managed infrastructure supports customer-controlled software.
Understand serverless responsibilities
AWS Lambda removes many traditional server administration tasks from the customer’s workload. The customer still writes or supplies code, chooses dependencies, configures permissions, manages secrets, and validates inputs. A serverless function that accepts untrusted data without checking it can cause harm even when every underlying host is patched by the provider.
Execution roles deserve particular attention. A function that reads one approved object should not receive broad permission to delete unrelated resources. Event-driven systems may be invoked frequently and automatically, increasing the impact of a bad permission or input-validation decision. Managed execution does not excuse missing application-level controls or monitoring.
The responsibilities may also include safe handling of retries and business state. If a message is delivered again, application code may need idempotency to avoid double billing. Those correctness obligations belong to the service designer. They are examples of why provider operational assurance and customer application responsibility work together.
A team moving a scheduled script from an EC2 instance into Lambda may no longer manage a guest operating system for that function, but it still owns the script’s dependencies and the permissions with which it executes. If the function can read an entire customer dataset when its task requires only one partition, that exposure reflects a customer decision. If application secrets are embedded in source code or logs, the managed execution environment does not cure the disclosure. Smaller infrastructure responsibilities should free teams to improve application and data controls, not convince them there is nothing left to secure.
The boundary also has consequences for incident response. In an instance-based application, investigators may need host operating-system telemetry, disk and process evidence, and network events. For managed services, available evidence may instead come from application instrumentation, platform events, configuration history, and provider-exposed logs. An organization should identify which evidence it needs before an incident and verify that collection and retention are actually enabled. It should not promise forensic access to provider-managed layers that customers do not control.
Shared responsibility is easiest to remember through ownership questions. Who can change the resource’s policy? Who decides which data may enter it? Who verifies backups against business recovery requirements? Who patches the infrastructure beneath the service? Those answers may be split across AWS, an internal platform team, and the application owner. Writing the boundary into operational runbooks reduces the risk that each group assumes another group is monitoring a critical control.
Protect identities and data deliberately
IAM policies, federation, role trust, and multifactor authentication help customers manage access, but they must be configured and reviewed. Protecting the AWS account root user is an important practice. Day-to-day work should normally use appropriately scoped identities rather than routine use of the most powerful account credentials. Service identities should be rotated, monitored, or managed using supported mechanisms where appropriate.
Data security includes encryption, classification, access control, and lifecycle decisions. Services such as AWS KMS and Secrets Manager can help with specific requirements, but enabling a service does not prove that a workload uses it correctly. A developer can still write a secret into a public repository or distribute an export outside approved channels. Customers must understand where sensitive information moves and who has access.
Logs and monitoring support evidence. CloudTrail helps record supported API activity; CloudWatch supports operational telemetry; Config can help evaluate resource configurations. These products play different roles and require suitable customer setup, retention, and response procedures. Logging only helps if someone can investigate and act when a significant event occurs.
Use provider assurance as evidence, not a substitute
AWS publishes information about its compliance programs and assurance materials, including through AWS Artifact where applicable. Customers can use these resources to support their own assessment of provider-controlled infrastructure. They still need to evaluate how their workloads satisfy organizational and regulatory requirements. A compliance statement about cloud infrastructure does not automatically cover a customer’s access policy, employee behavior, or application code.
The shared responsibility model also affects incident management. If a workload identity is compromised, the customer must understand which credentials and configurations to revoke and what evidence it needs. Provider support may help with relevant infrastructure issues, but the organization cannot delegate every detection and containment decision away. Incident procedures should reflect both sides’ roles.
Choose controls according to workload exposure and managed-service scope. A public API serving customer accounts needs different application checks from a private data-processing job, even if both run in AWS. Cloud security maturity depends on consistent decisions about actual information and transactions rather than an assumption that service certification covers every possible misuse.
Use the model in exam scenarios and design reviews
When a scenario asks who patches a guest operating system on EC2, think about the customer-controlled instance. When a scenario asks who secures foundational physical facilities, think about provider responsibility. When a scenario involves overly broad permissions to an S3 object or an unvalidated Lambda input, focus on the customer’s configuration and application decisions. The correct answer depends on the boundary described, not a slogan.
Further AWS Security Specialty study explores the controls in much greater depth, but the foundational principle remains constant: managed services shift selected tasks, not accountability for the business use of data and applications. Clear ownership of each layer prevents dangerous gaps where the provider assumes the customer will act and the customer assumes the provider has already done so.