The Security Pillar of the AWS Well-Architected Framework is a set of design principles and best practices for protecting data, systems, and assets in the cloud. For the CLF-C02 exam, this objective falls under Domain 2: Security and Compliance, which carries approximately 25% of the total score — the largest single domain. This chapter covers what the Security Pillar is, its six design principles, the shared responsibility model, and how to apply these concepts to AWS services. Mastering this chapter is critical because security questions appear in every section of the exam.
Jump to a section
Imagine you own a high-security bank vault. Your vault is a physical room with thick walls, a heavy door, and a combination lock. You hire a guard to watch the door and check IDs. This is your on-premises security model. Now consider a cloud security model: you still own the vault and its contents, but you rent a room in a skyscraper that already has building security, fire suppression, and reinforced floors. The building management (AWS) is responsible for the perimeter, the walls, and the public lobby. You are responsible for your vault door, the combination, and who you let inside. If you leave your vault door open, the building security cannot help you. If someone picks your lock because you used a weak combination, that is your fault. AWS gives you tools to set strong combinations (IAM policies), to monitor who tries the door (CloudTrail), and to add extra locks (encryption). But you must use them. The exam tests whether you know which security responsibilities belong to AWS (the building) and which belong to you (the vault owner). Many candidates confuse 'shared responsibility' with 'AWS does everything' — that is a trap.
What is the Security Pillar?
The Security Pillar is one of the six pillars of the AWS Well-Architected Framework. It provides a set of design principles and best practices to help you build secure workloads in the cloud. The pillar is organized into seven focus areas: identity and access management, detective controls, infrastructure protection, data protection, incident response, and compliance. The exam tests your understanding of these areas and how they map to AWS services.
The Problem It Solves
Before the cloud, security was often bolted on after the application was built. Physical servers lived in data centers with perimeter-based defenses. In the cloud, the perimeter is virtual, and you must design security into every layer. The Security Pillar gives you a structured way to think about security from the start — it shifts security from a 'checklist' to a 'continuous process.'
How It Works: The Six Design Principles
Implement a strong identity foundation – Use AWS Identity and Access Management (IAM) to create least-privilege permissions. Enable multi-factor authentication (MFA) for all users. Centralize identity management with AWS Single Sign-On (SSO) or federation.
Enable traceability – Monitor, alert, and audit actions and changes in your environment. Use AWS CloudTrail to log API calls, Amazon CloudWatch for metrics and alarms, and AWS Config for configuration history.
Apply security at all layers – Do not rely on a single perimeter. Use security groups and network ACLs for network layer security, AWS WAF for web application firewalls, and AWS Shield for DDoS protection.
Automate security best practices – Use AWS services like AWS Config rules to automatically check compliance, AWS Systems Manager to patch instances, and AWS Lambda to remediate non-compliant resources automatically.
Protect data in transit and at rest – Encrypt data at rest using AWS Key Management Service (KMS) or server-side encryption (SSE). Encrypt data in transit using TLS/SSL. Use AWS Certificate Manager (ACM) to manage certificates.
Prepare for security events – Have an incident response plan. Use AWS CloudFormation to create a 'golden AMI' for forensic analysis. Automate response with AWS Lambda and AWS Step Functions.
The Shared Responsibility Model
This is the most important concept for the exam. AWS is responsible for the security of the cloud — the physical infrastructure, hardware, software, and facilities. You are responsible for security in the cloud — your data, applications, identity and access management, network controls, and operating system patches. The line moves depending on the service: for Amazon EC2 (IaaS), you manage the guest OS, firewall, and application. For Amazon RDS (PaaS), AWS manages the database engine and OS, but you manage data access and encryption keys. For Amazon S3 (SaaS), AWS manages the underlying infrastructure, but you manage bucket policies, access controls, and data encryption.
Key AWS Services for the Security Pillar
IAM – Create users, groups, roles, and policies. Key concepts: principal, action, resource, condition. Use managed policies for common permissions.
AWS Organizations – Centrally manage multiple AWS accounts. Use Service Control Policies (SCPs) to set permission guardrails.
AWS KMS – Create and manage encryption keys. Integrates with many AWS services for envelope encryption.
AWS CloudTrail – Records all API calls in your account. Enabled by default for the last 90 days of event history. For long-term storage, create a trail that delivers logs to an S3 bucket.
AWS Config – Evaluates your resources against desired configurations. Can automatically remediate non-compliant resources.
AWS Shield – Managed DDoS protection. Standard is free and automatic. Advanced ($3,000/month) provides enhanced detection and response.
AWS WAF – Web application firewall that filters HTTP requests based on rules (IP addresses, HTTP headers, SQL injection, cross-site scripting).
AWS Security Hub – Centralized view of security alerts from multiple AWS services and third-party tools.
Amazon GuardDuty – Intelligent threat detection using machine learning. Analyzes CloudTrail logs, VPC Flow Logs, and DNS logs.
Amazon Inspector – Automated vulnerability assessment for EC2 instances and container images.
Comparison to On-Premises
In an on-premises data center, you are responsible for everything — from the physical building to the application code. In the cloud, you share responsibility. This reduces your operational burden but requires you to understand where your responsibility begins and ends. The exam tests this boundary with specific service examples. For instance, with Amazon RDS, AWS is responsible for the database engine patching, but you are responsible for managing database user permissions and encryption at rest.
When to Use the Security Pillar
You should apply the Security Pillar to every workload. It is not a one-time activity but a continuous process. Use the Well-Architected Tool in the AWS Management Console to review your workloads against the pillar. The exam expects you to know that the Security Pillar is one of the six pillars and that it focuses on protecting data, systems, and assets.
Identify Your Workload
Begin by selecting a workload to review. This could be a simple web application or a complex microservices architecture. In the AWS Well-Architected Tool, you define the workload by giving it a name, description, and selecting the AWS account(s) it runs in. The tool then presents a series of questions based on the Security Pillar best practices. You answer each question by selecting 'Yes,' 'No,' or 'Not Applicable.' For each 'No' answer, the tool provides improvement plans with specific AWS services and configurations to remediate the issue.
Review Identity and Access Management
The first focus area is identity and access management. The exam expects you to know that you should use IAM roles instead of long-term access keys, enable MFA for all users, and apply the principle of least privilege. A common mistake is to use the root user for daily tasks. The root user should only be used for a few account-level actions like changing support plans or closing the account. For all other actions, create IAM users or roles. AWS Organizations allows you to centrally manage multiple accounts and apply SCPs to restrict what member accounts can do.
Enable Detective Controls
Detective controls are about monitoring and logging. Enable AWS CloudTrail to record all API calls. By default, CloudTrail is enabled but only retains event history for 90 days. To store logs longer, create a trail that delivers logs to an S3 bucket. Use Amazon CloudWatch Logs to monitor application logs. Set up CloudWatch alarms for unusual activity, such as a spike in failed login attempts. Amazon GuardDuty continuously analyzes CloudTrail logs, VPC Flow Logs, and DNS logs for malicious activity. AWS Config tracks resource configuration changes and can trigger automatic remediation.
Implement Infrastructure Protection
Protect Data at Rest and in Transit
Data protection is a key exam topic. For data at rest, use encryption. Amazon S3 offers server-side encryption (SSE-S3, SSE-KMS, SSE-C). Amazon EBS volumes can be encrypted using KMS. Amazon RDS supports encryption at rest using KMS. For data in transit, enforce TLS/SSL using AWS Certificate Manager (ACM) to provision certificates. Use Amazon CloudFront to distribute content over HTTPS. The exam may ask which service is used to manage encryption keys — the answer is AWS KMS. Also, know that you can use your own keys (Customer Master Keys, CMKs) in KMS.
Prepare for Incident Response
Incident response is about having a plan. Use AWS CloudFormation to create a 'golden AMI' that can be deployed quickly for forensic analysis. Use AWS Config rules to automatically detect non-compliant resources and trigger Lambda functions for remediation. For example, if an S3 bucket becomes public, a Config rule can detect it and a Lambda function can change the bucket policy to private. The exam may ask how to automate security responses — the answer is AWS Lambda in conjunction with AWS Config or CloudWatch Events.
Scenario 1: E-commerce Platform with PCI DSS Compliance
A company running an e-commerce platform on AWS must comply with PCI DSS (Payment Card Industry Data Security Standard). They use AWS Artifact to access compliance reports and use AWS Config to continuously monitor their resources against a set of PCI DSS rules. They encrypt all credit card data at rest using AWS KMS and in transit using TLS. Their security team uses AWS CloudTrail to audit all API calls and Amazon GuardDuty to detect suspicious activity. A common mistake is to assume that AWS is fully responsible for PCI DSS compliance. In reality, the customer must implement the required controls for their applications and data. The company also uses AWS WAF to block SQL injection attempts and AWS Shield Advanced for DDoS protection. Cost consideration: AWS Shield Advanced costs $3,000 per month, but it includes enhanced DDoS mitigation and 24/7 access to the DDoS Response Team.
Scenario 2: Startup with Limited Security Team
A startup with a small team uses AWS to host a mobile app backend. They have no dedicated security engineer. They rely on AWS managed services like Amazon RDS and Amazon S3 to reduce their security burden. They enable S3 block public access at the account level to prevent accidental data leaks. They use IAM roles for EC2 instances instead of storing access keys. They set up AWS Config rules to detect when security groups are too permissive (e.g., SSH from 0.0.0.0/0). They use AWS Trusted Advisor to get security recommendations. The biggest risk is misconfigured S3 buckets. In one real incident, a startup left an S3 bucket public and exposed customer data. The exam emphasizes that S3 bucket policies and block public access settings are the customer's responsibility.
Scenario 3: Enterprise with Multiple Accounts
A large enterprise uses AWS Organizations to manage hundreds of accounts. They use Service Control Policies (SCPs) to restrict actions across all accounts, such as preventing deletion of CloudTrail logs or disabling encryption. They centralize CloudTrail logs into a single S3 bucket in a security account. They use AWS Security Hub to aggregate findings from GuardDuty, Inspector, and third-party tools. They have an incident response playbook that uses AWS Step Functions to automate containment steps, such as isolating an EC2 instance by changing its security group. A misconfiguration here could be an overly permissive SCP that inadvertently blocks legitimate actions. The exam may ask about SCPs and how they differ from IAM policies — SCPs set permission boundaries but do not grant permissions.
Exactly What CLF-C02 Tests
Domain 2: Security and Compliance (25% of exam). The Security Pillar is tested under objective 2.1: 'Define the AWS shared responsibility model.' You must be able to differentiate between security OF the cloud (AWS responsibility) and security IN the cloud (customer responsibility). The exam also tests the six design principles of the Security Pillar and how they map to AWS services. Expect 3-5 questions directly on the shared responsibility model, and several more on specific security services.
Common Wrong Answers and Why Candidates Choose Them
'AWS is responsible for everything once you move to the cloud.' – This is the #1 trap. Candidates think cloud means 'no security worries.' Reality: customers are always responsible for their data, IAM, and network controls.
'The root user should be used for daily administration.' – Many candidates think root is like an admin account. Reality: root user has unlimited access and should only be used for specific account management tasks. Use IAM users/roles instead.
'Security groups are stateless.' – Candidates confuse security groups with network ACLs. Security groups are stateful; network ACLs are stateless.
'AWS Config is used for logging API calls.' – Candidates mix up AWS Config (configuration tracking) with CloudTrail (API logging). CloudTrail logs API calls; Config tracks resource configurations.
Specific Terms That Appear Verbatim on the Exam
Shared Responsibility Model – Know the exact line for each service type (IaaS, PaaS, SaaS).
Principle of Least Privilege – Give only the permissions needed to perform a task.
Defense in Depth – Use multiple layers of security controls.
AWS Organizations – SCPs are permission guardrails.
AWS KMS – Managed encryption keys.
AWS CloudTrail – API logging.
AWS Config – Configuration compliance.
AWS WAF – Web application firewall.
AWS Shield – DDoS protection.
Amazon GuardDuty – Threat detection.
Amazon Inspector – Vulnerability assessment.
Tricky Distinctions
Security Group vs. Network ACL: Security groups are stateful, support allow rules only, and are attached to ENIs. Network ACLs are stateless, support allow and deny rules, and are attached to subnets.
AWS Config vs. AWS CloudTrail: Config tracks configuration changes; CloudTrail tracks API calls. Both can trigger alerts, but they serve different purposes.
AWS KMS vs. AWS CloudHSM: KMS is a managed service for encryption keys; CloudHSM provides dedicated hardware security modules (HSMs) for customers who need FIPS 140-2 Level 3 compliance.
Decision Rule for Multi-Choice Questions
When asked 'Who is responsible for X?' use the shared responsibility model. If the question involves physical infrastructure, hardware, or the hypervisor, the answer is AWS. If it involves customer data, IAM, OS patches (for EC2), or network configurations, the answer is the customer. For managed services like RDS, AWS handles the OS and engine, but the customer manages data access.
The Security Pillar has six design principles: strong identity foundation, enable traceability, apply security at all layers, automate security best practices, protect data in transit and at rest, and prepare for security events.
The shared responsibility model is the most tested concept: AWS is responsible for security OF the cloud; customers are responsible for security IN the cloud.
IAM is used for identity and access management; enable MFA and use least privilege.
CloudTrail logs API calls; AWS Config tracks configuration changes.
Encrypt data at rest with AWS KMS and data in transit with TLS/SSL using ACM.
Use security groups (stateful) for instance-level firewalls and network ACLs (stateless) for subnet-level firewalls.
AWS Shield Standard is free and automatic; Shield Advanced costs $3,000/month.
AWS WAF protects web applications from common exploits like SQL injection and XSS.
Amazon GuardDuty uses machine learning for threat detection.
AWS Organizations with SCPs set permission guardrails across accounts.
These come up on the exam all the time. Here's how to tell them apart.
Security Group
Stateful
Supports allow rules only
Attached to ENI (instance level)
Evaluated as a whole (all rules evaluated before decision)
Default: allows all outbound traffic
Network ACL
Stateless
Supports allow and deny rules
Attached to subnet (subnet level)
Evaluated in numeric order (first match wins)
Default: allows all inbound and outbound traffic
Mistake
The shared responsibility model means AWS handles all security.
Correct
AWS is responsible for security OF the cloud (physical infrastructure, hardware, software). Customers are responsible for security IN the cloud (data, IAM, network controls, OS patches).
Mistake
You should use the root user for everyday tasks because it has full access.
Correct
The root user has unrestricted access and should only be used for account-level tasks (e.g., changing support plan, closing account). Use IAM users/roles for daily administration.
Mistake
Security groups are stateless and can deny traffic.
Correct
Security groups are stateful and only support allow rules. They cannot explicitly deny traffic. Network ACLs are stateless and support both allow and deny rules.
Mistake
AWS Config is used to log API calls for auditing.
Correct
AWS Config tracks resource configuration changes, not API calls. AWS CloudTrail is used for auditing API calls.
Mistake
If you use Amazon RDS, AWS is responsible for all security, including data access.
Correct
AWS manages the database engine and OS, but you are responsible for managing database user permissions, encryption keys, and data access policies.
Security groups act as a virtual firewall for an EC2 instance. They are stateful, meaning if you allow inbound traffic, the outbound response is automatically allowed regardless of outbound rules. They only support allow rules. Network ACLs act as a firewall for a subnet. They are stateless, meaning you must explicitly define rules for both inbound and outbound traffic. They support both allow and deny rules and are evaluated in numeric order. This distinction is frequently tested on the exam.
Under the shared responsibility model, the customer is responsible for patching the guest OS on an EC2 instance. AWS is responsible for the hypervisor and physical hardware. If you use a managed service like Amazon RDS, AWS handles patching of the database engine and OS. This is a common exam question: for IaaS (EC2), you patch; for PaaS (RDS), AWS patches.
AWS Artifact is a self-service portal for on-demand access to AWS compliance reports and agreements. You can download SOC reports, PCI DSS reports, and ISO certifications. It helps you meet regulatory requirements by providing evidence of AWS compliance. It does not provide security monitoring or alerting — that is the role of services like GuardDuty and Config.
You can use AWS Config rules to detect non-compliant resources and trigger an AWS Lambda function to remediate the issue. For example, you can create a Config rule that checks if S3 buckets are public. If a bucket becomes public, Lambda can change the bucket policy to private. This aligns with the Security Pillar design principle of 'automate security best practices.'
AWS KMS is a managed service that allows you to create and control encryption keys. It is integrated with many AWS services and supports automatic key rotation. AWS CloudHSM provides dedicated hardware security modules (HSMs) that are FIPS 140-2 Level 3 validated. CloudHSM gives you full control over the HSM and is used for regulatory compliance where dedicated hardware is required. KMS is easier to use and more cost-effective for most workloads.
An SCP is a policy that specifies the maximum permissions for member accounts in an AWS Organization. SCPs do not grant permissions; they set guardrails. For example, you can create an SCP that prevents any account from disabling CloudTrail or deleting encryption keys. SCPs are applied to all users and roles in the account, including the root user. They are a key tool for implementing the Security Pillar's 'strong identity foundation' at scale.
AWS Shield Standard is automatically enabled for all AWS customers at no extra cost. It protects against common, most frequently occurring DDoS attacks, such as SYN floods and UDP floods, at the network and transport layers (Layer 3 and 4). For higher levels of protection, including application layer (Layer 7) attacks, you can purchase AWS Shield Advanced, which costs $3,000 per month and includes 24/7 access to the DDoS Response Team.
You've just covered Security Pillar — Well-Architected — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?