Cloud security interview questions

Questions and answers

5 questions with model answers

Rewrite each answer in your own words before the loop — interviewers can tell a memorized paragraph from one you can defend under a follow-up.

1. Question 1

   Explain the shared responsibility model with a concrete example.

   The provider secures the infrastructure — physical facilities, hypervisor, managed service internals — and the customer secures what they put on it: identity and access, data classification and encryption choices, network exposure, patching of anything they run, and configuration. The line moves with the service model, which is the part interviewers want: on EC2 you patch the guest OS, on RDS the provider patches the engine but you still own credentials, network placement, and backups, and on S3 there is no OS at all but bucket policy and encryption are entirely yours. Nearly every headline cloud breach lands on the customer side of that line — a public bucket, an overprivileged role, a leaked long-lived key. Saying that plainly shows you know where to spend effort.

2. Question 2

   What does least privilege actually look like in cloud IAM?

   It means each principal holds only the actions it needs, scoped to specific resources, ideally with conditions — source VPC endpoint, MFA present, tag match — rather than a wildcard on both action and resource. In practice I would start from actual usage data, such as AWS IAM Access Analyzer or last-accessed information, and shrink policies toward observed behavior instead of guessing. I would replace long-lived access keys with short-lived credentials from roles or workload identity federation, because leaked static keys remain one of the most common initial access paths. I would also watch the escalation paths that a policy accidentally grants — iam:PassRole with a permissive service trust, or the ability to attach policies to yourself, is administrative access wearing a disguise.

3. Question 3

   Why does the instance metadata service matter to an attacker?

   The metadata endpoint hands out temporary credentials for the role attached to the instance, so any request-forging bug in an application running on that instance can turn into cloud API access without touching a password. IMDSv1 answers a plain unauthenticated GET, which is exactly what an SSRF can produce; IMDSv2 requires a PUT to obtain a token with a restricted TTL and hop limit, which defeats the simple SSRF case. Beyond enforcing IMDSv2 I would keep instance roles minimal so stolen credentials reach little, and alert on metadata credentials being used from an IP outside the instance. It is a good answer to have ready because it connects an application bug to a cloud-wide consequence, which is the reasoning cloud teams hire for.

4. Question 4

   You suspect a cloud account is compromised. What do you look at first?

   Control-plane logs first — CloudTrail, Azure activity logs, or GCP audit logs — filtered to the suspected principal and window, because they record every API call that could create persistence or move laterally. I look for the classic follow-on pattern: enumeration calls, then creation of new users, access keys, or roles, trust policy edits, changes to logging or GuardDuty configuration, and activity in regions the organization never uses. In parallel I check identity provider logs for how the session was obtained and revoke it properly — for temporary credentials that means revoking the role's sessions, since deleting a key does not invalidate credentials already issued. Containment then focuses on removing attacker-created identities and rotating what was exposed, before rebuilding anything that ran untrusted code.

5. Question 5

   What changes about security when workloads move to containers?

   Containers share the host kernel, so isolation is weaker than a VM and a kernel vulnerability or an over-permissive container becomes a host compromise — running as root, privileged mode, hostPath mounts, or a mounted Docker socket are the usual culprits. Supply chain becomes a first-class concern because images pull in base layers and packages you did not audit, so image provenance, pinned digests, and scanning in CI matter more than at VM scale. Secrets handling changes too: environment variables end up in image history, orchestrator manifests, and process listings, so secrets belong in a manager with short-lived tokens. At runtime the useful controls are a minimal base image, read-only filesystems, dropped capabilities, network policy between workloads, and runtime detection, because a compromised container should not be able to reach the whole cluster.