CLF-C02: Who Secures What in AWS?

A company moves a customer database into a managed AWS service. A month later, an auditor finds that far too many employees can read the records. The platform is patched, the storage is operating normally, and AWS has not suffered an infrastructure failure. Yet the customer data is exposed because permissions were assigned without adequate review. The incident illustrates the most consequential cloud-security misunderstanding: a provider’s secure infrastructure does not automatically mean a customer’s configuration is secure.

Security and Compliance contributes 30% of the scored AWS CLF-C02 blueprint. That domain combines the shared responsibility model with identity, governance, compliance and security services. The most useful way to learn it is to connect each control to the decision it protects. Definitions alone do not explain how risk enters an account.

Shared responsibility changes as services become managed

AWS is responsible for security of the cloud: the physical facilities, underlying global infrastructure and certain managed service components. Customers are responsible for security in the cloud: their data, access decisions, configurations and workload-specific protections. The customer portion varies by service. On Amazon EC2, for example, the customer has significant control over the guest operating system and software. On a more managed service, AWS operates additional layers, but the customer still decides who can access data and how it is used.

Imagine deploying an application on EC2. The team chooses an operating-system image, applies updates, configures remote access and maintains the application. If it instead uses an AWS-managed database, portions of host and database-engine maintenance move to AWS. It does not follow that the company can ignore database credentials, network exposure, encryption choices or backup settings. Security is a series of allocations of responsibility, not one fixed line that applies identically across every product.

This model is especially important when a team adopts a service for convenience. Reduced maintenance is a legitimate reason to use managed services, but operational simplicity should create time for better data governance rather than an assumption that governance has disappeared.

Identity begins with the tasks people actually perform

AWS Identity and Access Management (IAM) lets administrators define permissions for users, roles and services. Policies describe which actions are allowed or denied under relevant conditions. A useful starting point is the job: a developer may need to view logs and deploy to a test environment but should not automatically have unrestricted access to production billing, security policies or personal data. Assigning access based on titles alone is rarely precise enough.

Consider a reporting job that reads source objects and writes a daily output file. Giving the job a role that can administer every S3 bucket is easy, but it increases damage if the code is compromised. Permissions scoped to the relevant resources and operations are safer. IAM roles also reduce the need to distribute long-lived access keys to workloads. Multi-factor authentication adds protection to user sign-in, especially for privileged accounts, but does not compensate for granting excessive permissions once a session is authorized.

Root-account credentials deserve particularly careful protection. They should not be used for routine application work. Teams also need to manage the entire access lifecycle: joining, changing responsibilities, emergency privileges and departure. A permission that was appropriate during a migration can become unnecessary risk after the project ends.

Authentication, authorization and encryption solve separate problems

Authentication establishes who or what is making a request. Authorization determines whether that identity can perform an action. Encryption helps protect information from unauthorized disclosure, whether stored or transmitted, when used with appropriate key management and protocols. These controls reinforce one another without substituting for one another. Encrypting a database does not stop an authorized but overprivileged employee from exporting records.

AWS Key Management Service (KMS) helps manage cryptographic keys used by integrated services and applications. Certificate services can support managed certificate lifecycles for relevant uses. Secrets Manager helps handle application secrets rather than embedding credentials in code. Each service protects a different point in the trust chain. A team selecting them must also consider permissions to use keys or retrieve secrets, because access to a protective service can itself become sensitive.

Transport encryption matters when information crosses networks. Storage encryption matters when media or stored data is exposed. Neither answers whether an application should collect the information in the first place or retain it for years. Compliance requirements often influence retention, access evidence and key handling, so the protection model must begin with data sensitivity and the business process that uses it.

Accounts and organizational guardrails need a purpose

Separating workloads across AWS accounts can reduce the consequences of mistakes and simplify billing or governance boundaries. AWS Organizations offers mechanisms for managing groups of accounts, and service control policies can establish permission guardrails across parts of an organization. A guardrail limits possibilities; it does not automatically grant permissions that IAM otherwise denies. Candidates should understand that distinction rather than treating every policy system as interchangeable.

Picture a firm with a public website, regulated analytics processing and a disposable experimentation environment. Independent account boundaries can make cost ownership and administrative privileges clearer. Central teams may set broad restrictions while product teams manage authorized resources within them. When a new project starts, account provisioning should apply logging, role and budget standards, not depend on someone remembering a checklist at the end.

Governance also includes operational behavior. Someone must review unusual spending, dormant access, open network paths and failed compliance checks. Automated controls can make these problems visible, but the organization must define which conditions are acceptable and which require intervention. A report that nobody owns is not an effective security program.

Network exposure and workload protection remain customer decisions

A virtual private cloud, subnets, security groups and network ACLs help define traffic boundaries for relevant AWS resources. A workload that only needs internal access should not receive unnecessary public inbound connectivity. But a private subnet alone is not a complete protection strategy. An attacker with valid credentials or a compromised application process may still access allowed resources. Identity, patching and application security matter alongside networking.

AWS WAF can help filter supported web traffic, while AWS Shield provides distributed-denial-of-service protections according to its capabilities and plan. Amazon GuardDuty analyzes certain signals to identify potentially malicious activity. AWS Security Hub helps aggregate and prioritize security findings. These products have distinct roles: traffic filtering, DDoS protection, threat detection and posture visibility are not four names for the same firewall.

For example, a web application can be reachable over HTTPS and still contain a vulnerable upload feature. Blocking unrelated network ports is good practice but does not remove the vulnerable code. Conversely, a well-patched application could expose an administrative panel to the internet because of a broad security-group rule. Good protection considers multiple failure paths without claiming that any single tool guarantees safety.

Compliance is evidence, not a logo on a provider page

AWS maintains assurance programs and publishes documentation about its infrastructure controls. Services such as AWS Artifact can provide access to certain compliance reports and agreements. Customers still need to map their obligations to their workloads: data location, retention, access approvals, audit logging, breach notification and contractual requirements may depend on the organization’s industry and jurisdiction. A provider certification is not a blanket approval of every customer deployment.

Take a customer-service database containing personal information. An organization may have to justify which staff roles can view records, how access is logged, whether the data can leave a geographic area and when it should be deleted. The infrastructure provider can contribute evidence about its controls, but it cannot determine the legal purpose of collecting the records. That belongs to the customer. A practical compliance review traces each obligation to a technical or procedural control and identifies the evidence that the control works.

Conversations about compliance are stronger when they separate what a service supports from what a workload is configured to do. Choosing an eligible region is necessary for some data-location policies, but replication, backups, external integrations and support processes still need attention.

Detection requires both signals and a response owner

CloudTrail helps record AWS account and API activity; CloudWatch supports telemetry and alarms for workloads and services. AWS Config can track configuration information and changes. Security-oriented detection services add other kinds of signals. These tools are most valuable when a security team knows what behavior deserves investigation. An audit event showing a role change is meaningful only in context: was it an approved deployment, an emergency action or an unexpected privilege escalation?

A response plan should identify who can examine evidence, revoke access, isolate affected resources and communicate business impact. Logs should be protected from casual tampering, and retention should reflect investigations and compliance needs. Alert volume should be tuned around real risks, otherwise important signals become indistinguishable from routine activity. Detection without authority to act creates a time delay at exactly the wrong moment.

Learners who later specialize in investigation and controls can explore the deeper scope of AWS Security Specialty. For CLF-C02, the essential skill is identifying which broad mechanism addresses the problem and what customer responsibility remains.

Use the responsibility model as a diagnostic tool

When presented with a security scenario, ask four questions. What asset is at risk? Which actor or service makes the security decision? Who manages that control? What evidence would show that it is working? If a stored object is public, permissions and policy are likely relevant. If a guest operating system is unpatched, customer patch management is relevant. If a managed database experiences an underlying infrastructure fault, the provider’s operational responsibility is involved, while application recovery expectations still need examination.

The answers are not always a single AWS product. A trustworthy cloud workload combines identity, data protection, network controls, governance and incident response. The purpose of the shared responsibility model is to keep both provider and customer duties visible while services become easier to deploy. That clarity is more durable than memorizing slogans about the cloud being secure by default.