All jobs / Solutions / cloud architect

Networking interview questions

Networking questions a Solutions / cloud architect can be asked, from first job to senior. Open one to see the strongest answer and why it works.

  1. What does a load balancer do, and what does it not do?

    The strongest answer: Spreads requests across healthy instances and drops unhealthy ones from rotation; it does not make a slow service fast or a stateful one safe to scale

    Why it works: Exactly. Distribution and health checks. It hides instance failure, not design failure.

    • Distributes across healthy instances.
    • Health checks remove the sick ones.
    • Does not fix slow code or shared state.
    • Not an availability guarantee on its own.

  2. What actually makes a subnet “public” in a cloud network, and what does a route table do?

    The strongest answer: A route table maps destination ranges to next hops; a subnet is public when its route table sends internet-bound traffic to the internet gateway and its instances have public addresses

    Why it works: Exactly — “public” is a property of routing plus addressing, not a label on the subnet.

    • Routing plus addressing makes it public.
    • Route table: destination to next hop.
    • Internet gateway route means public.
    • No route, no reachability.

  3. What problem does a CDN solve, and what does it not solve?

    The strongest answer: Serves static and cacheable content from locations near the user, cutting latency and origin load; it does nothing for personalised responses that cannot be cached

    Why it works: Exactly. Distance and origin load for cacheable content. Dynamic, per-user responses still travel to the origin.

    • Cacheable content, near the user.
    • Less latency and less origin load.
    • Nothing for per-user responses.
    • Not a security or backend substitute.

  4. You are designing the address space for a company’s first cloud networks. What do you decide up front?

    The strongest answer: Non-overlapping private ranges for every network, environment and the on-premises estate, room to grow, subnets split per zone and tier, and a recorded allocation plan

    Why it works: Right — overlapping ranges cannot be peered or routed later, and re-addressing a live network is a painful project.

    • Non-overlapping, generous, recorded.
    • One range per network and environment.
    • Include the on-premises ranges.
    • Subnets per zone and tier.

  5. Services inside the private network need to find the database and each other by name. How do you set up DNS for that?

    The strongest answer: A private DNS zone attached to the network, with records for internal endpoints that are not resolvable from the internet, sensible TTLs, and the same names in every environment so configuration does not change

    Why it works: Exactly — private zones keep internal names internal and let you move endpoints without touching configuration.

    • Private zone for private names.
    • Not resolvable from the internet.
    • Same names in every environment.
    • TTLs that allow failover.

  6. Layer 4 or layer 7 load balancer — how do you choose?

    The strongest answer: Layer 7 when you route on host, path or headers, terminate TLS or need HTTP-aware health checks; layer 4 for non-HTTP protocols, very high throughput, or when the connection must pass through untouched

    Why it works: Right — the choice follows what the balancer must understand about the traffic.

    • Route on what you must read.
    • L7: host, path, headers, TLS.
    • L4: any protocol, raw throughput.
    • Health checks follow the layer.

  7. Engineers need to reach private databases and admin consoles from home. VPN, bastion host or something else?

    The strongest answer: An identity-aware access layer: SSO with MFA, authorisation per resource, short-lived sessions and logging — a client VPN tied to the same identity is acceptable, a shared bastion key is not

    Why it works: Exactly — access is granted to a person for a resource, logged, and expires; network position alone grants nothing.

    • Access per person, per resource.
    • SSO and MFA in front.
    • Short sessions, full logging.
    • No shared keys, no open ports.

  8. A partner’s platform must call your API and you must call theirs, with no traffic over the public internet. What are the options?

    The strongest answer: Each side exposes its API as a private endpoint service the other consumes into its own network — no peering, no shared address space — or a site-to-site VPN where private endpoints are unavailable

    Why it works: Right — private endpoints expose one service point-to-point without joining the networks.

    • Expose one service, not a network.
    • Private endpoint service per API.
    • VPN if endpoints are unavailable.
    • Peering is too broad here.

  9. Your public API is read-heavy and used worldwide. What can a CDN do for it, and what must never be cached?

    The strongest answer: Cache public GET responses by URL with explicit cache headers, terminate TLS near users, absorb bursts and shield the origin; never cache per-user responses unless the cache key includes the identity, and never cache writes

    Why it works: Exactly — the CDN helps the public read path, and the cache key must include everything that changes the response.

    • Cache the public read path.
    • Explicit headers; key includes what varies.
    • Never per-user data by URL.
    • Writes go to the origin.

  10. Thirty networks across teams and environments must reach shared services and the on-premises estate. Peer them all, or something else?

    The strongest answer: A hub-and-spoke topology: spokes attach to a central transit hub that carries the on-premises link, shared services and central egress, with routing controlled centrally — peering is not transitive and a mesh does not scale

    Why it works: Right — the hub centralises routing, connectivity and inspection while keeping the spokes isolated.

    • Hub carries shared, spokes stay isolated.
    • Transit hub, not a mesh.
    • Central egress and inspection.
    • Peering is not transitive.

  11. In a previous incident a compromised container pulled a payload from an unknown host and nobody noticed for a week.

    Security requires that production workloads reach only approved external destinations. How do you design outbound control?

    The strongest answer: Route all egress through a central firewall or proxy that allows by domain and logs every connection, use private endpoints so cloud services never leave the network, and manage the allow-list as code with an owner

    Why it works: Exactly — domain-level egress control with logging is how you contain exfiltration and pulled payloads.

    • Central egress, allow by domain.
    • Log every outbound connection.
    • Private endpoints for cloud services.
    • Allow-list as code, with an owner.