Every cloud security engineer I know has a private list of misconfigurations they see over and over again. Not the theoretical ones from certification study guides. The real ones. The ones that show up in production on a Tuesday afternoon because someone merged a Terraform change without a security review.
I have been working in cloud security long enough to know that the gap between what job postings describe and what you actually do is enormous. Job postings say "design and implement cloud security architecture." The reality is closer to "find the S3 bucket someone made public at 2 AM and figure out why your SCPs did not catch it."
This article covers the seven misconfigurations that keep showing up across every AWS, Azure, and GCP environment I have worked in. If you are considering a career in cloud security engineering, this is what your days will actually look like.
1. Overpermissioned IAM Roles with Wildcard Actions
This one never goes away. A developer needs access to S3, so someone creates an IAM policy with s3:* on Resource: *. It works, it ships, and nobody touches it again. Six months later, that role has been assumed by a Lambda function, a CI/CD pipeline, and three microservices. It can now read every bucket in the account, including the one with database backups.
The fix is not just tightening the policy. It is building a process that prevents this from happening in the first place:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::app-data-prod/*"
}
]
}
You enforce this with IAM Access Analyzer, permission boundaries, and SCPs that deny iam:CreatePolicy unless the policy document passes a validation check. You also build a Terraform module that only accepts explicit action lists and reject any PR that contains a wildcard.
This is the kind of work that separates a cloud security engineer from a sysadmin who learned AWS. You are not just fixing the misconfiguration. You are building the guardrail that makes it impossible to recur.
Want to deep-dive into IAM security patterns? The AWS Security skill tree on HADESS maps every IAM concept you need to master, from basic policies to cross-account role chaining.
2. Public Cloud Storage That Nobody Intended to Be Public
S3 buckets, Azure Blob containers, GCS buckets. Every cloud provider has a storage service, and every one of them has a setting that makes it publicly accessible. AWS has gotten better with S3 Block Public Access at the account level, but I still find buckets that predate this feature, or accounts where someone disabled the block to "fix" a deployment issue and never turned it back on.
The cloud security engineer response is layered:
-
Preventive: SCP that denies
s3:PutBucketPolicyif the policy contains"Principal": "*" - Detective: CSPM rule that alerts on any bucket without Block Public Access enabled
- Corrective: Lambda function triggered by CloudTrail that automatically re-enables Block Public Access if someone disables it
You do not send a Slack message asking someone to fix it. You auto-remediate and log it.
Practice this exact scenario in the DevOps City cloud-native simulation where you defend infrastructure against real misconfiguration attack chains.
3. Terraform State Files with Secrets in Plaintext
This one is insidious. Terraform stores the full state of your infrastructure, including any secrets you pass as variables. Database passwords, API keys, certificates. If your state file is in an S3 bucket without encryption, or worse, committed to a Git repository, you have a credential exposure incident.
The fix:
terraform {
backend "s3" {
bucket = "company-terraform-state"
key = "prod/terraform.tfstate"
region = "us-east-1"
encrypt = true
kms_key_id = "arn:aws:kms:us-east-1:123456789:key/abc-123"
dynamodb_table = "terraform-locks"
}
}
Encrypt at rest with KMS. Enable versioning. Lock with DynamoDB. Restrict access to the state bucket to only the CI/CD pipeline's role. And audit the state file periodically for any secrets that should be in AWS Secrets Manager or HashiCorp Vault instead.
Terraform security is a core competency for cloud security engineers. The Terraform cheatsheet on HADESS covers state management, provider lock files, and policy-as-code patterns.
4. Kubernetes Clusters Running Containers as Root
I audit Kubernetes deployments regularly and the number of pods running as UID 0 is staggering. Developers build Docker images with USER root because it is the default and nobody tells them otherwise. When a container runs as root and an attacker achieves code execution inside it, the blast radius expands dramatically. Container escapes become trivial on unpatched nodes.
The fix is a combination of Pod Security Standards and admission control:
apiVersion: v1
kind: Pod
metadata:
name: secure-app
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
fsGroup: 2000
containers:
- name: app
image: app:latest
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- ALL
You enforce this with OPA/Gatekeeper or Kyverno policies that reject any pod spec without runAsNonRoot: true. You build this into the CI/CD pipeline so it fails before it ever reaches the cluster.
The Kubernetes skill tree covers pod security, network policies, RBAC, and runtime detection. If you are targeting cloud security roles, K8s security is non-negotiable in 2026.
5. Security Groups That Allow 0.0.0.0/0 on Management Ports
SSH (22) and RDP (3389) open to the internet. In 2026. It still happens. Usually because someone needed to debug a production issue and added a temporary rule that became permanent. Or because a CloudFormation template from 2019 never got updated.
The real problem is not the individual rule. It is the lack of automated enforcement:
# AWS Config custom rule - auto-remediate open SSH
def lambda_handler(event, context):
ec2 = boto3.client('ec2')
sg_id = event['detail']['requestParameters']['groupId']
response = ec2.describe_security_groups(GroupIds=[sg_id])
for permission in response['SecurityGroups'][0]['IpPermissions']:
for ip_range in permission.get('IpRanges', []):
if ip_range['CidrIp'] == '0.0.0.0/0' and permission['FromPort'] in [22, 3389]:
ec2.revoke_security_group_ingress(
GroupId=sg_id,
IpPermissions=[permission]
)
You pair this with an SCP that denies ec2:AuthorizeSecurityGroupIngress when the CIDR is 0.0.0.0/0 and the port is a management port. Defense in depth, but automated.
Explore the full Cloud Security skill tree to see where security groups fit in the broader cloud security competency map.
6. Missing CloudTrail or Disabled Logging Regions
CloudTrail is enabled in us-east-1. Great. But the attacker spins up resources in ap-southeast-1 where there is no trail configured. You have zero visibility. This is especially dangerous with services like EC2 that can be launched in any region for cryptomining.
The fix is an organization-level trail that covers all regions and all accounts:
aws cloudtrail create-trail \
--name org-trail \
--s3-bucket-name org-cloudtrail-logs \
--is-organization-trail \
--is-multi-region-trail \
--enable-log-file-validation
Then you add an SCP that denies cloudtrail:StopLogging and cloudtrail:DeleteTrail for everyone except the security account. If someone manages to disable logging, you want GuardDuty (which has its own independent data source) to catch it.
7. Cross-Account Role Assumptions Without External ID
When you set up cross-account access with sts:AssumeRole, failing to use an external ID opens you to the confused deputy problem. A malicious third party can trick your service into assuming a role in their account by providing your account ID as the trusted principal.
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "unique-per-customer-id-here"
}
}
}
This is a subtle one that junior engineers miss completely. It shows up in SaaS integrations, MSSP monitoring setups, and any multi-tenant architecture. If you understand the confused deputy problem and can explain it clearly in an interview, you are already ahead of most candidates.
Preparing for cloud security interviews? HADESS interview prep includes scenario-based questions exactly like this one, covering IAM, network security, and incident response in cloud environments.
What This Role Actually Requires
If you read through these seven examples, you will notice a pattern. Cloud security engineering is not about running scans and reading dashboards. It is about:
- Writing code. SCPs, Terraform modules, OPA policies, Lambda remediation functions, Config rules. You write more code than most "security" roles.
- Understanding infrastructure deeply. You cannot secure what you do not understand. IAM, networking, compute, storage, identity federation.
- Building systems, not just finding problems. Anyone can run a CSPM scan. The value is in building the automated guardrails that prevent misconfigurations before they reach production.
- Working across teams. You are the person who tells the platform team their Terraform module is insecure and then helps them fix it. Communication matters as much as technical depth.
The Skill Stack for 2026
Based on what I see in job postings and what actually matters on the job:
| Skill | Why It Matters | Where to Learn |
|---|---|---|
| AWS IAM | Foundation of everything | AWS Security on HADESS |
| Terraform / IaC | Every cloud security team uses it | Terraform Cheatsheet |
| Kubernetes Security | Container workloads are everywhere | K8s Skill Tree |
| CSPM Tools | Prisma Cloud, Wiz, Orca, AWS Security Hub | CSPM Cheatsheet |
| Python | Automation, Lambda functions, tooling | Practice with real scenarios |
| Azure Security | Multi-cloud is the norm | Azure Security on HADESS |
| Zero Trust | Architecture model for modern environments | Zero Trust Cheatsheet |
Certifications Worth Your Time
Not all certs are equal. Here is what actually moves the needle for cloud security engineering roles:
- AWS Security Specialty: The most respected cloud security cert. Covers IAM, logging, encryption, incident response on AWS. Takes 2 to 3 months of focused study.
- CCSP (ISC2): Vendor-neutral cloud security. Good for architects and senior engineers. Requires 5 years of experience.
- AZ-500 (Microsoft): Azure-specific security. Essential if your target employers run Azure.
- SC-100 (Microsoft): Cybersecurity architect. Strategic level, covers multi-cloud.
- CKS (Kubernetes): Certified Kubernetes Security Specialist. Hands-on exam. High value if you work with container workloads.
Map your certification path with the HADESS certificate roadmap. It shows you which certs to prioritize based on your current level and target role.
The Money
Cloud security engineering is one of the highest-compensated roles in cybersecurity:
- Junior (0 to 2 years): $90K to $130K
- Mid-level (2 to 5 years): $130K to $200K
- Senior (5 to 8 years): $180K to $260K
- Principal / Architect (8+ years): $220K to $300K+
These numbers are US-based. Major metros (NYC, SF, Seattle) pay at the top of the range. Remote roles typically pay 10% to 15% less but are more common in cloud security than in SOC roles because the work does not require physical presence.
Check exact salary data for your location and experience level with the HADESS salary calculator.
How to Break In
The most common paths into cloud security engineering:
- From DevOps/SRE: You already know the infrastructure. Add security specialization. Fastest path.
- From SOC/Security Analyst: You understand threats. Add cloud infrastructure knowledge. Medium path.
- From Sysadmin/Network Engineering: You understand operations. Add both cloud and security. Longer but solid.
- From Software Engineering: You can code. Add cloud infrastructure and security domain knowledge.
Regardless of your starting point, build a home lab. Deploy a multi-account AWS Organization with Terraform, set up CloudTrail, Config Rules, GuardDuty, and Security Hub. Break things on purpose and fix them. Document it on GitHub. This portfolio matters more than any certification.
Take the HADESS skill assessment to see where you stand and what gaps to close for cloud security roles.
Practice Before You Interview
Cloud security interviews in 2026 are increasingly hands-on. You will be asked to whiteboard IAM architectures, write policies live, and walk through incident response scenarios in cloud environments.
Practice with these interactive scenarios:
- Cloud Native City - defend cloud infrastructure in a simulation
- Terraform Security - Capital One breach recreation with IMDSv1 SSRF
- Operation Cloud Siege - multi-cloud attack and defense
- Azure Storm - Azure identity and infrastructure attack chain
- Container Fortress - Docker and Kubernetes attack chain
Where to Go From Here
Cloud security engineering leads naturally into several senior paths:
- Cloud Security Architect - designing security for entire cloud estates
- Multi-Cloud Security Engineer - specializing across AWS, Azure, and GCP simultaneously
- Security Director / CISO - leadership track with cloud security as your technical foundation
The full Cloud Security Engineer career path guide on HADESS covers 45 pages of progression maps, real job postings with skill analysis, and a 90-day action plan.
Built by HADESS - career intelligence for cybersecurity professionals. Skill assessments, interview prep, salary data, and career path planning.
Top comments (0)