Cloud Security — Interview Q&A
Q: Explain the shared responsibility model, and give a concrete example of where the line falls for a managed database service.
A: The cloud provider secures the infrastructure of the cloud (physical security, hypervisor, underlying network); the customer secures what they configure and put in the cloud (data, access controls, application-level security). For a managed database (RDS, for example): AWS handles OS patching, hardware failure, and the underlying database engine's security patches; you're responsible for IAM access policies to the database, network security group rules controlling who can reach it, encryption configuration, and the actual data and query-level access control within it. A strong answer names a specific service and draws the line concretely, not just recites the model abstractly.
Q: What's the actual difference between a security group and a NACL, and why would you use both?
A: Security groups are stateful and apply at the instance/ENI level — a rule allowing inbound traffic on a port automatically permits the return traffic, no explicit outbound rule needed. NACLs are stateless and apply at the subnet level — both directions need explicit rules. You'd use both because they provide defense in depth at different layers: NACLs as a broad, subnet-wide guardrail (useful for coarse-grained blocking, like denying a known-bad IP range across an entire subnet), security groups for fine-grained, per-resource access control. Relying on only one layer means a single misconfiguration removes your only network-level protection.
Q: How would you detect if an IAM role's credentials have been compromised?
A: Behavioral anomaly detection is the practical answer at scale — GuardDuty-style tooling flags unusual patterns: API calls from a geographic location that identity has never operated from, a sudden shift in the type of API calls (a role that normally only reads objects suddenly calling IAM enumeration APIs, a common reconnaissance pattern), or activity immediately following a suspicious authentication event. CloudTrail provides the underlying audit log to investigate once something's flagged — the combination of automated anomaly detection plus a fast manual investigation process is what actually catches compromise in practice, not either alone.
Q: A security scanner flags dozens of CSPM findings in an environment you've just inherited — how do you prioritize?
A: Triage by actual risk, not by raw finding count — internet-facing findings touching sensitive data get remediated immediately, treated as an active risk rather than a backlog item; internal-only or low-sensitivity findings get a defined SLA rather than urgent treatment. Without an explicit framework like this, teams commonly either panic-fix everything at once (disruptive, and low-value findings get equal urgent attention as critical ones) or, more commonly, get overwhelmed and start ignoring the tool's output entirely — a working triage process is what prevents both failure modes.
Q: What is SSRF, and why is it specifically dangerous in a cloud environment?
A: Server-Side Request Forgery is a vulnerability where an attacker tricks a server into making an HTTP request to a destination the attacker controls (fully) or influences (partially) — dangerous generally because it can be used to reach internal-only resources the attacker couldn't reach directly. In a cloud environment specifically, it's especially consequential because cloud instances expose an internal metadata service that provides IAM credentials for the instance's role — an SSRF vulnerability can be used to request that metadata endpoint and exfiltrate those credentials, turning a web application vulnerability into cloud infrastructure credential theft. IMDSv2's token requirement (see Intermediate) specifically breaks the common exploitation path for this.
Q: How do you approach compliance (SOC2, PCI-DSS, etc.) as an ongoing engineering concern rather than a one-time audit?
A: Treat compliance controls as continuously-verified, automated checks — much of this overlaps directly with CSPM findings and monitoring you'd want regardless of a specific compliance framework — rather than a periodic manual audit that can silently drift out of compliance the day after it's checked. This also means building evidence collection into the infrastructure itself (logs, configuration history proving a control was actually enforced over time), not reconstructing it manually when an auditor asks, which is both more reliable and dramatically less painful at audit time.
Q: What's your actual first move if you discover a leaked, valid IAM access key in a public GitHub repository right now?
A: Revoke/deactivate the key immediately — before investigating scope, before figuring out how it leaked. Containing ongoing potential access takes priority over understanding the full picture, since every minute the key remains active is continued exposure. After revocation: investigate what that key's role actually accessed via CloudTrail history, and only then address root cause (removing it from the repo's history, which itself requires care since git history rewriting has its own considerations, and reviewing why a long-lived key existed in code in the first place rather than a role-based credential).