Cloud Networking & Security — Interview Q&A
Q: Explain the difference between a Security Group and a Network ACL, and when you'd specifically reach for a NACL instead of just using Security Groups.
A: Security Groups are stateful and scoped per instance — allowing inbound traffic on a port automatically allows the corresponding return traffic, no separate outbound rule needed. NACLs are stateless and scoped per subnet — you have to explicitly allow both directions, and rules are evaluated in numbered order with first-match-wins, unlike Security Groups where all matching allow rules apply. In practice, Security Groups handle the vast majority of real access control because they're simpler and stateful; NACLs are worth reaching for specifically when you need an explicit subnet-wide deny (blocking a known-bad IP range at the subnet boundary, for instance) that would be harder to express and maintain correctly as a Security Group rule on every individual instance in that subnet.
Q: Why would you use a VPC Endpoint instead of just routing traffic to AWS services through a NAT Gateway?
A: Two distinct reasons. Cost: NAT Gateway charges per-GB of data processed, and traffic to AWS's own services routed through it unnecessarily is a common, avoidable cost — a VPC Endpoint routes that same traffic privately, at little to no cost for gateway-type endpoints like S3/DynamoDB. Security: a private subnet with VPC Endpoints for everything it needs and no NAT Gateway at all has literally no path to the public internet, which is a meaningfully stronger isolation guarantee than "outbound-only via NAT" for workloads that only need to reach AWS's own services and nothing external.
Q: A private-subnet resource has a Security Group correctly allowing HTTPS, but a request is still failing. What's your troubleshooting order?
A: Route table first — confirm an actual route to the destination exists, since a missing route produces the same visible symptom as a blocked port. Then NACLs — since they're stateless, confirm both directions are explicitly allowed, not just inbound. Then the Security Group itself — confirm the actual rule scope and source match what's expected. Then, if all of that looks correct, the resource's own OS-level firewall (iptables, Windows Firewall), which a cloud-level Security Group has no visibility into or control over. Jumping straight to "the Security Group must be misconfigured" skips three other equally common causes.
Q: Why isn't a private network boundary considered sufficient protection on its own, without also enforcing TLS internally?
A: Network segmentation controls who can reach a service; TLS protects the data itself even if that segmentation is ever bypassed or misconfigured — a compromised internal host, a routing misconfiguration, or a misapplied Security Group rule can all expose "internal" traffic in ways a purely network-based trust model doesn't defend against. The two controls are complementary, not substitutes — skipping TLS because traffic is "internal" removes a real defense-in-depth layer for a threat model (compromised internal host, internal misconfiguration) that's more realistic than it might initially seem, and is exactly the kind of assumption Zero Trust's "assume breach" principle is designed to push back against.
Q: How does network segmentation actually affect PCI-DSS compliance scope, concretely?
A: Any system that can communicate with the cardholder-data environment is considered in scope for the compliance audit, regardless of whether it directly touches card data — so poor segmentation, where the CDE is reachable from broad swaths of general application infrastructure, pulls all of that infrastructure into audit scope with real cost and operational overhead. A tightly segmented CDE — its own VPC/subnet, minimal explicit Security Group rules, dedicated logging — keeps the audit boundary as small as the actual card-data-handling components, which is simultaneously a genuine security improvement and a direct, measurable way to reduce audit cost and scope.
Q: What's the difference between L3/L4 and L7 DDoS protection, and why do you need both?
A: L3/L4 protection (AWS Shield Standard, Azure DDoS Protection) defends against volumetric floods — SYN floods, UDP reflection attacks — largely automatically, by absorbing and filtering at the network edge. L7 attacks are a flood of individually legitimate-looking HTTP requests designed to exhaust application resources rather than network bandwidth, and L3/L4 protection genuinely cannot distinguish that traffic from real user traffic — it requires a separately configured WAF rate-limiting layer. A common real gap is enabling basic DDoS protection and considering the topic closed, without realizing it doesn't cover this entire attack category.
Q: Walk through why DNS resolution can fail across a working VPC peering connection.
A: VPC Peering enables network-layer connectivity (routing, and whatever Security Groups allow) but does not automatically enable DNS resolution across the peered VPCs — that's a separate, explicit setting (AllowDnsResolutionFromRemoteVpc) that has to be enabled on both sides of the connection. This causes a specific, confusing failure pattern: connectivity tests by raw IP address work fine, since routing is genuinely correct, while DNS-based resolution of resources in the peered VPC silently fails — easy to miss if testing only confirmed IP-level connectivity without separately testing DNS resolution.