Network Security Architecture Questions

Fundamentals and design of network security including the Transmission Control Protocol and Internet Protocol stack, Domain Name System, Hypertext Transfer Protocol and Hypertext Transfer Protocol Secure, and common network protocols and services that impact security. Covers core network security controls such as firewalls, intrusion detection system and intrusion prevention system, network segmentation, virtual local area network design, access control lists, network access control and micro segmentation, secure tunneling and Virtual Private Networks, and secure protocol configuration such as Transport Layer Security and Internet Protocol Security. Includes threat models for network based attacks including man in the middle attacks, Domain Name System poisoning, reconnaissance, lateral movement across network boundaries, and distributed denial of service, along with detection, monitoring, logging, and incident response practices. Also covers architecture level patterns such as segmentation and zero trust networking, secure deployment of network appliances, and trade offs between performance and security.

MediumTechnical

35 practiced

Explain Resource Public Key Infrastructure (RPKI) and how BGP Route Origin Validation (ROV) helps prevent prefix hijacks. Describe deployment steps for enabling ROV on an enterprise edge router, common operational pitfalls (e.g., ROA misconfigurations), and recommended fallback behaviors when RPKI states are invalid or unknown.

HardSystem Design

35 practiced

Design a zero-trust network architecture for a global enterprise with on-prem data centers and multi-cloud workloads. Define the control plane, policy engine, policy enforcement points (PEPs), identity sources (human and service), certificate/key management, telemetry required for enforcement, and an incremental migration plan from a traditional perimeter model. Discuss scalability and latency trade-offs.

Sample Answer

**Overview / Goals**Design a global zero-trust architecture that verifies every request, enforces least privilege, protects workloads across on‑prem and multi‑cloud, and enables incremental migration from perimeter controls.

**Control Plane & Policy Engine**- Centralized control plane (multi‑region HA) exposing gRPC/REST APIs; backed by a distributed policy engine (e.g., Open Policy Agent Fleet) with region-local caches.- Policies expressed as intent: identity → attributes → allowed actions (L3/L7), microsegmentation rules, time/location constraints.

**Policy Enforcement Points (PEPs)**- Host-level PEPs: sidecar proxies (e.g., Envoy) for cloud VMs/containers and lightweight agents (eBPF-based) on bare‑metal.- Network PEPs: next‑gen firewalls or SD‑WAN edge devices enforcing macro policies (north-south).- Client PEPs: endpoint agents for users (TLS mutual auth) and browser plugins for web apps.

**Identity Sources**- Human: centralized IdP (OIDC/SAML) with MFA, device posture via EDR/MDM.- Service: short-lived service identities via SPIFFE/SPIRE or workload identity providers (AWS STS, Azure MSI).- Map identities → attributes (roles, teams, environment) in policy engine.

**Certificate / Key Management**- Internal PKI with automated issuance/rotation (e.g., cert-manager, Vault PKI), mutual TLS for service-to-service.- Use short-lived certs/keys (minutes to hours), hardware-backed keys for high-value systems, centralized rotation and revocation via OCSP/CRL and automated renewal.

**Telemetry for Enforcement**- Auth logs, mTLS handshake success/failure, agent heartbeats, flow logs (VPC/NSX), application request traces (distributed tracing), posture scans.- Centralized observability (ELK/Prometheus/Grafana) + SIEM for anomaly detection and automated policy adjustment.

**Incremental Migration Plan**1. Inventory and classification (criticality, trust levels).2. Start with high-risk east-west flows: deploy host agents/sidecars in dev, enforce deny-by-default microsegmentation for dev tenants.3. Extend to cloud workloads using workload identities and sidecars; integrate IdP and PKI.4. Gate user access: phase in device posture and conditional access for sensitive apps.5. Replace perimeter rules gradually; use SD‑WAN to steer traffic through inspection PEPs.6. Iterate with telemetry-driven policy tuning and automated rollback.

**Scalability & Latency Trade-offs**- Scalability: central policy cache per region reduces control plane load; use hierarchical policies to minimize rule count. eBPF/sidecars offload enforcement to hosts to scale horizontally.- Latency: mTLS and external policy lookups add hops—mitigate with local policy caches, short-circuit allow decisions, and colocated PEPs. Trade: stronger real-time checks increase latency; prefer asynchronous telemetry checks for low‑latency flows and synchronous checks for high-risk actions.

**Final Notes**Prioritize automation (CI/CD for policies), strong observability, and staged rollout with rollback gates. The network engineer role focuses on integrating PEPs into existing routing, ensuring HA for control-plane components, and tuning forwarding to minimize added latency.

MediumTechnical

40 practiced

You must restrict east-west traffic so developer workstations cannot access the production database subnet in a campus network. Outline a set of router/switch ACLs or firewall rules (include 3-5 example lines), describe where to apply them (source-side/segmentation point), and explain how to allow legitimate admin flows (backups, monitoring) without opening a broad hole.

Sample Answer

**Approach (brief)** Block east‑west traffic from developer workstations to the production DB subnet at the network segmentation point (firewall or core/router ACL). Permit only explicit, minimal admin/backup/monitoring sources and use stateful inspection, logging, and micro‑segmentation (jump hosts or bastion subnets).

**Where to apply** - Primary enforcement at the segmentation firewall or router interface on the source side (ingress from DEV VLAN/subnet). - Supplement with host-based firewall rules on DB hosts and ACLs on the DB VLAN gateway for defense‑in‑depth.

**Example ACL / firewall rules (3–5 lines)**

bash

# On perimeter router/firewall: deny dev -> db, allow specific admin/monitor IPs
access-list 100 deny ip 10.10.10.0 0.0.0.255 192.168.50.0 0.0.0.255 log
access-list 100 permit tcp host 10.0.1.5 host 192.168.50.10 eq 3306 log  # backup server -> DB
access-list 100 permit udp host 10.0.2.7 host 192.168.50.20 eq 161 log   # monitoring probe -> SNMP
access-list 100 permit tcp 192.168.50.0 0.0.0.255 any established      # allow DB responses
access-list 100 deny ip any 192.168.50.0 0.0.0.255

**Why and how to allow legitimate flows without a broad hole** - Whitelist by IP/port/protocol (least privilege). Only allow known backup and monitoring server IPs and necessary ports. - Use a dedicated bastion/jump host or service account VLAN for admins and force admin tools through it; allow only that host to reach DB. - Apply time-based rules for maintenance windows where appropriate. - Enforce encryption and authentication (IPsec, TLS) for allowed flows. - Log and monitor allowed flows; use alerts on anomalous source IPs or ports. - Complement with host-based firewall and DB access controls (service accounts, RBAC) to prevent misuse even if network rule is bypassed.

HardSystem Design

36 practiced

Design a global DDoS mitigation architecture for a SaaS provider with multi-region ingress points. Cover BGP-level mitigation (traffic steering and blackholing), use of CDN and cloud scrubbing services, regional scrubbing centers, automated traffic steering with BGP communities, and trade-offs between latency, cost, and mitigation efficacy.

Sample Answer

**Clarify requirements & constraints**- Global SaaS with multi-region ingress, SLA for <100 ms median latency, expected peak legitimate traffic 200 Gbps, must withstand multi‑hundred Gbps volumetric attacks, budget-conscious.

**High-level architecture**- Multi-region anycast ingress via POPs using CDN + provider ASNs.- Primary mitigation layers: (1) Edge CDN/WAF, (2) Cloud scrubbing providers with global backbone, (3) Regional scrubbing centers owned/leased, (4) BGP-level controls (traffic steering, blackholing).- Control plane: centralized Traffic Orchestration (TO) platform integrates telemetry (NetFlow/sFlow, BGP monitoring, CDN logs), DDoS detection, and automated BGP community signaling.

**Core components & responsibilities**- CDN/Edge (first line): absorb small-to-medium volumetrics, terminate TLS, apply WAF/L7 rules. Minimizes latency for legitimate users.- Cloud scrubbers (third-party): used when CDN capacity exceeded or for sophisticated L3/L4 attacks. Advertise victim prefixes to scrubbing backbone via BGP.- Regional scrubbing centers: colocated scrubbing appliances (on‑prem or leased) for low-latency mitigation for region-specific attacks; accept redirected traffic via BGP prepends/communities.- BGP control: Origin AS announces prefixes normally. On attack, TO signals upstreams with specific BGP communities: - Community A = steer to cloud-scrubber X (upstream advertises more-specific to scrubbing AS) - Community B = announce via regional POP (preferential AS_PATH prepends) - Community C = blackhole (discard at provider edge) — used only for clearly illegitimate targets or when preserving network stability.- Monitoring & automation: thresholds trigger automated steering but require human-in-the-loop for large decisions. Playbooks per region/type.

**Traffic flow & steering**- Normal: Anycast to nearest POP → CDN edge → origin.- If exceed CDN thresholds: TO sets BGP community to upstream to advertise more-specific routes into scrubbing provider; traffic flows into scrubbing backbone, cleaned, then forwarded to origin via GRE/IPsec or proxy.- For regional attacks: use BGP local-preference adjustments and AS_PATH prepends to steer traffic to regional scrubbing center to keep latency low.- Blackholing: use remotely-triggered blackhole (RTBH) for emergency, applied per-prefix with careful source validation.

**Trade-offs**- Latency vs Efficacy: Cloud scrubbing offers massive capacity but can add hop/processing—adds 20–80 ms. Regional scrubbing keeps latency low but limited capacity.- Cost vs Coverage: Always-on full scrubbing (clean pipe) is expensive. Hybrid: CDN + on-demand cloud scrubbing reduces cost; maintain small regional scrubbing for critical regions.- Mitigation accuracy vs Availability: Aggressive blackholing quickly protects backbone but drops legit traffic; prefer rate-limiting, flow-based filtering before blackholing.- Operational complexity: BGP community automation reduces reaction time but requires robust safeguards to avoid route flapping or misroutes.

**Operational considerations & best practices**- Test playbooks with planned drills; maintain peering relationships and signed community catalogs with providers.- Use signed BGP sessions (TTL security, MD5 or TCP-AO) and route filters to prevent hijacks.- Maintain telemetry: per-POP flow sampling, CDN logs, packet capture (ring buffer).- SLA and runbook with scrubbers: time to mitigate, chain-of-custody for forensic data.- Rollback and circuit breakers in automation to prevent cascading failures.

This design balances low-latency experience via CDN/regional scrubbing, high-capacity protection via cloud scrubbing, and fast BGP-level steering/blackholing for backbone protection—while surfacing trade-offs for cost, latency, and operational risk.

EasyTechnical

47 practiced

Explain the difference between signature-based IDS/IPS detection and anomaly-based detection. For each approach provide one core strength and one primary weakness in a production network, and describe a practical hybrid strategy that takes advantage of both approaches in a Security Operations Center.

Unlock Full Question Bank

Get access to hundreds of Network Security Architecture interview questions and detailed answers.

Join thousands of developers preparing for their dream job.