Cloud Security — Shared Responsibility, Misconfigurations, and Cloud Threats

What Is Cloud Security and Why Does It Matter?

Cloud security encompasses the policies, technologies, and controls that protect data, applications, and infrastructure in cloud environments, as defined by the Cloud Security Alliance (CSA) Cloud Controls Matrix and NIST SP 800-144 (Guidelines on Security and Privacy in Public Cloud Computing).

Cloud security is the practice of protecting data, applications, and infrastructure hosted in cloud environments, and it has become the single most in-demand cybersecurity skill set because nearly every organisation now runs workloads in the cloud. Misconfigurations, not sophisticated exploits, are the leading cause of cloud security breaches — and that means entry-level professionals who understand cloud security fundamentals can make an immediate impact.

If you are studying for CompTIA Security+ SY0-701 or CEH v13, cloud security appears across multiple exam domains. For entry-level SOC analysts, cloud-related alerts — public S3 buckets, overprivileged IAM roles, exposed APIs — are now a daily reality in most security operations centres.

Cloud security was the topic that made me realise how much the cybersecurity landscape has changed even in the last few years. When I started studying, I imagined security meant protecting servers in a room somewhere. Then I learned that most organisations no longer own their servers — they rent compute power, storage, and services from AWS, Azure, or Google Cloud. The attack surface has fundamentally shifted, and so has what defenders need to know. Understanding the shared responsibility model was the moment cloud security clicked for me.

Certification objective: CompTIA Security+ SY0-701 Domain 3 covers cloud security concepts including the shared responsibility model, cloud deployment models, and cloud-specific threats. CEH v13 Module 19 covers cloud computing threats, cloud platform vulnerabilities, and cloud security tools.

What Do Real-World Cloud Security Attacks Look Like?

According to the CSA Top Threats to Cloud Computing (2024), misconfiguration and inadequate change control remain the leading cause of cloud security incidents, responsible for more breaches than any other single attack vector.

Cloud security failures make headlines regularly because they often expose millions of records in a single incident.

Incident	Cloud platform	Impact	Root cause
Capital One breach (2019)	AWS	106 million customer records exposed, including SSNs and bank account numbers	Misconfigured WAF allowed SSRF attack to access EC2 instance metadata and IAM credentials
Microsoft Power Apps (2021)	Azure	38 million records from 47 organisations exposed, including COVID contact tracing data	Default table permissions set to public; organisations did not change them
Twitch source code leak (2021)	AWS	Entire source code repository, creator payment data, and internal tools leaked (125 GB)	Server misconfiguration allowed unauthorised access to internal Git repositories
Elasticsearch exposures (ongoing)	Various	Billions of records exposed across thousands of instances worldwide	Elasticsearch instances deployed without authentication — default configuration has no password
Toyota (2023)	Cloud-based	2.15 million Japanese customers’ vehicle data exposed for 10 years	Cloud environment misconfigured as public instead of private; no one noticed for a decade
Australian Government myGov data concerns (ongoing)	Various	Ongoing concerns about data handling and cloud security in government services	Highlights the challenge of securing cloud-hosted government services at scale

The Capital One breach is particularly instructive. The attacker exploited a misconfigured Web Application Firewall to perform a Server-Side Request Forgery (SSRF) attack, which accessed the EC2 instance metadata service and retrieved temporary IAM credentials. Those credentials provided access to S3 buckets containing customer data. The entire attack chain started with a single misconfiguration.

What Are the Key Concepts Behind Cloud Security?

The AWS Shared Responsibility Model — mirrored by Azure and GCP — establishes that the cloud provider secures the infrastructure (“security of the cloud”) while the customer secures their configurations, data, and access controls (“security in the cloud”), as further detailed in NIST SP 800-144.

Think of cloud computing like renting an apartment versus owning a house. When you own a house (on-premises), you are responsible for everything — the roof, the plumbing, the locks, the alarm system. When you rent an apartment (cloud), the building management handles some things (the structure, common areas, utilities) while you handle others (your belongings, your door lock, who you give keys to). The shared responsibility model defines exactly where the landlord’s responsibility ends and yours begins.

The critical insight is this: the cloud provider secures the cloud infrastructure itself, but you secure what you put in it. Most cloud breaches happen not because AWS, Azure, or GCP were hacked, but because customers misconfigured their own resources.

Cloud Service Models

Model	What you manage	What the provider manages	Example
IaaS (Infrastructure as a Service)	OS, middleware, runtime, applications, data	Physical servers, networking, virtualisation, storage	AWS EC2, Azure VMs, Google Compute Engine
PaaS (Platform as a Service)	Applications and data	OS, middleware, runtime, plus all IaaS responsibilities	AWS Elastic Beanstalk, Azure App Service, Google App Engine
SaaS (Software as a Service)	Data and user access configuration	Everything else — the entire application stack	Microsoft 365, Salesforce, Google Workspace

As you move from IaaS to SaaS, you manage less and the provider manages more. But at every level, you are always responsible for your data and your access controls.

Cloud Deployment Types

Type	Description	Use case
Public cloud	Shared infrastructure operated by a cloud provider; accessed over the internet	Most common; cost-effective for general workloads
Private cloud	Dedicated infrastructure for a single organisation; may be on-premises or provider-hosted	Regulated industries, sensitive data, compliance requirements
Hybrid cloud	Combination of public and private cloud with data and applications moving between them	Organisations migrating gradually or with mixed compliance needs
Multi-cloud	Using multiple public cloud providers simultaneously	Avoiding vendor lock-in, leveraging best-of-breed services
Community cloud	Shared infrastructure for organisations with common concerns (e.g., government, healthcare)	Sector-specific compliance and data sovereignty requirements

The Shared Responsibility Model

📊 Visual Explanation

The Shared Responsibility Model

Who secures what — the most important concept in cloud security

Data Classification & Encryption

ALWAYS your responsibility — classify, encrypt, and control access to your data

Identity & Access Management

YOUR responsibility — who can access what, with what permissions

Application Security

Your responsibility in IaaS/PaaS — secure your code, dependencies, and configurations

Network Controls

Shared — provider gives tools (security groups, NACLs), you must configure them correctly

Operating System & Middleware

Your responsibility in IaaS — patching, hardening, monitoring

Virtualisation & Physical Infrastructure

PROVIDER responsibility — hypervisor, physical servers, data centre security

Physical Data Centre Security

PROVIDER responsibility — buildings, power, cooling, physical access controls

Idle

The layers at the top (orange, pink, purple) are always your responsibility regardless of service model. The layers at the bottom (cyan, green) are always the provider’s responsibility. The middle layers shift depending on whether you use IaaS, PaaS, or SaaS.

Step-by-Step: Understanding Cloud Security Threats

Threat 1: Misconfiguration

Misconfiguration is the number one cloud security threat, responsible for more breaches than any other cause. Cloud platforms offer thousands of configuration options, and a single incorrect setting can expose data to the entire internet.

Common misconfigurations:

Public S3 buckets. AWS S3 storage buckets configured with public read access, exposing their contents to anyone with the URL. This has caused dozens of major breaches.
Overly permissive security groups. Firewall rules that allow traffic from 0.0.0.0/0 (the entire internet) to sensitive ports like SSH (22), RDP (3389), or database ports.
Unrestricted IAM policies. Granting users or services more permissions than they need, violating the principle of least privilege. An AdministratorAccess policy on a Lambda function is a common mistake.
Unencrypted storage. Databases and storage volumes without encryption at rest, meaning a compromised backup or snapshot exposes plaintext data.
Logging disabled. Not enabling AWS CloudTrail, Azure Activity Log, or GCP Cloud Audit Logs, leaving no record of who did what.

Threat 2: Insecure APIs

Cloud services are managed through APIs. Every action — creating a server, modifying a database, changing permissions — is an API call. If these APIs are misconfigured, exposed, or lack proper authentication, attackers can control your entire cloud environment.

Unauthenticated API endpoints. Management APIs exposed without requiring authentication tokens or API keys.
Excessive API permissions. API keys with more permissions than the application needs.
API keys in source code. Developers accidentally committing cloud credentials to public Git repositories — automated scanners find these within minutes.

Threat 3: Identity and Access Management Failures

Cloud IAM is complex because it involves users, groups, roles, policies, service accounts, and cross-account access. Mistakes in IAM are often the root cause or a key enabler of breaches.

No MFA on root/admin accounts. The single most critical IAM control, and one of the most frequently missed.
Long-lived access keys. Static credentials that never expire and are never rotated, sitting in configuration files or environment variables.
Overprivileged service accounts. Applications running with administrator-level permissions when they only need read access to a single database.
Cross-account trust misconfigurations. Allowing external AWS accounts to assume roles in your environment without proper conditions.

Threat 4: Data Breaches Through Cloud Storage

Cloud storage services make it easy to store vast amounts of data, but they also make it easy to accidentally expose it.

S3 bucket enumeration. Attackers discover bucket names through DNS, certificate transparency logs, or brute force, then check if they are publicly accessible.
Snapshot exposure. EBS snapshots or database backups shared publicly or with overly broad permissions.
Insufficient encryption. Data encrypted in transit (TLS) but not at rest, or encrypted with keys the customer does not control.

Threat 5: Container and Serverless Vulnerabilities

Modern cloud workloads increasingly use containers (Docker, Kubernetes) and serverless functions (AWS Lambda, Azure Functions). These introduce new security challenges.

Vulnerable base images. Containers built from images with known CVEs in the operating system or libraries.
Container escape. Exploiting vulnerabilities to break out of a container and access the host system or other containers.
Insecure Kubernetes configurations. Dashboard exposed to the internet, overly permissive pod security policies, or secrets stored in plaintext.
Serverless function injection. Exploiting input validation flaws in Lambda functions to access other AWS services through the function’s IAM role.

How Does Cloud Security Fit Into a Security Architecture?

NIST SP 800-144 recommends that organisations evaluate cloud security architectures by comparing the control differences between on-premises and cloud environments, with particular attention to identity management replacing the network perimeter as the primary security boundary.

On-Premises vs Cloud Security

📊 Visual Explanation

On-Premises vs Cloud Security

On-Premises Security

Full control — You own and manage everything — hardware, network, OS, applications
Physical perimeter — Firewalls, DMZ, physical access controls define the boundary
Capital expenditure — Buy hardware upfront; long procurement cycles
Manual scaling — Add capacity by buying and racking new servers
Known attack surface — Fixed infrastructure with predictable boundaries

Cloud Security

Shared responsibility — Provider secures infrastructure; you secure your configurations and data
Identity perimeter — Identity and access management replaces the network perimeter as primary control
Operational expenditure — Pay as you go; rapid provisioning but also rapid cost escalation
Auto-scaling — Resources scale automatically — but so can misconfigurations and costs
Dynamic attack surface — Infrastructure changes constantly; resources created and destroyed in minutes

Verdict: Cloud security is not harder or easier — it is fundamentally different. The perimeter shifts from the network to identity, and misconfigurations replace unpatched servers as the primary risk.

Use case

Most organisations operate in hybrid environments. Security professionals need to understand both models and how they interact.

Cloud Security Tools and Services

Cloud providers offer native security tools that entry-level professionals should be familiar with:

Category	AWS	Azure	GCP
IAM	AWS IAM, IAM Access Analyzer	Azure Active Directory (Entra ID), PIM	Google Cloud IAM, Policy Intelligence
Logging	CloudTrail, CloudWatch	Activity Log, Monitor, Sentinel	Cloud Audit Logs, Cloud Logging
Network security	Security Groups, NACLs, WAF	NSGs, Azure Firewall, WAF	VPC firewall rules, Cloud Armor
Storage security	S3 bucket policies, Macie	Storage firewalls, Purview	IAM conditions, DLP API
Compliance	Security Hub, Config	Defender for Cloud, Policy	Security Command Center
Secret management	Secrets Manager, KMS	Key Vault	Secret Manager, Cloud KMS

CSPM (Cloud Security Posture Management)

CSPM tools continuously monitor cloud environments for misconfigurations and compliance violations. They are the cloud equivalent of vulnerability scanners for infrastructure configuration.

Popular CSPM tools include:

AWS Security Hub and AWS Config (native)
Microsoft Defender for Cloud (native to Azure, also supports AWS/GCP)
Prisma Cloud (Palo Alto Networks — multi-cloud)
Wiz — Agentless cloud security platform
Prowler — Open-source AWS/Azure/GCP security assessment tool

What Does Cloud Security Look Like in Practice?

The CIS Benchmarks for AWS, Azure, and GCP provide over 200 specific configuration checks that security professionals use to assess and harden cloud environments — many of which can be automated using native cloud CLI tools and open-source scanners like Prowler.

These commands demonstrate real security checks performed by cloud security professionals. Practise in a personal AWS Free Tier or Azure free account.

AWS S3 Bucket Security Checks

# List all S3 buckets in the account
aws s3api list-buckets --query "Buckets[].Name" --output table

# Check if a bucket has public access
aws s3api get-public-access-block --bucket my-bucket-name

# Check bucket policy for public access
aws s3api get-bucket-policy --bucket my-bucket-name --output json

# Check bucket ACL for public permissions
aws s3api get-bucket-acl --bucket my-bucket-name

# Enable server-side encryption on a bucket
aws s3api put-bucket-encryption --bucket my-bucket-name \
  --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}'

# Block all public access at the account level
aws s3control put-public-access-block --account-id 123456789012 \
  --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

AWS IAM Security Checks

# List all IAM users
aws iam list-users --query "Users[].UserName" --output table

# Check if MFA is enabled on the root account
aws iam get-account-summary --query "SummaryMap.AccountMFAEnabled"

# Find users without MFA
aws iam generate-credential-report
aws iam get-credential-report --query "Content" --output text | base64 -d | grep -i "false"

# List overly permissive policies (AdministratorAccess)
aws iam list-entities-for-policy \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess \
  --query "PolicyUsers[].UserName"

# Check for access keys older than 90 days
aws iam list-access-keys --user-name myuser \
  --query "AccessKeyMetadata[?CreateDate&lt;='2025-12-01'].AccessKeyId"

Cloud Security Logging Verification

# Check if CloudTrail is enabled
aws cloudtrail describe-trails --query "trailList[].{Name:Name,IsMultiRegion:IsMultiRegionTrail,IsLogging:true}"

# Search CloudTrail for suspicious IAM activity
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=ConsoleLogin \
  --max-results 10

# Check for security group rules allowing 0.0.0.0/0 on SSH
aws ec2 describe-security-groups \
  --filters Name=ip-permission.from-port,Values=22 Name=ip-permission.cidr,Values=0.0.0.0/0 \
  --query "SecurityGroups[].{ID:GroupId,Name:GroupName}"

Prowler — Open-Source Cloud Security Assessment

# Install Prowler
pip install prowler

# Run a full AWS security assessment
prowler aws

# Run specific checks (CIS Benchmark)
prowler aws --compliance cis_2.0_aws

# Check only IAM-related findings
prowler aws --service iam

# Output results as CSV for analysis
prowler aws -M csv -o /tmp/prowler-results/

Legal and ethical warning: Only run security assessments against cloud accounts you own or have explicit written authorisation to test. Scanning or probing cloud resources belonging to other organisations is illegal under the Computer Fraud and Abuse Act (US), the Criminal Code Act 1995 (Australia), and similar legislation. AWS, Azure, and GCP all provide free-tier accounts for learning and testing.

What Are the Limitations of Cloud Security Controls?

According to Gartner, through 2025, 99% of cloud security failures will be the customer’s fault — primarily due to misconfiguration, overprivileged identities, and insufficient monitoring rather than provider infrastructure compromises.

Security control	Benefit	Limitation / failure mode
Shared responsibility model	Clear division of security duties between provider and customer	Customers misunderstand what they are responsible for; assume the provider handles everything
IAM policies	Granular access control for every resource and action	Complexity leads to overly permissive policies; “just make it work” overrides least privilege
Encryption at rest	Protects data if storage is compromised	Useless if the attacker has the IAM permissions to decrypt; key management is the real challenge
CSPM tools	Continuous monitoring for misconfigurations	Alert fatigue from thousands of findings; prioritisation requires cloud security expertise
VPC and security groups	Network-level isolation and access control	Misconfigured rules (0.0.0.0/0) negate the entire control; complexity grows with scale
CloudTrail/audit logging	Complete record of all API activity for investigation	Logs are only useful if someone is monitoring them; storage costs grow with scale
Multi-factor authentication	Blocks credential theft attacks against cloud consoles	Not always enforced on service accounts, API keys, or programmatic access
Container image scanning	Identifies known CVEs in container images before deployment	Zero-day vulnerabilities not in databases; scanning does not catch logic flaws or misconfigurations

What Interview Questions Should You Expect About Cloud Security?

Cloud security is among the most frequently tested topics in modern cybersecurity interviews, with the shared responsibility model, IAM, and misconfiguration risks appearing in both CompTIA Security+ SY0-701 Domain 3 and CCSK (Certificate of Cloud Security Knowledge) exam objectives.

Cloud security questions are among the most common in modern cybersecurity interviews. Interviewers want to see that you understand the shared responsibility model and can think about cloud-specific risks.

Q1: Explain the shared responsibility model.

Strong answer: “The shared responsibility model defines who secures what in a cloud environment. The cloud provider is responsible for security ‘of’ the cloud — the physical infrastructure, hypervisors, and global network. The customer is responsible for security ‘in’ the cloud — their data, IAM configurations, application code, and network settings. The exact boundary shifts depending on whether you use IaaS, PaaS, or SaaS. In IaaS, you manage the most. In SaaS, the provider manages nearly everything, but you are still responsible for your data and access controls.”

Q2: What is the most common cause of cloud security breaches?

Strong answer: “Misconfiguration. Cloud providers offer thousands of configuration options, and a single incorrect setting — a public S3 bucket, an overly permissive security group, or an unrestricted IAM policy — can expose data to the internet. The Capital One breach in 2019 started with a misconfigured WAF that allowed an SSRF attack. This is why CSPM tools and cloud security auditing are so important — they catch misconfigurations before attackers do.”

Q3: How would you respond to an alert about a publicly accessible S3 bucket?

Strong answer: “First, I would verify the alert by checking the bucket’s public access block settings, bucket policy, and ACL. Then I would determine what data the bucket contains and its sensitivity. If the bucket contains sensitive data and is confirmed public, I would immediately block public access and document the change. I would then investigate how long the bucket was public, whether any unauthorised access occurred by checking S3 access logs, and identify who misconfigured it and why. Finally, I would recommend preventive controls like account-level public access blocks and CSPM monitoring.”

Q4: What is the difference between IaaS, PaaS, and SaaS from a security perspective?

Strong answer: “The difference is how much you manage versus how much the provider manages. With IaaS, you manage the OS, middleware, applications, and data — you are responsible for patching, hardening, and monitoring the most. With PaaS, the provider manages the OS and runtime, so you focus on your application code and data. With SaaS, the provider manages almost everything, and you are primarily responsible for user access controls and data classification. At every level, you always own your data security and identity management.”

Q5: Why is identity the new perimeter in cloud security?

Strong answer: “In on-premises environments, the network perimeter — firewalls and DMZs — was the primary security boundary. In the cloud, there is no physical perimeter. Resources are accessed over the internet via APIs. This means identity and access management — who can authenticate, what they are authorised to do, and how those permissions are enforced — becomes the primary security control. Compromising a cloud IAM credential can give an attacker access to everything, which is why MFA, least privilege, and access key rotation are critical.”

How Is Cloud Security Used in Real Security Operations?

The CSA Cloud Controls Matrix and AWS Well-Architected Framework (Security Pillar) both define operational security practices — including continuous monitoring, incident response, and compliance automation — that entry-level analysts encounter from their first day in a cloud-centric SOC.

Day-One SOC Cloud Scenarios

In a modern SOC, cloud security alerts are a significant portion of the daily workload:

Public storage alert. The CSPM tool flags an S3 bucket or Azure Blob container that was just made public. You verify the finding, assess data sensitivity, remediate by blocking public access, and investigate who made the change.
Unusual API activity. CloudTrail or Azure Activity Log shows API calls from an unfamiliar IP address or geographic location. You check whether the user account was compromised, verify MFA status, and correlate with other indicators.
Overprivileged IAM alert. IAM Access Analyzer identifies an IAM role that grants administrative access to a Lambda function. You work with the development team to scope the permissions down to only what the function needs.
Exposed credentials. GitHub secret scanning or AWS GuardDuty detects that an AWS access key was committed to a public repository. You immediately rotate the key, check CloudTrail for any activity using the compromised key, and assess impact.

Cloud Security Posture Management Workflow

A typical cloud security workflow for entry-level analysts:

Monitor CSPM dashboards for new findings — prioritise critical and high-severity misconfigurations.
Triage and validate findings — confirm the misconfiguration exists and assess its risk in context.
Remediate or escalate — fix simple misconfigurations directly (block public access, tighten security groups) or escalate complex ones to cloud engineering teams.
Document and track — record findings, remediation actions, and timelines for compliance reporting.
Trend analysis — identify recurring misconfiguration patterns that indicate a need for developer training or policy changes.

Australian Context: Cloud Security and the ASD ISM

In Australia, cloud security is governed by several frameworks and regulations:

ASD Information Security Manual (ISM) — The ISM provides cloud-specific security guidelines including cloud assessment and authorisation requirements. Australian government agencies must assess cloud services against the ISM before adoption.
Certified Cloud Services List (CCSL) — The ASD maintains a list of cloud services that have been assessed against the ISM for government use. AWS, Azure, and GCP all have CCSL-certified regions in Australia.
IRAP Assessment — The Information Security Registered Assessors Program (IRAP) provides independent assessments of cloud services against Australian government security requirements.
Privacy Act 1988 — Cloud services storing Australian personal information must comply with the Australian Privacy Principles, including data sovereignty considerations for where data is stored and processed.
SOCI Act 2018 — Critical infrastructure entities using cloud services must include cloud risks in their Critical Infrastructure Risk Management Programs.

For career changers in Australia, understanding the ISM cloud guidelines and IRAP assessment process is valuable for roles in government, defence, healthcare, and any organisation that handles sensitive data in the cloud.

Summary and Key Takeaways

Cloud security is the fastest-growing area in cybersecurity, and understanding its fundamentals is essential for every entry-level professional.

The shared responsibility model is the foundation. The cloud provider secures the infrastructure; you secure your configurations, data, and access controls. Most breaches happen because customers misconfigure their side.
Misconfiguration is the number one cloud threat. Public S3 buckets, overly permissive IAM policies, and open security groups have caused more breaches than sophisticated exploits.
Identity is the new perimeter. In the cloud, IAM replaces the network firewall as the primary security boundary. MFA, least privilege, and credential management are critical.
Cloud service models (IaaS, PaaS, SaaS) determine your security responsibilities. The more the provider manages, the less you manage — but you always own data security and access controls.
CSPM tools continuously monitor for misconfigurations and are the cloud equivalent of vulnerability scanners for infrastructure configuration.
Cloud-native threats include insecure APIs, container vulnerabilities, and serverless injection — new attack surfaces that require cloud-specific security knowledge.
Every major cloud provider offers native security tools (CloudTrail, Security Hub, Defender for Cloud) that security professionals must know how to use.

Individual results vary. Career timelines, salary outcomes, and job availability depend on your location, experience, market conditions, and effort. The information on this page is educational, not a guarantee of employment outcomes.

Security Concepts for the CIA triad and defence-in-depth principles that apply to cloud environments
Understanding the Threat Landscape for broader context on threat actors targeting cloud infrastructure
Career Paths to see where cloud security specialists fit in the industry
Home Lab Setup to practise cloud security using free-tier cloud accounts

Frequently Asked Questions

What is the shared responsibility model in cloud security?

The shared responsibility model defines who secures what in a cloud environment. The cloud provider secures the underlying infrastructure — physical servers, hypervisors, networking, and data centre security. The customer secures their data, access controls, configurations, and applications. The exact boundary shifts depending on whether you use IaaS, PaaS, or SaaS, but data security and identity management are always the customer's responsibility.

What is the most common cause of cloud security breaches?

Misconfiguration is the leading cause of cloud security breaches. Common examples include public S3 buckets exposing data to the internet, overly permissive IAM policies granting excessive access, security groups allowing traffic from any IP address, and disabled logging that prevents incident investigation. Cloud platforms offer thousands of settings, and a single misconfiguration can expose an entire environment.

What is the difference between IaaS, PaaS, and SaaS?

IaaS (Infrastructure as a Service) provides virtual servers and storage — you manage the OS, applications, and data. Examples include AWS EC2 and Azure VMs. PaaS (Platform as a Service) provides a runtime environment — you manage your application code and data. Examples include Azure App Service. SaaS (Software as a Service) provides complete applications — you manage user access and data configuration. Examples include Microsoft 365 and Salesforce.

What is an S3 bucket misconfiguration?

An S3 bucket misconfiguration typically refers to an AWS S3 storage bucket that has been set to allow public access, meaning anyone on the internet can view or download its contents. This has caused numerous major data breaches. AWS now blocks public access by default on new buckets, but existing buckets may still be misconfigured. Always enable account-level public access blocks as a safety net.

What is CSPM?

Cloud Security Posture Management (CSPM) refers to tools that continuously monitor cloud environments for misconfigurations and compliance violations. CSPM tools scan your cloud resources, compare them against security benchmarks like CIS, and alert you to risks such as public storage, overly permissive access, and disabled encryption. Examples include AWS Security Hub, Microsoft Defender for Cloud, and open-source tools like Prowler.

What is cloud IAM and why is it important?

Cloud Identity and Access Management (IAM) controls who can authenticate to your cloud environment and what actions they are authorised to perform. IAM is important because identity has replaced the network perimeter as the primary security control in the cloud. A compromised IAM credential can give an attacker access to all cloud resources. MFA, least privilege, and regular access reviews are essential IAM practices.

What are the biggest cloud security threats?

The top cloud security threats include misconfiguration (the number one cause of breaches), insecure APIs that manage cloud resources, identity and access management failures, data breaches through exposed cloud storage, container and serverless vulnerabilities, and insufficient logging that prevents incident detection and investigation.

Do I need cloud certifications for entry-level cybersecurity jobs?

Cloud-specific certifications like AWS Cloud Practitioner or AZ-900 are helpful but not always required for entry-level security roles. What matters more is understanding cloud security fundamentals — the shared responsibility model, IAM, common misconfigurations, and cloud-native threats. CompTIA Security+ SY0-701 covers cloud security concepts and is a stronger starting point for most cybersecurity roles.

What is container security?

Container security involves protecting containerised applications (Docker, Kubernetes) from threats including vulnerable base images with known CVEs, container escape attacks that break out of the container to access the host, insecure Kubernetes configurations, and overprivileged container runtime settings. Container security requires scanning images before deployment, enforcing runtime policies, and monitoring for anomalous container behaviour.

How do I practise cloud security as a beginner?

Sign up for a free-tier cloud account on AWS, Azure, or GCP. Practise creating and securing resources — set up an S3 bucket and configure access controls, create IAM users with least-privilege policies, enable CloudTrail logging, and run security assessment tools like Prowler. Free-tier accounts provide enough resources for meaningful hands-on learning without incurring costs.

More resources

AWS Shared Responsibility Model

AWS documentation explaining the shared responsibility model — the foundational concept for cloud security.

Visit CIS Benchmarks for Cloud

Free security configuration benchmarks for AWS, Azure, and GCP from the Center for Internet Security.

Visit ASD ISM Cloud Security Guidelines

Australian Signals Directorate Information Security Manual guidance for cloud computing security assessment.

Visit

Sources: AWS, Azure, and GCP security documentation, NIST SP 800-144, CIS Benchmarks, ASD ISM, OWASP Cloud Security. Last verified: March 2026.

Cloud Security — Shared Responsibility, Misconfigurations, and Cloud Threats

What Is Cloud Security and Why Does It Matter?

What Do Real-World Cloud Security Attacks Look Like?

What Are the Key Concepts Behind Cloud Security?

Cloud Service Models

Cloud Deployment Types

The Shared Responsibility Model

📊 Visual Explanation

Step-by-Step: Understanding Cloud Security Threats

Threat 1: Misconfiguration

Threat 2: Insecure APIs

Threat 3: Identity and Access Management Failures

Threat 4: Data Breaches Through Cloud Storage

Threat 5: Container and Serverless Vulnerabilities

How Does Cloud Security Fit Into a Security Architecture?

On-Premises vs Cloud Security

📊 Visual Explanation

Cloud Security Tools and Services

CSPM (Cloud Security Posture Management)

What Does Cloud Security Look Like in Practice?

AWS S3 Bucket Security Checks

AWS IAM Security Checks

Cloud Security Logging Verification

Prowler — Open-Source Cloud Security Assessment

What Are the Limitations of Cloud Security Controls?

What Interview Questions Should You Expect About Cloud Security?

How Is Cloud Security Used in Real Security Operations?

Day-One SOC Cloud Scenarios

Cloud Security Posture Management Workflow

Australian Context: Cloud Security and the ASD ISM

Summary and Key Takeaways

Related

Frequently Asked Questions

Related sections

More resources