Computer science concepts

Cloud Networking, CIDR, And Secure Infrastructure

Candidates must demonstrate practical cloud networking and CIDR fundamentals plus secure system design judgment: how to partition IP space, enforce…

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 $2^{32-p}$ . A /24 = 256 addresses, usable hosts often $2^{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.