📁 Sangam Dhakal - Portfolio v2.0 - Netscape Navigator 4.0
_
□
×

πŸ“š Interview question

Design the network path for a public .NET API on a cloud platform: from the user's browser to the database. Which components do you put in the path (DNS, CDN/WAF, load balancers, proxies, firewalls, private networking), and what does each one do?

An end-to-end cloud network design for a public API: global entry, TLS, WAF, L7 routing, private subnets, egress control, private endpoints, and how each choice affects security, latency and operations.

Staff / Architect SystemDesign Expert architecture cloud firewall load-balancer networking system-design tls

🎯 Key points

  • DNS with a sensible TTL, CAA records and DNSSEC where supported points the public name at a global edge
  • Global edge (CDN + WAF + DDoS protection) terminates TLS near users, caches safe responses and filters attacks and abusive rates
  • Lock the origin to the edge (private link, service tags or IP ranges plus an edge ID header) so the WAF cannot be bypassed
  • Regional L7 gateway or ingress handles routing, re-encrypted TLS, health probes, draining, body limits and timeouts that shrink from the edge inwards
  • App tier runs in private subnets with no public IPs, default-deny NSGs or security groups, Kubernetes NetworkPolicies and workload identity
  • Data services are reached through private endpoints and private DNS zones with public network access disabled
  • Egress goes through a NAT gateway or firewall with an FQDN allow-list, static outbound IPs and enough SNAT ports
  • Observability across every hop (edge and WAF logs, flow logs, OpenTelemetry traces with traceparent into Application Insights or another backend) and everything defined as code with policy checks

⏱ 30-second answer

Layered from outside in:

  1. DNS with low TTL for the public name.
  2. Global edge / CDN + WAF (Front Door, CloudFront + AWS WAF, Cloudflare): anycast entry, TLS termination close to users, caching, DDoS and OWASP rules, rate limiting.
  3. Regional L7 gateway / ingress (App Gateway, ALB, ingress controller): routing, re-encrypted TLS, health probes; only accepts traffic from the edge.
  4. App tier in private subnets (AKS/ECS/App Service with VNet integration): no public IPs, NSGs/security groups and NetworkPolicies limit east-west traffic.
  5. Data tier via private endpoints (SQL, storage, Key Vault) with private DNS zones; public access disabled.
  6. Controlled egress through a NAT gateway or firewall with allow-lists.

Plus observability at every hop (flow logs, edge logs, traces with traceparent), and automated certificates and network rules as code.

πŸ—£ Full answer (senior)

Reference design

User ──DNS (api.example.com, CNAME β†’ edge)──►
  Global edge: CDN + WAF + DDoS protection, TLS 1.3 at the edge, cache static/GETs
        β”‚  TLS (re-encrypted), origin locked to edge only (private link or header + IP allow-list)
        β–Ό
  Region A                                            Region B (active/active or warm standby)
  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€ VNet / VPC ───────────────────┐
  β”‚ public subnet:  L7 gateway / ingress (only edge IPs allowed) β”‚
  β”‚                     β”‚                                       β”‚
  β”‚ private subnet: AKS / ECS pods (no public IPs)              β”‚
  β”‚   NetworkPolicy: ingress only from gateway; egress allow-listβ”‚
  β”‚                     β”‚                                       β”‚
  β”‚ data subnet:    private endpoints ──► SQL, Redis, Storage,  β”‚
  β”‚                 Key Vault (public access disabled)          β”‚
  β”‚                                                             β”‚
  β”‚ egress: NAT gateway or firewall (FQDN allow-list, logging)  β”‚
  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

What each component contributes

Component Security Performance Reliability
Edge/CDN + WAF DDoS absorption, OWASP rules, bot and rate limits TLS and caching near users, connection reuse to origin Health-based failover between regions
L7 gateway / ingress Only edge can reach it; mTLS optional HTTP/2 to backends, compression Health probes, draining
Private app subnets No direct internet exposure; least-privilege rules Low intra-region latency Zone-redundant node pools
Private endpoints Data never on public internet; public access off Same-region placement Zone-redundant data services
Egress firewall/NAT Blocks exfiltration, audited allow-list Watch SNAT port limits Static outbound IPs for partner allow-lists

Key decisions and trade-offs

  • Where TLS terminates: at the edge for speed, re-encrypt to origin for zero trust; certificates automated at each hop.
  • Origin lockdown: otherwise attackers bypass the WAF by hitting the gateway directly.
  • Active/active vs active/passive: cost and data replication complexity vs recovery time.
  • Mesh or not: mTLS and L7 balancing between services vs operational overhead.
  • Client IP propagation: configure X-Forwarded-For trust for edge and gateway hops.

Production example

A retailer exposed an AKS ingress publicly with a WAF policy on a CDN in front. A penetration test found the ingress public IP directly and bypassed the WAF. We put the gateway behind private link from the edge (and as a fallback, an IP allow-list for the edge's service tag plus a secret header check), removed public IPs from nodes, moved SQL and storage to private endpoints, and routed egress through a firewall with an FQDN allow-list. A later credential-stuffing attack was absorbed by WAF rate limits without touching the app.

πŸ” What the interviewer is checking

A staff-level design question that ties the networking topics together. The interviewer wants to see the candidate make and justify trade-offs between security, latency, cost and operability, not just list cloud products.

Green flags

  • Layers the path logically (DNS, edge, gateway, private app, private data, egress) and gives a reason for each hop.
  • Explains origin lockdown, private endpoints and private DNS.
  • Talks about where TLS terminates, timeouts per hop, health checks, failover and observability (traces across hops).
  • States trade-offs such as active/active versus active/passive and mesh versus no mesh, and maps the design to the cloud the team uses.
  • Mentions infrastructure as code and policy enforcement.

Red flags

  • A public load balancer straight to VMs with public IPs.
  • No thought about egress, certificates, private DNS or origin bypass.
  • Lists products without explaining what each protects against.

πŸ“š Learn in depth

1. Design walk-through, outside in

DNS: api.example.com CNAME to the edge endpoint; TTL 300 s; DNSSEC where supported; CAA records restricting which CAs can issue certificates.

Edge: anycast IPs terminate TLS close to users (saving round trips: Sydney users do not pay the handshake to a US origin). Cache what is cacheable (Cache-Control from the app). WAF managed rule sets plus custom rate limits by IP and by API key. Health probes per origin for failover.

Origin protection: private link from edge to regional gateway when available; otherwise restrict to the edge's published IP ranges or service tags and validate an edge-injected header or ID.

Regional gateway/ingress: path and host routing, request size limits, timeouts aligned with the app, HTTP/2 to backends, session affinity off by default.

App tier: private subnets, no public IPs, NSGs/security groups default-deny, Kubernetes NetworkPolicies (ingress from gateway namespace only; egress to DNS, data subnet and egress gateway), workload identity for credentials.

Data tier: private endpoints + private DNS zones linked to the VNet; public network access disabled; separate subnet with its own rules.

Egress: NAT gateway for predictable outbound IPs (partners can allow-list them) and enough SNAT ports; or a firewall with FQDN rules and logging for exfiltration control.

2. Latency budget example (user in Perth, origin in Sydney)

without edge: DNS 20 + TCP 50 + TLS 50 + request 50 + app 30      β‰ˆ 200 ms cold
with edge:    DNS 20 + TCP 5  + TLS 5  + edgeβ†’origin (warm) 50 + app 30 β‰ˆ 110 ms cold

3. Failure modes to design for

Failure Mitigation
Region outage Edge health probes fail over to region B; data replication strategy decides RPO
WAF false positives Detection mode first, per-rule exclusions, logs to SIEM
Certificate expiry at any hop Automated renewal; expiry alerts per hop
SNAT exhaustion NAT gateway with enough IPs; connection reuse
Private DNS misconfiguration IaC for zones and links; startup checks resolve to private IPs
Bypass of the edge Origin lockdown and regular external scans

4. Observability

  • Edge and WAF logs (blocked requests, cache hit ratio), gateway access logs, NSG/VPC flow logs, firewall logs.
  • Propagate traceparent through all hops; correlate edge request IDs with app traces.
  • Synthetic checks from several regions through the full path.

5. Everything as code

Terraform/Bicep for VNets, rules, private endpoints and DNS; Helm/Kustomize for NetworkPolicies and ingress; policy-as-code (Azure Policy, OPA) to forbid public IPs on data services.

6. Try it yourself

Sketch this design for one of your services. For each hop, write down: who terminates TLS, which IPs may connect, the timeout, the health check and where its logs go. Then try to reach the origin directly from the internet and confirm it is blocked.

πŸ’» Code

// App-side pieces of the design
var builder = WebApplication.CreateBuilder(args);

// Trust edge + gateway hops for client IP and scheme
builder.Services.Configure<ForwardedHeadersOptions>(o =>
{
    o.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
    o.ForwardLimit = 2;
    o.KnownProxies.Clear();
    o.KnownProxies.Add(IPAddress.Parse("10.10.1.10")); // regional gateway private IP
});

// Reject requests that did not come through the edge (defence in depth behind IP restrictions)
var expectedEdgeId = builder.Configuration["Edge:Id"]!;

var app = builder.Build();
app.UseForwardedHeaders();
app.Use(async (ctx, next) =>
{
    if (ctx.Request.Path.StartsWithSegments("/health")) { await next(); return; }
    if (ctx.Request.Headers["X-Azure-FDID"] != expectedEdgeId)   // Front Door ID header
    {
        ctx.Response.StatusCode = StatusCodes.Status403Forbidden;
        return;
    }
    await next();
});

// Cache headers the edge can honour
app.MapGet("/catalogue/{id}", (int id) => Results.Ok(GetItem(id)))
   .CacheOutput(p => p.Expire(TimeSpan.FromMinutes(5)));

app.Run();
# Terraform sketch: SQL reachable only through a private endpoint
resource "azurerm_mssql_server" "orders" {
  name                          = "sql-orders-prod"
  public_network_access_enabled = false
  # ...
}

resource "azurerm_private_endpoint" "orders_sql" {
  name      = "pe-sql-orders"
  subnet_id = azurerm_subnet.data.id
  private_service_connection {
    name                           = "sql"
    private_connection_resource_id = azurerm_mssql_server.orders.id
    subresource_names              = ["sqlServer"]
    is_manual_connection           = false
  }
  private_dns_zone_group {
    name                 = "sql"
    private_dns_zone_ids = [azurerm_private_dns_zone.sql.id]
  }
}

⚠ Common mistakes

  • Mistake: Putting a WAF or CDN in front but leaving the origin publicly reachable. Why it is wrong: Attackers find the origin IP (certificate transparency logs, scans, old DNS records) and bypass every edge control, including rate limits. Instead: Lock the origin to the edge with private link, service-tag or IP restrictions and an edge ID header check, and scan regularly from outside to prove it.

  • Mistake: Giving app nodes or databases public IPs "for convenience". Why it is wrong: It widens the attack surface, and one wrong firewall rule exposes data directly to the internet. Instead: Use private subnets, private endpoints with public access disabled, and a bastion, VPN or just-in-time access for administration.

  • Mistake: Ignoring egress. Why it is wrong: Unrestricted outbound access makes data exfiltration and supply-chain callbacks easy, and default outbound SNAT ports run out under load, causing intermittent connection failures. Instead: Route egress through a NAT gateway or firewall with an allow-list, logging and enough outbound IPs, and reuse connections with a shared HttpClient from IHttpClientFactory.

  • Mistake: Designing the path without timeouts and limits per hop. Why it is wrong: If an inner hop waits longer than an outer one, the outer hop gives up first, returns 504 and the client retries while the original request still runs, which amplifies load. Instead: Make timeouts shrink from the edge inwards and align request body size limits at every hop.

  • Mistake: Forgetting private DNS when adding private endpoints. Why it is wrong: The app still resolves the public name to the public IP, so connections fail once public access is disabled, or quietly go over the internet while it is enabled. Instead: Link private DNS zones to the VNet in infrastructure as code and check at startup that data hosts resolve to private addresses.

  • Mistake: Building it by hand in the portal. Why it is wrong: Undocumented rules drift between environments and cause outages nobody can explain. Instead: Define networks, rules, DNS and certificates in Terraform or Bicep, deploy them through a pipeline with review, and enforce guardrails with Azure Policy or OPA.

πŸ› Senior insight: trade-offs

At staff level the question is about defence in depth with clear trust boundaries and the operational cost of each layer. Every hop needs a reason: the edge for latency, DDoS protection and the WAF; the gateway for routing and origin protection; private networking so data is never exposed; egress control so a compromise is contained. Each hop also adds certificates, timeouts, logs and failure modes, so I keep the number of hops deliberate and documented.

The same design on each major cloud

Layer Azure AWS Google Cloud
Global edge + WAF Front Door Premium with WAF CloudFront + AWS WAF + Shield Cloud CDN + global external Application Load Balancer + Cloud Armor
Origin lockdown Private link from Front Door, X-Azure-FDID check CloudFront VPC origins or managed prefix list + custom header Cloud Armor policy, serverless NEGs or internal origins
Regional L7 Application Gateway or AKS ingress Application Load Balancer Regional Application Load Balancer or GKE Gateway
Private data access Private Endpoint + Private DNS zone PrivateLink interface endpoints + Route 53 private zones Private Service Connect + Cloud DNS private zones
Egress control NAT Gateway, Azure Firewall NAT Gateway, Network Firewall Cloud NAT, Cloud NGFW
Observability Application Insights, NSG/VNet flow logs CloudWatch, X-Ray, VPC Flow Logs Cloud Trace, Cloud Logging, VPC Flow Logs

The concepts carry across providers, but the details differ: which services support private origins, how service tags or prefix lists are published, how flow logs are priced and sampled, and how quickly global configuration changes propagate. Using OpenTelemetry in the .NET app keeps traces portable whichever backend is chosen.

Trade-offs I make explicit

Decision Option A Option B
TLS to origin Terminate at edge only (simpler, faster) Re-encrypt every hop (zero trust, more certificates)
Regions Active/active (lower RTO, harder data replication) Active/passive (cheaper, slower failover)
Service-to-service Service mesh (mTLS, L7 balancing) NetworkPolicies + app-level TLS (less to operate)
Egress Firewall with FQDN rules (control, audit) NAT gateway only (cheaper, less control)

I make the design verifiable: origin lockdown tested by external scans, synthetic probes through the full path from several regions, flow logs and edge logs correlated with traces, and policy-as-code that prevents public IPs on data services. The design is only as strong as its weakest bypass, and the most common bypass is a forgotten public endpoint.

πŸ”— Follow-ups the interviewer may ask

  1. When: Candidate mentions NSGs or security groups Why: Checks firewall details and troubleshooting
    How to answer

    A firewall allows or blocks traffic based on rules (source, destination, port, protocol, and for L7 firewalls/WAFs, HTTP content).

    • Stateful firewalls (Azure NSGs, AWS security groups, most host firewalls) track connections, so return traffic is automatically allowed. Stateless filters (AWS NACLs) need rules both ways.
    • Layers: host firewall (iptables/nftables, Windows Defender Firewall), cloud NSG/security group, network appliances, Kubernetes NetworkPolicy, and WAF at the edge.

    Troubleshoot by symptom: timeout usually means dropped by a firewall or routing, refused means reached the host but nothing listening, reset after idle often means a firewall or load balancer idle timeout removed the connection state. Test from the source (nc -vz, Test-NetConnection), check rules and flow logs in both directions, and set TCP keep-alives or shorter pool idle timeouts below the firewall's idle timeout.

  2. When: Candidate mentions the regional gateway Why: Probes load balancer behaviour
    How to answer

    A load balancer spreads traffic across healthy instances.

    • Layer 4 (TCP/UDP: Azure Load Balancer, AWS NLB, Kubernetes Services via kube-proxy) picks a backend per connection using IPs and ports. Fast, protocol-agnostic, no HTTP awareness.
    • Layer 7 (HTTP: App Gateway, ALB, Front Door, ingress controllers, Envoy, YARP) picks per request, can route by path/host/header, terminate TLS, retry and add headers.

    Health checks remove unhealthy instances (in Kubernetes: readiness for traffic, liveness for restarts). Algorithms: round robin, least connections/requests, hashing. Sticky sessions pin a user to one instance, which hurts scaling and failover. Connection draining stops new traffic to an instance before shutdown so in-flight requests finish.

    gRPC uses long-lived HTTP/2 connections, so an L4 balancer balances connections, not calls: one client connection carries all its calls to one pod. Use L7 balancing (mesh/Envoy) or client-side load balancing.

  3. When: Candidate mentions TLS termination points Why: Checks TLS depth
    How to answer

    HTTPS is HTTP inside TLS. TLS gives confidentiality (encryption), integrity (tamper detection) and server authentication (certificates).

    TLS 1.3 handshake (one round trip): the client sends supported ciphers, a key share, SNI (hostname) and ALPN (h2); the server replies with its key share, certificate chain and a signature proving it owns the private key. Both derive session keys via ECDHE (forward secrecy).

    The client validates: chain to a trusted root, not expired, hostname matches the SAN, and optionally revocation.

    For "remote certificate is invalid": read the SslPolicyErrors / chain status, inspect with openssl s_client -showcerts, then fix the real cause (expired cert, missing intermediate, wrong hostname, or a private/corporate root CA not trusted in the container). Never return true from ServerCertificateCustomValidationCallback in production.

πŸ›  Real-world problems: how you handle them

WAF bypass through a publicly reachable ingress
Situation
[Retail API] on .NET [10] in [AKS] with a CDN + WAF in front; the ingress controller still had a public IP.
Signals
Penetration test reached the API directly on the ingress IP, bypassing WAF rules and rate limits.
Investigation
External scan confirmed the ingress answered on 443 from the internet; NSG allowed `Internet` to the ingress subnet.
Resolution
Connected edge to the gateway via private link, removed public IPs, restricted NSG to the edge service tag as a fallback, added an edge ID header check, and moved SQL/storage to private endpoints with egress through a firewall.
Prevention
Policy-as-code denying public IPs except on the edge, monthly external attack-surface scans, synthetic tests that confirm direct origin access is blocked.

How to tell it (STAR)

**S:** A [penetration test] showed our [retail API] could be reached directly, skipping the WAF we relied on. **T:** As the lead for the platform, I had to close the gap and harden the rest of the path. **A:** I locked the origin to the edge with private link and header checks, removed public IPs, moved data services to private endpoints and put egress behind a firewall, all in Terraform with policies to prevent regressions. **R:** The retest found no direct path, and a later [credential-stuffing] attack was stopped by WAF rate limits without touching the app.

↩ Usually asked after

More in Networking Basics

Last updated 23 Oct 2026.

🌐 Sangam's Webring

βͺ Previous 🏠 Main Next ⏩
πŸ’¬ Chat with me