Interview conceptSystem Design

Cloud Networking, CIDR, And Secure Infrastructure

Asked of: Software Engineer

Last updated

What's being tested

Candidates must demonstrate practical cloud networking and CIDR fundamentals plus secure system design judgment: how to partition IP space, enforce least-privilege network controls, and choose management/storage patterns that support scale, availability, and audits. Interviewers look for crisp clarifying questions, correct bitwise/prefix reasoning, and tradeoffs between cost, operational complexity, and security posture—skills a Software Engineer uses when designing services and APIs that run in a cloud VPC.

Core knowledge

  • CIDR and prefix math: number of addresses in a prefix /p is 232p2^{32-p}. A /24 = 256 addresses, usable hosts often 232p22^{32-p}-2 but cloud providers may reserve additional addresses.

  • VPC and subnet semantics: a VPC is an L3 container; subnets map to AZs. Plan subnets per AZ to enable high availability and failure-domain isolation.

  • Security group vs NACL: security groups are stateful (return traffic allowed automatically), NACLs are stateless and evaluate per-packet; both use allow/deny but precedence and order differ.

  • Route table basics: longest-prefix match decides next hop; default routes (0.0.0.0/0) send to IGW/NAT. Multiple route tables let you split traffic control per subnet.

  • IP address management (IPAM): avoid fragmentation by allocating in powers-of-two blocks; reserve hot pools for growth and ephemeral needs (autoscaling, CI runners).

  • NAT design and egress: NAT gateway (managed, scalable, cost-per-hour) vs instance NAT (cheaper at low scale, operational overhead); consider bandwidth and single-point-of-failure.

  • Perimeter and L7 controls: use ALB/NLB, WAF, and ingress controllers for public endpoints; terminate TLS at the edge or via a service mesh depending on threat model.

  • Storage tradeoffs: EBS for single-instance block storage, EFS for POSIX shared mounts, S3 for object storage and high-throughput read-heavy workloads; choose encryption-at-rest and lifecycle policies.

  • Identity & access: use IAM roles for service principals, SAML SSO for human access, and role assumption for cross-account access; avoid long-lived credentials and prefer short-lived tokens.

  • Observability & auditing: enable VPC Flow Logs, centralized logging (CloudWatch/ELK) and config auditing. Log retention and indexing affect cost—prioritize for critical flows.

  • Encryption & networking: apply TLS end-to-end for public and internal traffic if the threat model requires, and consider mTLS for service-to-service authentication in zero-trust designs.

  • IPv6 considerations: IPv6 removes address exhaustion but changes NAT assumptions; plan dual-stack if external client reachability or privacy requirements demand it.

Tip: sketch a small CIDR map on the whiteboard early — it shows you understand constraints and avoids later rework.

Worked example: Design secure multi-tier cloud infrastructure

First 30 seconds: ask clarifying questions — expected scale (RPS, number of hosts), compliance/regulatory constraints, public vs private endpoints, DR / RTO targets, and whether multi-account tenancy is required. Skeleton: (1) Network segmentation: public subnets for load balancers, private app subnets, isolated DB subnets; subnets per AZ for HA. (2) Perimeter & L7 controls: place an ALB/NLB in public subnets, terminate TLS with a certificate manager, add a WAF for OWASP class protections. (3) Access rules and identity: use security groups for instance-level access, NACLs for coarse-layer filtering, IAM roles for services and SAML SSO for users. (4) Management & observability: enable VPC Flow Logs, centralized metrics, and patching via Systems Manager. One tradeoff to flag: NAT gateway cost versus instance NAT — NAT gateway simplifies operations and scales, but at high egress volume instance NAT with autoscaling or using egress proxies may be cheaper. Close by outlining rollout: prototype with IaC (Terraform/CloudFormation), run security tests, and iterate on CIDR sizes and monitoring; note you'd also design automated incident playbooks and periodic access reviews if given more time.

A second angle: Evaluate IP Access Rules

This framing focuses on bitwise and precedence logic. Start by formalizing rule semantics: each rule is (action, direction, CIDR, port/proto), and evaluation must handle overlapping CIDRs and precedence. Algorithmically, use a longest-prefix match (LPM) trie for fast lookup; worst-case lookup is proportional to address bit-length (32 for IPv4). Be explicit about tie-breaking: most systems apply the most-specific (longest) prefix first; if equal prefix-lengths exist, either first-match or explicit priority decides allow/deny. For correctness, test edge cases: /32 exact matches, 0.0.0.0/0 fallback, and combined allow/deny conflicts. Implement unit tests that exercise overlapping prefixes and rule reordering to ensure deterministic behavior.

Common pitfalls

Pitfall: Wrong CIDR sizing — Candidates often pick a tight subnet (/28 etc.) without growth headroom, forcing disruptive re-IP later. Always reserve growth pools and show how you'd expand or use NAT-ing patterns to defer readdressing.

Pitfall: Confusing security groups with NACLs — A common mistake is expecting NACL statefulness; call out stateful security groups for service-level allow rules and NACLs for stateless, coarse network filters.

Pitfall: Overprivileged identities — granting blanket * IAM permissions or sharing long-lived keys looks efficient but fails audits; prefer role assumption, least privilege, and short-lived credentials, and describe proof of rotation and audit hooks.

Connections

Interviewers may pivot to related topics like service-to-service auth (mTLS, token exchange), load balancing/health checks, kubernetes network policies, or IPAM tooling and automation (Terraform, AWS IPAM). Being able to map your VPC design to containerized deployments and service meshes is valuable.

Further reading

Practice questions

Related concepts

Cloud Networking, CIDR, And Secure Infrastructure — Tech Interview Concept | PracHub