Network Segmentation and Security Architecture Questions
Design and justify network architectures that use intentional segmentation and trust boundaries to protect assets and limit lateral movement. Candidates should demonstrate understanding of segmentation strategies such as demilitarized zones for internet facing services, separation of management and production networks, separation by trust level including guest and sensitive data zones, and isolation of production from non production environments. Implementation techniques include virtual local area networks and subnet design, routing and access control lists, firewall placement and firewall rule set design for physical and virtual firewalls, host based firewalls and microsegmentation for workload isolation, secure administrative access using bastion hosts and virtual private networks, proxies and reverse proxies, and network address translation considerations. The topic covers defense in depth principles applied across network, system, application, and data layers including intrusion detection and intrusion prevention systems, web application firewalls, endpoint hardening, data encryption at rest and in transit, and data loss prevention. Candidates should be able to design interzone traffic controls and firewall rules to control traffic between segments, explain zero trust architecture principles that verify every access request, and plan logging, monitoring, alerting, and incident response to detect and contain compromises. Include cloud and on premise considerations such as security groups, network policies for container orchestration platforms, hybrid and multicloud design patterns, compliance driven segmentation requirements, and trade offs between security, availability, performance, and operational complexity.
HardSystem Design
39 practiced
Design a zero-trust administrative access architecture for a hybrid environment with multiple cloud accounts and on-prem systems. Requirements: just-in-time bastion access, federated SSO, MFA, session recording, least privilege, audit trail, and emergency break-glass. Outline the components, authentication/authorization flow, and fail-safe behaviors during identity provider outages.
Sample Answer
**Clarify requirements & constraints**- Hybrid: multiple cloud accounts + on‑prem- Must support JIT bastion access, federated SSO, MFA, session recording, least privilege, full audit trail, break‑glass- High availability and resilient during IdP outages**High‑level components**- Identity plane: Enterprise IdP (SAML/OIDC) with SCIM; secondary IdP (warm standby) and hardware token authority- Policy & Access Control: Central Policy Decision Point (PDP) / Policy Enforcement Points (PEP) using ABAC/RBAC + time/just‑in‑role rules- Secrets & Credential Vault: ephemeral credential broker (HashiCorp Vault or cloud native) issuing short‑lived keys- Just‑in‑Time Bastion Service: orchestrator that provisions ephemeral bastion instances/containers per session (cloud/on‑prem)- Session Proxy & Recorder: proxy (ssh/rdp/web) that records keystrokes/video and streams to immutable audit store- PAM/Privileged Elevation: approval workflows, step‑up MFA, approval tokens- Observability & Audit: SIEM, WORM audit store, tamper‑evident logs, UEBA- Break‑glass controls: sealed offline credentials, hardware tokens, emergency bastion with reduced privileges but full recording- Orchestration & Automation: IaC templates and autoscaling for availability**Authentication & Authorization flow**1. User authenticates to IdP (federated SSO) with primary MFA (TOTP/Push + device posture attestation). IdP issues short TTL OIDC token.2. User requests access to target via Access Portal (PEP). Portal enforces device posture, risk score, location.3. Portal forwards attributes to PDP which evaluates ABAC policy (role, purpose, time window, approval required).4. If JIT approved, orchestrator calls Vault to mint ephemeral credentials for target account (e.g., cloud STS token or ephemeral local account) scoped to minimal privileges.5. Orchestrator provisions ephemeral bastion (container/VM) in target network with single session endpoint; network ACLs allow only that session.6. User connects through Session Proxy which enforces command filtering, records session, and forwards to target using ephemeral creds.7. All events (requests, approvals, credential issuance, session recording metadata) stream to SIEM and immutable audit store for compliance.**Least privilege & JIT mechanics**- Default deny; access is time‑boxed and purpose‑bound- Privilege elevation via PAM with approval and step‑up MFA; elevation ephemeral and revoked after session- Short TTL tokens (minutes to hours), automatic revocation after session termination**Session recording & monitoring**- All interactive sessions proxied through recorder (encrypted at rest). Live monitoring triggers alerts on anomalous behavior (UEBA).- Recordings and audit metadata stored in WORM storage and accessible only to auditors via controlled workflow.**Break‑glass & IdP outage fail‑safe**- Multi‑IdP design: active + warm standby; realtime user provisioning via SCIM to standby- Short cached tokens for critical automation with strict TTL and revocation hooks- Break‑glass process: - Emergency access tickets require multi‑party attestation (e.g., 2 execs), generate one‑time sealed HSM‑wrapped token stored in Vault quorum. - Hardware (FIDO2) or emergency OTP cards available in secure vault for named custodians. - Emergency bastion host can be booted by OOB orchestration (out‑of‑band network) with limited, fully audited scope and live session recording to immutable store.- During IdP outage normal SSO flows fail fast; portal rejects new approvals unless emergency mode is invoked. Emergency mode requires stronger attestation and generates ephemeral creds via HSM + quorum; every action is logged and immediately alerted.**Fail‑safe behaviors & trade‑offs**- Deny‑by‑default during partial failures reduces risk but may impact ops — mitigated by documented break‑glass with strict controls.- Short token TTL + central revocation minimizes leaked credential window.- Operational complexity: require runbooks, run regular drills, test IdP failover and break‑glass.**Operational & governance**- Periodic access reviews, automated policy tests, retention policies, and incident playbooks.- Regular audits of session recordings and automated anomaly detection.This design enforces zero‑trust principles: continuous authentication/authorization, least privilege, JIT access, full observability, and tightly controlled emergency paths that are auditable and tamper‑resistant.
MediumSystem Design
48 practiced
Design a segmentation architecture for a three-tier application (web, app, database) that will run across multiple datacenters with approximately 1,000 servers. Define zones, firewall placement, routing considerations, NAT usage, ways to enforce least privilege between tiers, and strategies to avoid single points of failure.
Sample Answer
**Clarify requirements & assumptions**- 3-tier app (web/app/db), ~1,000 servers across 2+ datacenters (active-active), must be secure, highly available, enforce least privilege.**High-level zones**- Per-DC: Internet DMZ (load balancers, reverse proxies), Web tier zone, App tier zone, DB zone (private), Management/Monitoring zone, Shared services (auth, secrets).- Use micro-segmentation within tiers (subnet per service or per application group).**Firewall placement**- Edge NGFWs per-DC between Internet and DMZ (stateful inspection, WAF).- Internal distributed firewalls (host-based or SDN security groups) between zones to enforce L4–L7 policies.- North-south controls at perimeter; east-west controls at hypervisor/SDN and host-level for fine-grain isolation.**Routing & NAT**- Overlay network (VXLAN) per DC for scalable L2/L3 segmentation; route between overlays via routers/ASRs.- Use route reflectors / BGP EVPN for multi-DC connectivity.- Public NAT at edge for inbound/outbound (SNAT for outbound via central egress clusters; DNAT/load‑balancer VIPs for inbound). DBs have no public NAT; access only via app tier IPs.**Least privilege enforcement**- Zero-trust: allow only explicit flows (web->app: HTTPS on specific ports; app->db: single DB port, specific app IPs).- Mutual TLS between tiers and service-to-service auth (mTLS + identity-aware proxies).- Role-based security groups, host firewall rules generated from policy engine (e.g., Calico, NSX).- Secrets in vault; DB credentials limited by role and rotated.**High availability / avoid SPOF**- Active-active across DCs with geo-load balancing (GSLB).- Redundant NGFW clusters, redundant routers, multi-AZ placement for LB and DB clusters (replication, automatic failover).- Distributed control plane for SDN; multiple NAT/egress clusters with health checks.- Regular DR runbooks, automated failover tests.**Operational controls**- Centralized logging, IDS/IPS per zone, continuous policy audit, CI/CD gating for network policy changes.This design balances secure segmentation, least privilege, and multi-DC resilience for ~1,000 servers.
MediumSystem Design
51 practiced
Design a zero-trust microsegmentation approach for internal services that uses identity-based policies and mutual TLS (mTLS). Explain how service identities are issued and rotated, how policy is authored and distributed to enforcement points, and how you maintain service discovery and performance during rolling updates.
Sample Answer
**Clarify requirements & goals**- Zero-trust internal microsegmentation using identity-based policies and mTLS between services, minimal blast radius, automated identity lifecycle, low operational/perf impact during rolling updates.**High-level architecture**- Control plane: Certificate Authority (CA) + Identity service (e.g., SPIRE/SPIRE-compatible or cloud KMS CA) + Policy engine (OPA/Gatekeeper) + Service registry.- Data plane: Sidecar proxies (Envoy) performing mTLS and policy enforcement; orchestration (K8s) for lifecycle.**Service identity issuance & rotation**- Each workload gets a short-lived X.509 SVID issued by the CA after workload attests via node/workload attestor (SPIRE) or Kubernetes mTLS bootstrap (Kubelet + CSR).- Certificates valid 5–15 minutes; agents auto-renew via control plane using authenticated attestation (mutual TLS to CA).- Revocation implicit via short lifetime; immediate revocation via CRL/OCSP or control-plane push if needed.**Policy authoring & distribution**- Policies authored in Rego (OPA) or high-level RBAC: allow {source.service, dest.service, dest.port, context (time, namespace)}.- Central policy repo + CI for review. Control plane compiles policies to enforcement primitives and pushes to sidecars via xDS API (Envoy) or sidecar config-sync.- Sidecars evaluate policies locally (deny-by-default).**Service discovery & rolling updates**- Service registry integrated with control plane (K8s endpoints + mesh control plane). Sidecars use local cache and health checks.- Rolling update strategy: pre-warm new pods, probe readiness only after mTLS cert obtained and sidecar ready; use connection draining (graceful shutdown), L7 load-balancer retries and circuit breakers to maintain availability.- Performance: TLS session resumption, keepalives, and persistent connections to reduce handshake cost; short cert lifetimes balanced against handshake overhead.**Observability & ops**- Central logging/metrics for auth failures, cert issuance, policy denials. Automated test harness for policy changes.- Periodic audits and simulated revocation drills.Trade-offs: very short certs improve security but increase CA load — mitigate with local agents and scaled CA horizontally.
MediumTechnical
47 practiced
Propose a host-based firewall policy strategy for Linux and Windows servers across different trust zones. Describe base rule templates, orchestration/management approach (e.g., IaC/CM), exception handling, logging requirements, and ways to prevent drift and enforce consistency at scale.
Sample Answer
**Goal & constraints**Protect Linux/Windows servers by zone (Trusted, DMZ, Untrusted), minimize attack surface, maintain operational availability and auditability, enable rapid scale via automation.**Base rule templates**- Default deny inbound, allow established/related. Explicit allow for management (SSH/RDP) from management zone only.- Trusted: allow app ports between app/web DB tiers; restrict admin to jump-hosts.- DMZ: only allow required public-facing ports (80/443) to web process; block lateral host-to-host except monitoring.- Untrusted: isolate, only egress allowed to update/CDN endpoints.- Outbound: whitelist critical services (NTP, DNS, package repos); log and alert unusual destinations.**Orchestration / management**- Store canonical rules as IaC (Terraform + config modules) and CM templates (Ansible/Chef/Puppet) with OS-specific manifests (iptables/nftables/ufw for Linux; Windows Defender Firewall via DSC/Group Policy/PowerShell Desired State).- Pipeline: review → test in staging VMs → sign-off → push via CI/CD. Use change requests tracked in VCS.**Exception handling**- Formal exception workflow: ticket with business justification, TTL, compensating controls, owner, and automated expiration. Exceptions deployed via scoped feature-flagged rules with short lifetimes; require periodic renewal.**Logging & monitoring**- Centralize firewall logs to SIEM (syslog/CEF). Include rule-id, zone, src/dst, process/user where available. Alert on rule hits violating baseline (new ports, high volume, repeated denies). Retain per compliance policy.**Drift prevention & consistency**- Enforce desired state with continuous compliance: periodic scans (OS-native and orchestration agents), immutable manifests, and automated remediation (remediate unless exception ticket exists). Use rule fingerprinting and policy-as-code tests (policy unit tests + integration tests).- Metrics: percent compliant, mean time to remediate drift, exception count/age. Regular audits and quarterly tabletop reviews.This strategy balances strict baseline controls, automated lifecycle, auditable exceptions, and continuous enforcement at scale.
EasyTechnical
49 practiced
Design a guest Wi-Fi zone that prevents guests from reaching internal resources while allowing internet access and limited services (for example, a print service with strict controls). Describe VLANs, DHCP, captive portal requirements, DNS restrictions, and firewall rules you'd implement.
Sample Answer
**Approach (role perspective)** As a Security Architect I design the guest zone to enforce strong network segmentation, least privilege for services, and auditable controls while preserving usability.**VLANs & IP plan**- Guest VLAN 200: 192.168.200.0/24 (DHCP scope .10–.250) — internet-only clients - Printer/service VLAN 210: 192.168.210.0/28 (static addresses for shared printers/services) - Management/internal VLANs remain isolated (no routed access from guest VLAN)**DHCP**- DHCP on edge firewall or dedicated DHCP server per VLAN. - Lease time short (4–8 hours) and option to push DNS to local DNS proxy.**Captive portal**- External captive portal with SSO/OTP option, legal banner, MAC/IP logging, rate limiting, and device-isolation toggle. Require acceptance and optional signup. Support 802.1X for corporate guests.**DNS restrictions**- Force DNS to internal DNS proxy on guest VLAN (firewall DNS redirection). - DNS proxy enforces allowlist/denylist, blocks internal domain resolution (split-horizon prevents returning internal A records). - Block DNS over HTTPS/TLS to external resolvers via SNI/port rules and TLS inspection where permitted.**Firewall rules (ordered, explicit)**1. Allow Guest VLAN → Internet (HTTP/HTTPS) via NAT, stateful, with IDS/IPS. 2. Deny Guest VLAN → any Internal VLAN subnets. (High-priority) 3. Allow Guest VLAN → Printer/service VLAN: only to specific IPs and ports (e.g., TCP 9100, IPP 631) with time-of-day restrictions and strong rate limits. 4. Allow Guest VLAN → DNS proxy (UDP/TCP 53) only. Block other DNS. 5. Allow portal authentication endpoints and captive portal IPs. 6. Log and alert on any denied-internal attempts; flow logs retained for 90+ days.**Controls & Monitoring**- NAC/device isolation, per-device firewalling, periodic vulnerability scans of shared printers, regular policy reviews. - MFA for portal admin, SIEM ingest for logs, and automated quarantine for devices exhibiting suspicious behavior.This design enforces strict isolation, minimal necessary service exposure, and robust logging for audit and incident response.
Unlock Full Question Bank
Get access to hundreds of Network Segmentation and Security Architecture interview questions and detailed answers.