15 AWS Security Misconfigurations Interviewers Actually Test You On

Quick Answer: AWS security interview questions are almost never abstract — they present a misconfiguration and ask what you would do. The fifteen that come up most are: public S3 buckets, wildcard IAM policies, leaked access keys, unprotected root accounts, 0.0.0.0/0 security groups, unconditioned cross-account trust, over-broad iam:PassRole, deletable CloudTrail, no alerting on IAM changes, shared snapshots or AMIs, secrets in code, default VPCs in production, missing SCPs, open queue and topic policies, and unencrypted or unmonitored backups. Interviewers are testing your process, not just your fixes.

How Interviewers Actually Frame These Questions

Very few interviewers ask “what is a security group.” The realistic formats you will meet in Indian cloud security interviews are three.

The scenario fix. “An S3 bucket containing customer exports was found to be public. Walk me through what you do.” They want sequence: verify exposure, determine blast radius, contain, remediate, then prevent recurrence — including the audit trail, because the follow-up is always “what do you tell the client afterwards?”

The detective control. “How would you know this happened?” This separates candidates who know the theory from those who have operated an account. CloudTrail, GuardDuty, Config rules, Access Analyzer and EventBridge alarm patterns are the expected vocabulary.

The prevention design. “How do we stop it happening again?” SCPs at the organisation level, permission boundaries, block-public-access at the account level, policy-as-code in the pipeline. Answers that only patch the single resource score poorly.

The 15 Misconfigurations, and What Each One Is Testing

1. Public S3 bucket with Block Public Access disabled. The classic. What they test: whether you check which public access setting failed — bucket policy, ACL, account-level — and whether you reach for the account-level Block Public Access control rather than fixing one bucket.
2. Action “Action”: “*”,”Resource”: “*” — wildcard policies. What they test: whether you know which IAM actions support resource-level scoping and can name Access Analyzer as the tool that finds them.
3. Long-lived access keys committed to git. What they test: your incident sequence — deactivate before anything else, review CloudTrail for every action taken with that key, then rotate everything and find how it leaked.
4. Root account used for daily work, no hardware MFA. What they test: whether you would alarm on root console login as standard, and whether you know root cannot be constrained by SCPs in the way IAM identities can.
5. Security group allowing 0.0.0.0/0 on port 22 or 3389. What they test: whether you suggest a reference-based rule between security groups rather than an IP range, and whether you know NACLs are a different layer entirely.
6. Cross-account role trust with only an account ID. What they test: external ID, the confused-deputy problem, and conditions such as principal tags or aws:PrincipalOrgID. Candidates who cannot explain confused deputy rarely pass a security screen.
7. iam:PassRole allowed on “*”. What they test: the escalation path — pass an admin role to Lambda or SageMaker and inherit its permissions. Naming iam:PassedToService as the condition is a strong signal.
8. CloudTrail not enabled, not multi-region, or logs deletable. What they test: log immutability — S3 Object Lock or a separate log-archive account — and whether “we have CloudTrail on” was ever followed by “and someone reads it.”
9. No alerting on identity changes. What they test: whether you would put an EventBridge rule on CreateUser, AttachUserPolicy and failed console logins, and where the notification goes at 3 AM.
10. Public AMI or snapshot shared broadly. What they test: data at rest leaving the account — EBS snapshots, RDS snapshots and AMIs are a frequently forgotten exfiltration path, and aws ec2 describe-snapshots with owner self reveals them.
11. Secrets in environment variables or code. What they test: whether you know about Secrets Manager rotation, Parameter Store secure strings, and that a git history rewrite does not un-leak a key.
12. Default VPC used for production workloads. What they test: architectural awareness as much as security — default VPCs span all AZs with a public subnet in each, so production ends up internet-facing without anyone deciding it should be.
13. No SCPs, or FullAWSAccess never replaced. What they test: whether you understand SCPs restrict rather than grant, and whether you would test a guardrail after writing it rather than assuming it works.
14. SQS, SNS or KMS policies with Principal “*”. What they test: resource-policy thinking — a queue that any AWS account can send to is a data poisoning vector, and cross-account access needs explicit principals plus conditions.
15. Backups unencrypted and unmonitored. What they test: the boring completeness of security — snapshot encryption, retention, and whether deletion of backups would be detected at all.

One observation after enough of these interviews: the candidates who pass are not the ones who memorise all fifteen — they are the ones who answer each one the same disciplined way. Detect, contain, remediate, prevent, and tell me what the audit trail shows. A candidate who runs through that framework on a question they have never heard will always beat one reciting a checklist they have.

The Candidate Who Fixed It Wrong

A panel I sat on in 2025 gave a mid-level candidate this: “A bucket holding KYC documents is public. Go.” He answered quickly and confidently — set the bucket policy to deny non-VPC access, enable encryption, add a lifecycle rule. Technically he listed real controls. Then we asked the second question: how long has it been public, and who accessed it?

Silence. He had jumped to remediation without touching CloudTrail or S3 server access logging, so he could not establish the exposure window, could not say whether objects had been downloaded, and had therefore already destroyed evidence by overwriting the policy. The candidate after her started differently: check GetObject logging first, capture the current policy, then block public access at account level, then rotate anything the bucket might have referenced, and only then write the incident note. Same knowledge, different order — and only one of them would be trusted with a client incident.

The remediation he skipped has a detection-side companion worth memorising, since “how would you find this?” is the question that follows most AWS security interview questions:

# Is anything in this account publicly exposed right now?
aws s3api get-public-access-block --bucket customer-exports
aws s3api get-bucket-policy-status --bucket customer-exports

# Turn on the detective controls an interviewer expects you to name
aws accessanalyzer create-analyzer --analyzer-name org-analyzer --type ACCOUNT
aws guardduty create-detector --enable --finding-publishing-frequency FIFTEEN_MINUTES

# Which identities have credentials nobody has used?
aws iam generate-credential-report && aws iam get-credential-report 
  --query 'Content' --output text | base64 -d

Which of the 15 Come Up at Which Level

How to Prepare Practically

1. Break an account on purpose. Create each misconfiguration in a sandbox account, then detect it with the commands above and fix it. Six hands-on hours beats a weekend of reading.
2. Write your incident answers down. A four-step framework — detect, contain, remediate, prevent — with one concrete tool call for each step.
3. Learn the escalation chains. PassRole, assume-role chaining, and what an over-permissive Lambda role means. Interviewers probe here to find the limit of your understanding.
4. Follow real incidents. The public-postmortem patterns map directly onto these fifteen questions, and being able to reference a real case signals currency.

If you are using this list to steer your study rather than just to revise, note that IAM and organisation-level controls carry the most weight in both interviews and pay — cloud security compensation in India is consistently topped by engineers with IAM depth, as set out in AWS Cloud Security Engineer Salary India 2026. Encoding your answers as policy checks in the deployment pipeline is the senior version of all fifteen, and the tooling side is covered in Terraform vs AWS CDK vs CloudFormation.

Training Resources

Work through these misconfigurations hands-on in SkilBrill AWS Cloud Security Training — IAM design, detective controls, incident response and organisation-level guardrails, with mock interview rounds on exactly this question style.

FAQ

What AWS security interview questions should I prepare for?

Focus on misconfiguration scenarios: public buckets, wildcard IAM policies, leaked keys, open security groups, unconditioned cross-account roles and logging gaps. Expect to be asked how you would detect, contain, remediate and prevent — not just how you would patch the resource.

How do I answer an AWS security scenario question?

Use the same sequence every time: verify the exposure, establish the timeline from CloudTrail or resource logs, contain before changing anything, remediate, then add the organisation-level control that prevents recurrence. Mention what you would report and when.

Is iam:PassRole really that dangerous?

Yes — it is one of the most common privilege-escalation paths in AWS. If a principal can pass a highly privileged role to a service it controls, it effectively gains that role’s permissions. Scope it to specific role ARNs and restrict it with iam:PassedToService.

How do I find misconfigurations in my own AWS account?

Enable IAM Access Analyzer, GuardDuty and AWS Config rules, then use the credential report and S3’s public-access checks as routine monthly reviews. Access Analyzer’s unused-access findings are the fastest route to tightening policies safely.

Do AWS security interviews include coding?

Rarely algorithms. More often you will write IAM or SCP JSON, a short script to audit resources, or review a flawed policy you are asked to fix. Practising policy JSON and AWS CLI one-liners is the better use of preparation time.

Written by SkilBrill Training Institute

October 15, 2026 · 8 min read