None of the ranking pages we checked covers IMDSv2, iam:PassRole, or session credentials outliving a deleted key, and two of their Kubernetes sets still teach PodSecurityPolicy as current, four years after its removal.
Sources: Glassdoor and Blind candidate reports, the practitioner-compiled jassics list, and staffing firm KORE1‘s scenario prompts (August 2026); Azure and GCP candidate evidence is thin. Loops and format rounds are in the security engineer interview guides.
The cloud security question families and what a strong answer names
| Question family | How it is asked (source) | What a strong answer names |
|---|---|---|
| Shared responsibility | Managed Kubernetes on a major cloud: “Draw the line.” (KORE1 list) | The provider runs the control plane; you own identities, RBAC, pods, network exposure and data |
| IAM scoping | Scope a role that reads one S3 bucket and writes one SQS queue (KORE1 list) | Named actions on two ARNs plus KMS, explicit deny beating any allow, Access Analyzer unused-access findings |
| IAM privilege escalation | “What’s wrong with this policy” (jassics list) | iam:PassRole plus compute creation, iam:CreatePolicyVersion, iam:UpdateAssumeRolePolicy |
| Multi-account guardrails | 40 AWS accounts, a security team of three (KORE1 list) | IAM Identity Center, SCPs on principals, RCPs on resources, permission boundaries for delegated roles |
| Network segmentation | A default security group open on 22, 3306 and more (jassics list) | Strip the default group’s rules, nothing world-open but the load balancer, stateful SGs versus stateless NACLs, VPC endpoints |
| Instance metadata and SSRF | “The difference between IMDSv1 and IMDSv2” (Addepar candidate, Glassdoor) | Precedence, the token-optional default, account enforcement since February 24, 2026, node hop limit 1 |
| KMS and encryption | “File download but can’t see the object”; rotation period (jassics list) | The key policy as the first gate, kms:Decrypt for the caller; rotation is mostly compliance (365-day default, custom periods allowed) and re-encrypts nothing |
| Database credentials | “How to secure the database, even if the credential is leaked?” (Glassdoor candidate) | Services: short-lived or IAM auth plus network limits. People: MFA, missing in the 2024 Snowflake customer breaches |
| Logging and detection | “CloudTrail vs CloudWatch” (jassics list) | CloudTrail as the audit trail, GuardDuty sources versus protection plans, Security Hub versus Security Hub CSPM |
| Kubernetes | A mounted service account token has cluster-admin; nobody knows why (KORE1 list) | PSP removed in v1.25, Pod Security Admission, kubectl auth can-i, webhooks as attack surface |
| CSPM and CNAPP triage | “Your CNAPP just surfaced 1,200 new findings” (KORE1 list) | Attack paths over severity counts; Security Hub, Defender for Cloud, Security Command Center |
| Cloud incident response | A role “was just assumed from an AWS account you don’t recognize” (KORE1 list) | Audit the trust policy (wildcard principal, no sts:ExternalId or aws:PrincipalOrgID), revoke its sessions, add an org-ID RCP with vendor exceptions |
Scoping an AWS IAM role, then finding its escalation path
The first half of the S3-and-SQS answer is table stakes: s3:GetObject on arn:aws:s3:::orders-bucket/*, sqs:SendMessage on one queue ARN, kms:Decrypt if the bucket uses SSE-KMS, and kms:GenerateDataKey if the queue is encrypted with a customer managed key. The judgment the loop rewards is in the second half: “how you’d know six months from now if that scope had quietly grown.” IAM Access Analyzer’s unused-access findings answer it.
Rhino Security Labs catalogs 21 IAM privilege-escalation methods, and three cover most policies you’ll be handed to critique. iam:CreatePolicyVersion lets a principal write a new version of a policy attached to itself and make it the default in one call. iam:PassRole on "Resource": "*" runs code as a more privileged role, given lambda:CreateFunction plus a way to invoke it, or ec2:RunInstances plus a way to read the instance’s credentials. iam:UpdateAssumeRolePolicy rewrites a role’s trust policy to trust the attacker.
IMDSv2 is still token-optional unless something says otherwise
IMDSv1 answers any GET; IMDSv2 wants a PUT for a session token first. What candidates miss is precedence. EC2 takes metadata settings from the launch parameter, then the account default for that Region, then the AMI, and with none set the instance gets “V1 or V2 (token optional).” Amazon Linux 2023 ships with ImdsSupport at v2.0, but an unflagged older or custom AMI falls back to token optional.
Since February 24, 2026 an account can enforce IMDSv2 with HttpTokensEnforced: launches that allow IMDSv1 fail, and IMDSv1 can’t be re-enabled on instances that have it off. A Deny on ec2:RoleDelivery NumericLessThan 2.0, in an IAM policy or SCP, makes credentials fetched through IMDSv1 unusable.
AWS recommends a hop limit of 2 for containers, but the EKS best-practices guide warns that even with IRSA or EKS Pod Identity (2023), a pod “can still inherit the rights of the instance profile.” Default nodes to IMDSv2-only with hop limit 1, or block 169.254.169.254 from pods, and keep hop limit 2 only on node groups whose workloads need IMDS; IRSA and Pod Identity are why most don’t.
Azure and GCP require a request header and reject anything carrying X-Forwarded-For; more in why SSRF interviews begin at 169.254.169.254.
Capital One 2019, with the disputed step left disputed
Capital One is the SSRF-to-metadata story, uncertainty included. On record: the March 2019 intrusion affected about 100 million people in the US and 6 million in Canada. DOJ says it came “through a misconfigured web application firewall,” and the criminal complaint says a command returned credentials for “*****-WAF-Role,” used to copy more than 700 S3 folders.
The SSRF step is inferred. AWS CISO Stephen Schmidt’s letter to Senator Wyden said “we believe a SSRF attack was used,” and an AWS spokesperson told The Register SSRF was “just one of many subsequent steps,” while Snyk argued SSRF wasn’t the primary factor. The OCC’s $80 million penalty (August 2020) cited weak risk assessment before the cloud migration and alerting failures. So answer in three layers: a relayed request, probably SSRF, then an over-permissioned role, then detection that didn’t fire.
A leaked access key: deleting it doesn’t end the incident
The weak answer to “how do you respond if GuardDuty detects a compromised IAM key?” is “deactivate, rotate, check CloudTrail,” which misses three things. Look before you delete: pull the key’s last-used time, service and Region, since deletion takes that record with it. Work from a separate admin principal.
Temporary credentials outlive the key. Sessions minted with sts:GetSessionToken, sts:GetFederationToken or by assuming a role stay valid until they expire, up to 36 hours. Permissions are checked on every request, so attach a deny-all policy to the user, which covers its own session tokens, and revoke active sessions on any role it assumed.
When a key lands in a public GitHub repo, AWS may move first and attach AWSCompromisedKeyQuarantineV3 to the user; in Unit 42’s December 2025 test, published September 2026, that took 10 seconds. The Health event and support case leave no CloudTrail entries, and the AttachUserPolicy record names the compromised user as userIdentity without marking it automated, so it looks like the victim attached a policy to itself. Alert on AttachUserPolicy with that policy ARN, and leave the policy on, as its description asks.
Its deny list is mostly anti-fraud (RunInstances, Bedrock, SES, Lightsail, Organizations) plus s3:GetObject, s3:ListBucket and new user sessions. It doesn’t list sts:AssumeRole, Secrets Manager, SSM Parameter Store or DynamoDB, so whatever of those the user could already reach stays reachable. Then hunt for persistence: new users, keys or roles, trust-policy edits, Lambda functions and CloudTrail changes.
Kubernetes security after PodSecurityPolicy, and the cluster-admin token
Reaching for PSP dates you: it was removed in v1.25, and the supported releases are now 1.35 to 1.37. Pod Security Admission, stable since v1.25, sets a level (privileged, baseline, restricted) for each mode (enforce, audit, warn) through namespace labels such as pod-security.kubernetes.io/enforce: restricted. For rules it can’t express, name ValidatingAdmissionPolicy (GA in v1.30), Kyverno or Gatekeeper.
For the cluster-admin prompt, check what the account can do, then who granted it:
kubectl auth can-i --list --as=system:serviceaccount:<ns>:<sa>
kubectl get clusterrolebindings -o json | jq -r '.items[]
| select(.roleRef.name == "cluster-admin")
| "\(.metadata.name): \(.subjects)"'Repeat with rolebindings -A. The filter misses custom roles granting * on *, and an account bound through the system:serviceaccounts group won’t appear by name, which is why can-i comes first.
Learn what the workload uses before taking anything away: read the API server audit log for that service account (on EKS, only if you turned on control plane audit logging), write a Role or ClusterRole with only those verbs and resources, bind it, and delete the cluster-admin binding. Set automountServiceAccountToken: false where pods never call the API, and block repeats with an admission rule that rejects new cluster-admin bindings outside a break-glass group.
Admission webhooks are attack surface too: IngressNightmare (CVE-2025-1974, rated 9.8), found by Wiz, was an unauthenticated ingress-nginx webhook flaw giving code execution under a service account that could read every namespace’s secrets.
SCARLETEEL, from a pod to a Terraform state file
Sysdig’s February 2023 SCARLETEEL write-up maps onto the families above: an exposed service in self-managed Kubernetes on AWS, node role credentials through IMDSv1, keys in Lambda environment variables, more than 1TB out of S3, a Terraform state file with plaintext keys, and some CloudTrail logging disabled. The pivot into a second account failed because its user was tightly scoped. The Sysdig interview guide covers its loop.
Azure, Google Cloud and the AWS Security Hub rename
Since December 2, 2025, “AWS Security Hub” means the unified product that correlates GuardDuty, Inspector, Macie and CSPM findings into attack paths; the old standards-and-controls service is AWS Security Hub CSPM, and AWS recommends enabling both.
One reported Azure question compares service principals, enterprise apps and management groups with AWS. Azure AD has been Microsoft Entra ID since 2023, with Entra Conditional Access for policy and managed identities for workloads. Posture lives in Microsoft Defender for Cloud, a CNAPP with a free Foundational CSPM tier; a set that still says “Azure Security Center” is years stale.
On Google Cloud, organizations created on or after May 3, 2024 block service account key creation by default. Security Command Center Premium adds attack path simulation and Container Threat Detection, the counterpart to GuardDuty Runtime Monitoring and Defender for Containers, and the Enterprise tier shuts down on May 21, 2027.
The design round and the coding screen
Amazon’s “cloud native book store” prompt (reported on Blind) is a threat model with a cloud diagram: trust boundaries first, then threats at each one, as in the threat modeling interview walkthrough and the security system design interview. Amazon’s prep page lists “Scripting and automation” among its seven competencies, and one Glassdoor candidate reported writing a CLI tool for a mock set of microservices; the secure code review interview and application security engineer interview questions cover the code-reading side.
For cloud-heavy vendor loops, see the Wiz, Orca Security and Rapid7 interview guides and the Upwind interview guide. At Amazon (see the Amazon security engineer interview loop), none of Amazon’s seven competencies is cloud security, yet a Blind candidate counted cloud architecture as one of five rounds. Both hold if cloud questions arrive inside the design round, which is where to prepare for them anyway.
Practice the behavioral round:
