Cloud security interviews rarely fail on definitions; they fail when the candidate cannot trace how one leaked credential or one permissive policy turns into a data breach, and what would have stopped it. This guide gives the questions hiring managers ask cloud security engineers across identity and access, guardrails, network and data protection, Kubernetes, detection and incident response, with model answers that show the depth expected at mid and senior level. Questions are grouped by topic, and each answer names the real setting, API or log a strong candidate would mention. Examples use AWS, Azure and Google Cloud, listed alphabetically; most interviews go deep on one provider but test whether you can reason across all three. It is written for candidates preparing for cloud security engineer, cloud security architect and platform security roles, and for hiring managers building a consistent question bank. For the role itself, skills and progression, see the Cloud Security Engineer Career Guide.
Key takeaways
- Identity is the centre of most questions. Expect to explain how roles, trust policies, service principals and service accounts work, and how you would remove long-lived keys.
- Explain the evaluation logic, not just the feature. Strong answers say how an organisation guardrail, an identity policy and a resource policy combine into an allow or deny.
- Tie every control to an attack. Interviewers want to hear which technique a control blocks, for example IMDSv2 against metadata credential theft (ATT&CK T1552.005).
- Kubernetes is now a standard round. Pod Security Admission, RBAC, service account tokens and workload identity come up in most cloud security interviews.
- Scenarios decide senior hires. Practise one design question and one incident question out loud, with phasing, trade-offs and rollback.
How cloud security interviews are structured
| Round | What is assessed | How to prepare |
|---|---|---|
| Screen with recruiter or hiring manager | Scale and scope: number of accounts or subscriptions, providers, what you owned end to end | Have numbers ready: accounts in scope, findings reduced, keys removed, detections shipped |
| Cloud fundamentals | IAM model, networking, encryption, logging in at least one provider | Be able to draw how a request is authorised in your main provider |
| Hands-on or take-home | Reading a policy, a Terraform plan or a set of logs and finding the problem | Practise reviewing IAM policies and trust policies for wildcards and missing conditions |
| Kubernetes and containers | Cluster access, pod security, image supply chain, workload identity | Know the three Pod Security Standards levels and how RBAC bindings are audited |
| Design scenario | Architecture judgement: multi-account structure, guardrails, phased rollout | Rehearse a 30-minute whiteboard: secure landing zone for 50 teams |
| Incident scenario | Triage method, containment order, evidence | Rehearse "access key found on a public repository" from first alert to closure |
| Behavioural | Influencing engineering teams without blocking delivery | Prepare two stories where you changed a default for many teams |
Identity and access questions
Q: How is an API request authorised in AWS when several policy types apply?
A strong answer: an explicit deny anywhere wins. Within an account, the request needs an allow from an identity-based or resource-based policy, and must also be within any permissions boundary and session policy. Across AWS Organizations, service control policies and resource control policies set the maximum available; AWS states that no permissions are granted by an SCP. Add the exceptions: SCPs do not affect the management account or service-linked roles. See the AWS IAM Policies and Roles Guide.
Q: What is a trust policy and what would you look for when reviewing one?
The trust policy on a role defines which principals can assume it. Look for whole-account principals where a specific role would do, wildcard principals, missing external ID on third-party roles (the confused deputy problem), and, for OIDC federation, missing conditions on the subject claim so that any repository or branch could assume the role.
Q: How would you remove long-lived access keys from a large AWS estate?
- Inventory keys and last-used dates from the IAM credential report and IAM Access Analyzer unused access findings (unused roles, access keys, passwords and permissions).
- Classify by consumer: CI/CD (move to OIDC federation), workloads on AWS (move to roles on the instance, task or function), on-premises workloads (IAM Roles Anywhere), humans (IAM Identity Center).
- Deactivate before deleting, watch for failures for a set period, then delete.
- Prevent regression with an SCP or detection on CreateAccessKey, and track a "static keys remaining" metric.
See the AWS Access Keys Security Guide.
Q: Explain managed identities and workload identity federation in Azure.
Managed identities are Entra identities for Azure resources whose credentials the platform issues and rotates: system-assigned (lifecycle tied to one resource) or user-assigned (standalone and reusable). For workloads outside Azure, a federated identity credential on an app registration or user-assigned managed identity trusts an external identity provider; Entra ID checks that the token's issuer, subject and audience match the configured values case-sensitively, then issues an access token through the client credentials grant. Sources include GitHub Actions, Kubernetes clusters, Google Cloud and AWS. See the Azure Managed Identities Security Guide.
Q: Why are Google Cloud service account keys a risk, and what replaces them?
Downloadable keys are long-lived and work from anywhere. Replace them with attached service accounts, service account impersonation for administrators, and workload identity federation for external workloads, then enforce the organisation policy constraint that disables key creation. See the Google Cloud Service Account Keys Security Guide.
Guardrail and multi-account questions
| Concept | AWS | Azure | Google Cloud |
|---|---|---|---|
| Hierarchy for policy | Organizations, organisational units | Management groups, subscriptions | Organisation, folders, projects |
| Preventive guardrail | Service control policies, resource control policies | Azure Policy (deny effect) | Organisation policy constraints |
| Posture service | AWS Security Hub | Microsoft Defender for Cloud | Security Command Center |
| Control plane audit log | AWS CloudTrail | Azure Activity Log | Cloud Audit Logs |
| Private service access | VPC endpoints (PrivateLink) | Private Endpoint | Private Service Connect |
Q: Design a multi-account structure for 50 product teams.
A strong answer separates security tooling, log archive, shared networking, production, non-production and sandbox into distinct accounts or subscriptions under a hierarchy, applies guardrails at the hierarchy level (deny disabling of audit logs, restrict regions, block public storage, deny root user actions), centralises logs into an account that workload teams cannot modify, and gives each team its own accounts per environment to limit blast radius. Mention a test path: apply new guardrails to a sandbox unit first, then non-production, then production. See the Cloud Landing Zone Security Guide.
Q: What is a data perimeter?
Preventive controls ensuring only trusted identities access trusted resources from expected networks. In AWS: SCPs restrict what your identities can reach, RCPs restrict who can reach your resources, and VPC endpoint policies restrict network paths. Candidates who mention organisation ID conditions (aws:PrincipalOrgID, aws:ResourceOrgID) show they have built one. See the Cloud Data Perimeter Guide.
Network, data and encryption questions
Q: How does IMDSv2 reduce SSRF risk?
IMDSv2 requires a session token obtained with a PUT request and sent on every GET. A typical SSRF bug only allows GET requests, PUT requests containing an X-Forwarded-For header are rejected, and the default hop limit of 1 stops the token travelling beyond the instance. Enforce it by setting HttpTokens to required. Link the answer to an incident: in the Capital One breach, role credentials taken from a misconfigured firewall could read far more storage than the role needed, so the lesson covers both metadata hardening and role scope. See the Cloud Instance Metadata Services Compared Guide.
Q: A security group allows 0.0.0.0/0 on port 22. What do you do?
Confirm whether the instance is actually reachable (public IP, route to an internet gateway), check flow logs and authentication logs for access, then replace direct SSH with a session manager or bastion service and an allow-list. Prevent recurrence with a guardrail or IaC rule, not a ticket.
Q: Provider-managed keys, customer-managed keys, BYOK or HYOK: how do you choose?
Provider-managed keys meet most encryption at rest requirements. Customer-managed keys add control over key policy, rotation, logging and the ability to disable a key. BYOK adds control of key origin. HYOK keeps the key outside the provider, at a cost in availability and latency. Choose from the threat model and regulatory requirement, not by default. See the Cloud Customer-Managed Keys and BYOK/HYOK Decision Guide.
Q: How would you find and fix public storage across the estate?
Use the posture service and external access analysis to list buckets, containers and objects reachable by anonymous users or by principals outside the organisation, check access logs for reads before changing anything, then apply account-level public access blocks (or the provider equivalent) through a guardrail. See the Cloud Storage Exposure Playbook.
Kubernetes and container questions
Q: What are the Pod Security Standards and how are they enforced?
Three profiles: Privileged (unrestricted), Baseline (blocks known privilege escalations such as privileged containers and host namespaces) and Restricted (current hardening practice, including running as non-root and dropping capabilities). The built-in Pod Security Admission controller applies them per namespace through labels, in enforce, audit or warn mode. A strong candidate rolls out in warn and audit mode first, fixes workloads, then enforces. See the Kubernetes Admission Control Guide.
Q: How do pods get cloud credentials without static secrets?
Through managed workload identity features that map a Kubernetes service account to a cloud identity: projected, audience-bound service account tokens are exchanged for cloud credentials (EKS Pod Identity or IAM roles for service accounts, AKS workload identity with Entra, GKE Workload Identity Federation). Follow-ups usually test whether one service account is shared by many workloads. See the Kubernetes NHI Security Guide.
Q: How would you audit cluster RBAC?
List ClusterRoleBindings to cluster-admin, roles with wildcard verbs or resources, permission to read secrets cluster-wide, to create pods in privileged namespaces, or to use impersonate, bind and escalate verbs. Check which service accounts hold them and whether their tokens are mounted where not needed. See the Kubernetes RBAC Guide.
Detection and incident response questions
Q: Which cloud events would you alert on first?
| Behaviour | Example signals | ATT&CK |
|---|---|---|
| New credentials added to an existing identity | New access key, new service principal secret, new service account key | T1098.001 Additional Cloud Credentials |
| Valid cloud account used from unusual context | Console sign-in or API use from new location, dormant identity becomes active | T1078.004 Cloud Accounts |
| Metadata credential theft | Instance role credentials used from outside the provider network | T1552.005 Cloud Instance Metadata API |
| Bulk storage reads | Spike in object reads, snapshot sharing, export jobs | T1530 Data from Cloud Storage |
| Reconnaissance | Burst of list and describe calls across services and regions | T1580 Cloud Infrastructure Discovery |
Also alert on changes that blind you: audit trail stopped or deleted, log sinks removed, diagnostic settings changed. See the Cloud Detection Engineering Guide.
Q: An access key appears on a public repository. Walk me through your response.
- Identify the identity and its permissions; check the audit log for every call made with the key since its creation, not only since the leak.
- Deactivate the key (do not delete yet, so the evidence remains linked), and revoke active sessions for any role it could assume.
- Look for persistence: new users, keys, roles, trust policy changes, compute in unused regions.
- Rotate dependent secrets, restore least privilege, and remove the secret from repository history.
- Fix the cause: replace static keys for that workload with federation or roles, add secret scanning in pre-commit and CI.
See the Cloud Access Key Leak Playbook.
Q: What do you preserve as evidence in a cloud incident?
Audit logs exported to a protected account, flow logs, disk snapshots of affected instances (shared to a forensics account), container images and runtime state, identity provider sign-in logs, and a record of every containment action with timestamps. See the Cloud Forensics Guide.
Scenario questions and what a strong answer contains
- Snowflake-style credential reuse: "A SaaS data platform account is accessed with a valid password from an infostealer log." A strong answer covers MFA or key-pair authentication for every account including service users, network policies limiting where logins come from, rotation, owner assignment and detection of logins from new networks. The Snowflake breach shows static, single-factor credentials without network restrictions are the gap.
- Roll out a guardrail without breaking production: stage it by hierarchy (sandbox, non-production, production), run detective mode first, publish an exception process with expiry dates, and keep a tested way to roll back.
- Reduce posture findings by half in a quarter: group findings by rule and owner, fix defaults in templates and guardrails rather than individual resources, accept or suppress with documented reasons, and report the trend.
- Secure a new AI workload in the cloud: treat the model endpoint and agent as non-human identities with their own roles, keep secrets out of prompts and environment variables, log invocations, and restrict data access to what the use case needs.
Standards interviewers expect you to know
| Reference | What to be able to say |
|---|---|
| NIST SP 800-145 | The NIST definition of cloud computing: service models IaaS, PaaS and SaaS, and how they move the shared responsibility line |
| CIS Benchmarks | Foundations Benchmarks per provider and Kubernetes benchmarks as the usual baseline for posture tools |
| NIST SP 800-53 Rev 5 | AC-6 Least Privilege, AC-2 Account Management, AU-6 Audit Record Review, CM-6 Configuration Settings, CA-7 Continuous Monitoring |
| NIST CSF 2.0 | PR.AA-05 (access permissions managed with least privilege), PR.PS-01 (configuration management), DE.CM-01 (network monitoring) |
| MITRE ATT&CK cloud techniques | T1078.004, T1098.001, T1528 Steal Application Access Token, T1530, T1552.005, T1580 |
| Kubernetes Pod Security Standards | Privileged, Baseline, Restricted; enforce, audit and warn modes |
Questions to ask the interviewer
- Scope: How many accounts, subscriptions and projects, and which providers are in scope?
- Ownership: Who owns guardrails and the landing zone: the security team, a platform team, or both?
- Identity: How many long-lived cloud keys remain, and is there a plan to remove them?
- Detection: Who writes cloud detections and who responds to them out of hours?
- Measurement: Which cloud security metrics does leadership see each month? See the Cloud Security Metrics guide.
Common failure patterns in cloud security interviews
- Tool names instead of mechanisms: naming a CNAPP product without explaining what it checks or how a finding would be fixed.
- Ignoring non-human identities: answering access questions only for human users, when roles, service principals and keys hold most cloud privilege.
- Containment without evidence: deleting a compromised key or instance before capturing logs and snapshots.
- One-provider thinking: being unable to map a familiar control to its equivalent elsewhere, even at concept level.
- No rollout plan: proposing an organisation-wide deny policy with no staged deployment, exception path or rollback.
Practitioner checklist
- Draw the authorisation flow for your main provider, including organisation guardrails and resource policies.
- Prepare a worked answer for removing static keys, with numbers from your own experience.
- Read and critique at least three real IAM policies and three trust policies before the interview.
- Learn the equivalent names for hierarchy, guardrail, posture and audit log services across AWS, Azure and Google Cloud.
- Know the three Pod Security Standards and how you would audit cluster RBAC.
- Rehearse the leaked access key incident aloud, including evidence and persistence checks.
- Map five common cloud detections to their ATT&CK technique IDs.
- Prepare two stories about changing a default for many engineering teams.
Standards and references
- NIST: SP 800-145, The NIST Definition of Cloud Computing
- AWS: Service control policies (SCPs)
- AWS: Use the Instance Metadata Service to access instance metadata
- AWS: What is IAM Access Analyzer?
- Microsoft Learn: Workload identity federation
- Kubernetes: Pod Security Standards
- MITRE ATT&CK: Cloud Matrix
Related NHI Mgmt Group resources: Cloud Security Engineer Career Guide · Cyber Security Interview Preparation Guide · Cloud Security Glossary · AWS Certified Security Specialty Guide · Certified Kubernetes Security Specialist (CKS) Guide