The Shared Responsibility Model — Who Owns What
The shared responsibility model defines the boundary between what the cloud provider secures and what the customer must secure. This boundary shifts depending on the service model. The most common exam scenario: a company stores sensitive data in an S3 bucket that is publicly accessible. Who is responsible for the misconfiguration? The customer — configuring access controls is always the customer's responsibility.
| Security Responsibility | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physical infrastructure, datacentre | Provider | Provider | Provider |
| Hypervisor / virtualisation layer | Provider | Provider | Provider |
| Operating system (patching, hardening) | Customer | Provider | Provider |
| Runtime / middleware | Customer | Provider | Provider |
| Application code and configuration | Customer | Customer | Provider |
| Data classification and protection | Customer | Customer | Customer |
| Identity and access management | Customer | Customer | Shared |
| Network controls (security groups, firewall) | Customer | Shared | Provider |
| Endpoint security (devices accessing cloud) | Customer | Customer | Customer |
Data is always the customer's responsibility — regardless of service model. Even in SaaS, you are responsible for what data you put in the application, who has access to it, and how it's classified. The provider secures the platform; you secure your data on it.
IaaS = most customer responsibility. You own the OS up. The provider owns the physical layer and hypervisor. On A+ and Security+, IaaS scenarios where a VM is compromised due to an unpatched OS — that's the customer's fault, not the provider's.
Cloud Security Tools — What They Do and When to Use Them
Exam trigger: A company wants to see what cloud services employees are using without approval → CASB.
Exam trigger: A company wants to find security misconfigurations across their AWS/Azure environment → CSPM.
Exam trigger: A company needs to protect containers and VMs running in their cloud environment at runtime → CWPP.
Exam trigger: A company with remote workers wants to replace their VPN and perimeter firewall with a cloud-native security model → SASE.
Top Cloud Misconfigurations — The Most Common Attack Vectors
Cloud breaches are disproportionately caused by misconfigurations rather than sophisticated attacks. Security+ scenarios frequently describe a cloud environment and ask you to identify the security flaw. These are the most commonly tested misconfigurations.
| Misconfiguration | Risk | Correct Control |
|---|---|---|
| Publicly accessible cloud storage (S3 bucket, Azure blob with public read) | Data exposure — anyone can read the bucket contents without authentication | Block public access at the account level. Use bucket policies and ACLs to restrict to specific principals only. |
| Overly permissive IAM roles (wildcard * permissions) | Privilege escalation — a compromised service can access any resource | Principle of least privilege — grant only the specific permissions required. Audit IAM roles regularly with tools like AWS Access Analyzer. |
| Security group / firewall rule 0.0.0.0/0 on management ports (SSH/RDP) | Brute force, credential stuffing, exploitation of unpatched services from any internet source | Restrict SSH/RDP to specific IP ranges or VPN. Use a bastion host or jump server for management access. |
| Root account / global admin used for daily operations | Compromise of root gives unrestricted access to everything — no recovery path | Disable root access keys. Enable MFA on root. Use IAM users/roles with minimum permissions for all routine tasks. |
| Unencrypted storage volumes and databases | Data exposure if volume snapshots are shared or storage media is repurposed | Enable encryption at rest using cloud KMS (Key Management Service). Enforce encryption on all new volumes via policy. |
| Disabled logging and monitoring (CloudTrail, Azure Monitor off) | No audit trail — attackers can operate undetected and incidents cannot be investigated | Enable logging for all services. Forward logs to a SIEM. Set alerts for privileged actions, failed auth, and resource creation. |
| Secrets and credentials in source code or environment variables | Credential theft from code repositories — GitHub scans routinely find AWS keys | Use cloud secrets managers (AWS Secrets Manager, Azure Key Vault). Never commit credentials to version control. |
Serverless Security
Serverless functions (AWS Lambda, Azure Functions, Google Cloud Functions) run code without managing servers. The cloud provider handles the OS and runtime — but you still own the function's code, its permissions, and the data it processes. The attack surface shifts from infrastructure to function configuration and code vulnerabilities.
Each function should have its own IAM role with minimum permissions. Giving all functions the same broad role means a vulnerable function can access resources it never needs.
Injection attacks still apply. If a serverless function passes user input to a database query without sanitising it, it's vulnerable to SQL injection the same as any other application.
Third-party dependencies are a supply chain risk. Serverless functions rely on libraries — a compromised library (like the Log4j vulnerability) affects every function that includes it.
Cold starts can mask attacks. Functions that are infrequently called may not have logging configured consistently — ensure every invocation is logged.
Container Security
Containers (Docker, Kubernetes) package applications and their dependencies into isolated units. Security+ SY0-701 tests containers primarily in the context of image security, container escape, and Kubernetes misconfigurations.
Image vulnerabilities — containers are built from images. A vulnerable base image propagates the vulnerability to every container built from it. Scan images before deployment using tools like Trivy or Snyk.
Container escape — a vulnerability that allows malicious code in a container to break out and access the host OS or other containers. Running containers as root dramatically increases escape risk. Best practice: run containers as non-root users.
Kubernetes RBAC — Kubernetes has its own role-based access control system separate from cloud IAM. Misconfigured Kubernetes RBAC is a common attack vector — the default service account often has more permissions than needed.
Immutable infrastructure — containers should be treated as disposable and immutable. Never patch a running container; rebuild the image with the fix and redeploy. This prevents configuration drift and ensures a known-good state.
Cloud Security Architecture — Key Concepts
Infrastructure as Code (IaC) Security
IaC tools (Terraform, CloudFormation) define infrastructure in configuration files. Misconfigurations in IaC templates deploy insecure infrastructure at scale. Scanning IaC templates before deployment (using tools like Checkov or tfsec) catches misconfigurations before they reach production — this is "shift left" security applied to infrastructure.
Cloud-Native Firewall and Security Groups
Cloud providers offer virtual firewalls as security groups (AWS) or network security groups (Azure). Unlike traditional firewalls, these are stateful and attached to individual resources rather than network segments. Each resource should have its own security group with minimum required rules — the principle of least privilege applied to network access.
Secrets Management
Cloud Key Management Services (KMS) store and manage cryptographic keys and secrets. Applications retrieve secrets at runtime via API rather than storing them in config files or environment variables. Rotation policies ensure secrets are automatically cycled. On the exam: AWS Secrets Manager, Azure Key Vault, and HashiCorp Vault are the tools associated with secrets management in cloud environments.
"Shadow IT" → CASB. Any scenario describing employees using unapproved cloud apps, or a company wanting visibility into what SaaS services are in use, points to a CASB solution.
"Misconfiguration detected" → CSPM. Continuous monitoring and detection of cloud configuration drift or policy violations is the CSPM use case. If the scenario involves a tool finding security gaps across cloud accounts automatically, that's CSPM.
Data breaches from public S3 buckets → customer's responsibility. Provider secures the platform; customer secures configuration and data. Exposed cloud storage is always the customer's misconfiguration, regardless of how the question is framed.
Exam Scenarios
Studying for Security+ SY0-701?
Cloud security is 18% of Domain 3. See the full Security+ study guide for all 5 domains.