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.

HardTechnical

42 practiced

Translate this hybrid connectivity scenario into routing and firewall controls: on-prem network 10.0.0.0/16 connects to AWS via Direct Connect with two VPCs (10.1.0.0/16 and 10.2.0.0/16). You must allow only web traffic from the internet to 10.1.0.0/16 DMZ, allow 10.1.0.0/16 to reach 10.2.0.0/16 App through an inspection gateway, and prevent direct VPC-to-VPC lateral movement. Provide a BGP/routing sketch and the firewall (or Security Group/NACL) rules necessary to enforce these constraints.

Sample Answer

**Approach (brief)** I’ll show a BGP/routing sketch for Direct Connect + TGW, then specific firewall / Security Group / NACL rules to enforce: only Internet→10.1 DMZ web allowed, 10.1→10.2 allowed via inspection gateway, and block direct VPC-to-VPC lateral movement.

**Topology & BGP/routing sketch**- On-prem: 10.0.0.0/16- VPC-DMZ: 10.1.0.0/16- VPC-App: 10.2.0.0/16- Transit/Inspection GW (NGFW) in 10.1 or separate inspection VPC (10.3.0.0/24)

ASCII:

Internet -> IGW -> ALB / ELB -> SG(DMZ web) -> 10.1.0.0/16
10.1 <-> TGW <-> DX Gateway <-> OnPrem (BGP)
10.2 attached to TGW but routes to 10.1 go via NGFW: 10.2 -> TGW -> Route to 10.3(inspection) -> 10.1
BGP: advertise 10.1/16, 10.2/16, 10.0/16 between TGW and on-prem

Routing rules:- On TGW, set route table for 10.2 -> direct to VPC-Attachment; 10.1 -> via inspection attachment (10.3)- On VPC attachments, disable route propagation so traffic between 10.1 and 10.2 hits TGW rules

**Firewall / SG / NACL rules**

1) Internet → 10.1 DMZ (only web)- ALB/NAT/IGW security group (allow inbound TCP 80,443 from 0.0.0.0/0)- DMZ instances SG: allow inbound TCP 80,443 from ALB SG; deny other inbound- NACL on 10.1 subnet: allow ephemeral responses; explicit deny other inbound ports if required

2) 10.1 → 10.2 only via inspection gateway- TGW routing forces 10.1→10.2 traffic to inspection VPC (10.3)- Inspection gateway NGFW rules: - Inbound (from 10.1): allow TCP/UDP required app ports (e.g., 443, 8080) to 10.2; apply IDS/IPS, URL/App controls - Outbound (to 10.2): allow same - Drop any traffic sourced from 10.1 destined to 10.2 that fails inspection- On 10.2 SG: allow inbound from NGFW ENI CIDR (10.3) on app ports; deny inbound from 10.1 CIDR- On 10.1 SG: allow outbound to NGFW only on required ports; do NOT allow direct outbound to 10.2 CIDR

3) Prevent direct VPC-to-VPC lateral movement- 10.2 SG: deny/omit rules allowing 10.1 CIDR. Only permit traffic from NGFW IP(s).- 10.1 SG: restrict outbound to NGFW IP(s) and Internet (for web).- NACLs optional: add stateless rules to block 10.1→10.2 and 10.2→10.1 except via NGFW subnets.

**Validation & Notes**- Ensure TGW route table attachment separation: one table forcing 10.1→inspection and 10.2→local; disallow peering that bypasses TGW inspection.- BGP: advertise VPC CIDRs via TGW to on-prem; use route prioritization / blackhole for accidental direct paths.- Audit: verify flow logs / NGFW logs to confirm flows traverse inspection.

MediumTechnical

35 practiced

Design network segmentation for a Kubernetes cluster hosting three namespaces: frontend, backend, and db. Requirements: frontend pods can talk to backend on TCP 80; backend can talk to db on TCP 5432; no other cross-namespace traffic allowed. Provide example Kubernetes NetworkPolicy YAML(s) that enforce this behavior and explain how policy enforcement differs across CNIs.

Sample Answer

**Approach (brief)** Use default deny egress/ingress in each namespace, then allow only the explicit flows: frontend -> backend: TCP 80, backend -> db: TCP 5432. Apply NamespaceSelector-based NetworkPolicies so labels control allowed peers.

**NetworkPolicy YAMLs**

Allow backend to receive from frontend on TCP 80:

yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: backend
spec:
  podSelector: {}           # all backend pods
  policyTypes: ["Ingress"]
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          app-namespace: frontend
    ports:
    - protocol: TCP
      port: 80

Allow db to receive from backend on TCP 5432:

yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-db
  namespace: db
spec:
  podSelector: {}           # all db pods
  policyTypes: ["Ingress"]
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          app-namespace: backend
    ports:
    - protocol: TCP
      port: 5432

Default deny in each namespace (optional explicit deny by creating an empty policy):

yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: frontend
spec:
  podSelector: {}
  policyTypes: ["Ingress"]
  ingress: []
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: backend
spec:
  podSelector: {}
  policyTypes: ["Ingress"]
  ingress: []
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: db
spec:
  podSelector: {}
  policyTypes: ["Ingress"]
  ingress: []

Ensure each Namespace has label e.g. kubectl label namespace frontend app-namespace=frontend, etc.

**How enforcement differs across CNIs**- Calico: fully supports NetworkPolicy and NamespaceSelector; can enforce both ingress and egress and offers logging, global policies, and advanced selectors. Use Calico for scalable microsegmentation.- Cilium: supports NetworkPolicy and more advanced L7 and identity-aware policies (eBPF); can do richer observability and efficient enforcement.- Weave Net / kube-proxy-mode CNIs: basic NetworkPolicy support may vary; older or minimal CNIs might only support namespaced podSelector rules and not NamespaceSelector or egress. Always verify CNI docs and test with tools (kubectl exec curl) and consider adding egress policies if outbound restrictions required.

Testing: validate with namespaces labeled, then curl from pods and observe allow/deny; check CNI logs/iptables/ipsets or Cilium Hubble for troubleshooting.

MediumTechnical

38 practiced

Design a centralized logging and monitoring architecture to collect firewall logs, NetFlow/IPFIX data, host logs, and Kubernetes network policy events across an on-prem and cloud hybrid environment. Include log transport, normalization, retention policies for compliance, real-time alerting, and automated response playbooks for containment.

Sample Answer

**Overview / Goals**Centralized, resilient collection of firewall logs, NetFlow/IPFIX, host logs, and K8s network policy events across on‑prem and cloud; normalized, retained for compliance, with real‑time alerts and automated containment playbooks.

**Architecture**- Collectors: Dedicated on‑prem Log Forwarders (rsyslog/Fluentd) + cloud agents (Fluent Bit) → secure TLS/mTLS to central Ingest Layer.- NetFlow/IPFIX: High‑performance flow collectors (nfdump/pmacct or commercial) aggregation → export as JSON to ingest.- Ingest/Queue: Kafka or AWS Kinesis for buffering and resilience.- SIEM / Index: Elastic Stack / Splunk / Sumo Logic for parsing, correlation, dashboards.- Storage: Hot (searchable) indices for 90 days, warm for 1 year, cold/archival to S3/Glacier for compliance (policy-driven).

**Normalization & Enrichment**- Use ingest pipelines to map fields to canonical schema (src_ip, dst_ip, proto, bytes, action, flow_duration).- Enrich with asset inventory, geolocation, vulnerability tags, Kubernetes metadata (pod, ns, policy).

**Retention / Compliance**- Compliance example: PCI/HIPAA — keep raw logs 1 year, indexed alerts 2 years; encrypt at rest, role‑based access, WORM for archival where required.

**Real‑time Alerting**- Stream detection rules in SIEM + anomaly detection on NetFlow (spikes, data exfiltration), failed connection patterns, policy violations.- Alerting channels: PagerDuty, Slack, ServiceNow tickets.

**Automated Response Playbooks**- Playbook examples: - Lateral movement detected (high connection fan‑out): auto‑isolate host via NAC API, block IP on perimeter firewall, create ticket, notify SOC. - K8s network policy violation: add network policy deny rule via GitOps PR, scale down offending pod, quarantine via CNI label.- Ensure human approval step for high‑impact actions; log all actions for audit.

**Operational Considerations**- Test via purple team drills, monitor pipeline latency, rotate keys, monitor storage costs.- Document runbooks and monitor collector health with metrics and SLAs.

MediumTechnical

43 practiced

Describe a practical plan to validate and test network segmentation controls after deployment and on a recurring basis. Include automated tests (policy-as-code), passive flow verification, active scanning, host-based verification, scheduled penetration tests, and how to safely remediate failed controls without causing downtime.

Sample Answer

**Plan Overview**Validate segmentation with an automated, layered testing program: policy-as-code + CI, passive flow verification, active scans, host checks, scheduled pen tests, and safe remediation playbooks.

**Policy-as-code (automated)**- Encode segmentation rules in Terraform/CloudFormation + OPA/Rego or Sentinel.- CI pipeline runs unit tests (policy evaluations), and integration tests against a staging VPC using mocked flows.- Example: PR blocked if OPA detects a security group allowing DB access from 0.0.0.0/0.

**Passive flow verification**- Collect VPC Flow Logs/NetFlow/sFlow and centralize (ELK/Splunk).- Daily automated queries to confirm only allowed source-dest-port tuples appear.- Use baselined alerting for unexpected flows (anomaly scoring).

**Active scanning**- Weekly targeted scans with nmap/Nessus from bastion/jump hosts to verify ports unreachable where blocked.- Use authenticated scans on hosts to check internal listener exposure.

**Host-based verification**- OS agents (osquery/Wazuh) validate iptables/ACL state, routing table, and service bindings; run nightly checks and report drift to CMDB.

**Scheduled pen-testing**- Quarterly internal/external pen-tests focusing on lateral movement and segmentation bypass; capture TTPs and remediation tickets.

**Safe remediation**- Use canary patches: apply rule changes to a small subnet, enable traffic mirroring to validate, then roll out.- Implement automated rollback in config management if health checks (connectivity, application KPIs) degrade.- Schedule disruptive remediations in maintenance windows and coordinate with owners; use staged firewall rule insertions (deny with logging first, then deny without logging).

**Observability & Governance**- Dashboards for policy compliance and recent remediation actions.- Change control/RBAC and runbooks for emergency rollback.- Metric-driven SLIs: segmentation-compliance %, unauthorized-flow-count, time-to-remediate.

This approach ensures continuous validation with low risk to production availability.

MediumTechnical

74 practiced

You manage an L3 switched network with VLANs: 10 (users), 20 (VoIP), 30 (servers). Users should not initiate connections to servers except to a specific app server on TCP 8080; servers should reach only management hosts on TCP 22. Draft Cisco-like ACLs for this scenario and explain where (which interfaces and direction) you would apply them to limit unnecessary traffic and avoid asymmetric routing.

Sample Answer

**Approach (short):**Apply explicit extended ACLs on the VLAN SVIs, inbound on the source VLANs so unwanted packets are dropped before routing (avoids asymmetric routing). Permit only needed flows; deny others and allow intra-VLAN and necessary infrastructure (DHCP, DNS) as needed.

**ACLs (Cisco-like examples, adjust IPs to real ones):**

bash

! Users (VLAN 10) — allow DNS/DHCP, allow to app server 10.30.10.5:8080, deny other accesses to servers (VLAN30)
ip access-list extended ACL-VLAN10-IN
 permit udp any eq domain any                ! DNS (if needed)
 permit udp any eq bootps any                  ! DHCP server/relay (if needed)
 permit tcp 10.10.0.0 0.0.0.255 host 10.30.10.5 eq 8080
 deny   ip 10.10.0.0 0.0.0.255 10.30.0.0 0.0.0.255
 permit ip any any                             ! allow other legitimate traffic (or be explicit)

bash

! Servers (VLAN 30) — allow SSH only to management hosts in VLAN10 (e.g. 10.10.0.5/24)
ip access-list extended ACL-VLAN30-IN
 permit tcp 10.30.0.0 0.0.0.255 10.10.0.0 0.0.0.255 eq 22
 deny   ip 10.30.0.0 0.0.0.255 10.10.0.0 0.0.0.255
 permit ip any any                             ! allow other required egress (or be explicit)

**Where to apply (interfaces & direction):**- Apply ACL-VLAN10-IN on SVI interface Vlan10, inbound: interface Vlan10 ip access-group ACL-VLAN10-IN in Rationale: blocks user-initiated connections to servers before routing.- Apply ACL-VLAN30-IN on SVI interface Vlan30, inbound: interface Vlan30 ip access-group ACL-VLAN30-IN in Rationale: prevents servers from initiating non-management flows as soon as traffic enters L3.

**Reasoning / asymmetric routing:**- Applying ACLs on the source-VLAN SVI inbound ensures packets are filtered before routing to another device path; this avoids creating asymmetry where return traffic bypasses the ACL.- Stateful inspection would simplify return handling; on pure IOS L3, keep ACLs symmetric (control both directions) or permit return traffic explicitly.- Test and log denies, and be cautious with broad "permit ip any any" — replace with explicit permitted services (DNS, NTP) in production.

Unlock Full Question Bank

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

Join thousands of developers preparing for their dream job.