AI Skill Report Card

Architecting Networks

A-87·Sep 27, 2026·Source: Web

Network Architect

14 / 15

Given a project brief (scale, environments, compliance needs, growth targets), produce four deliverables in this order: Network Design → Traffic Flow → Security Layer → Scalability Plan. Always ground decisions in segmentation (least privilege between zones) and secure communication (encrypt in transit, authenticate at boundaries).

Example trigger: "Design a network for a 3-tier web app across dev/staging/prod with a compliance requirement for PCI-DSS."

Recommendation▾
Add an example showing a bad/naive output (e.g., flat network mistake) alongside the corrected version to reinforce pitfalls concretely
15 / 15

Progress:

  • Step 1: Gather requirements (scale, environments, compliance, latency/throughput needs, growth horizon)
  • Step 2: Define zones and segmentation (trust boundaries, VLANs/subnets, VPCs)
  • Step 3: Design routing (internal routing, egress/ingress paths, peering, NAT)
  • Step 4: Map traffic flow (client → edge → app → data, east-west vs north-south)
  • Step 5: Layer security controls (firewalls, ACLs, mTLS, WAF, IDS/IPS, secrets in transit)
  • Step 6: Plan scalability (horizontal growth, multi-region, autoscaling network paths, IP space headroom)
  • Step 7: Assemble the four-part output

Step details

1. Requirements gathering — Ask only if critical info is missing (scale, compliance, cloud/on-prem/hybrid). Otherwise assume reasonable defaults and state assumptions explicitly.

2. Segmentation — Default to zone model: Public/Edge → DMZ → Application → Data → Management. Each zone is a separate subnet/VLAN/VPC with explicit allow-list rules between adjacent zones only. No zone talks to a non-adjacent zone directly.

3. Routing — Specify: internal routing tables, default gateways, NAT gateways for private subnets, peering/transit gateway for multi-VPC/multi-region, and explicit deny for unrouted paths.

4. Traffic flow — Diagram as text (arrows + protocol + port). Separate north-south (user-facing) from east-west (service-to-service).

5. Security layer — Map each zone boundary to a control: firewall rules, mTLS between services, WAF at edge, IDS/IPS on ingress, VPN/private link for admin access. Encrypt all inter-zone traffic; authenticate every hop.

6. Scalability — Address: IP address space headroom (CIDR sizing), autoscaling group network attachment, multi-AZ/multi-region failover, load balancer tiers, and how segmentation rules extend to new nodes without redesign.

Recommendation▾
Include a brief note on when to deviate from the fixed four-zone model (e.g., serverless/microservices architectures) to show flexibility
17 / 20

Example 1: Input: "Design a network for a 3-tier web app across dev/staging/prod with PCI-DSS compliance."

Output:

Recommendation▾
Consider adding a short template/checklist for CIDR sizing math to make the 4x headroom guidance more actionable
  • 3 isolated VPCs (dev/staging/prod), each with 5 zones: Edge, DMZ, App, Data, Management
  • Prod: /20 CIDR split into /24 subnets per zone x 2 AZs
  • Dev/Staging: smaller /22 CIDR, single AZ, no PCI scope
  • User → CloudFront/WAF (443) → ALB (443) → App tier (8443, mTLS) → Data tier (5432, TLS, restricted SG)
  • Management: Bastion/VPN (22/443) → all zones (audited, MFA required)
  • East-west: App-to-App via internal ALB, mTLS enforced, no direct DB access from Edge/DMZ
  • WAF + rate limiting at Edge
  • Security Groups: default-deny, explicit allow per adjacent zone only
  • mTLS between App and Data tiers (cert rotation 90 days)
  • PCI scope isolated to Prod Data zone; flow logs to SIEM; IDS/IPS on ingress
  • Secrets via vault, never in transit unencrypted
  • Autoscaling App tier attaches to existing subnet/SG template — no manual network changes
  • Multi-AZ now, multi-region (active-passive) reserved CIDR blocks pre-allocated
  • Transit Gateway planned for >3 VPCs to avoid peering mesh complexity
  • Headroom: current usage 20% of allocated CIDR, supports 4x growth before re-IP needed

**Example 2:**
Input: "Segment a flat office network with no current VLANs."

Output:
  • Introduce 4 VLANs: Corporate (users), Servers, IoT/Guest, Management
  • Core switch with inter-VLAN routing via firewall (not switch ACL alone)
  • Corporate → Internet (proxied), Corporate → Servers (specific ports only)
  • IoT/Guest → Internet only, no access to Corporate/Servers
  • Management → all VLANs (read-only monitoring), admin access via jump host
  • Firewall rules enforce default-deny between VLANs
  • 802.1X for Corporate VLAN device authentication
  • IoT/Guest isolated at Layer 2 and Layer 3
  • VLAN IDs reserved in blocks of 10 per site for future site rollout
  • Template firewall ruleset replicated per new site via IaC
  • Always state assumptions when requirements are incomplete rather than blocking on questions.
  • Default to zero-trust: no implicit trust between zones, even internal ones.
  • Size IP address space for at least 4x current scale.
  • Encrypt and authenticate every inter-zone hop, not just internet-facing ones.
  • Keep the four output sections in the fixed order: Network Design, Traffic Flow, Security Layer, Scalability Plan.
  • Prefer named, reusable zone/tier patterns over one-off custom topologies.
  • Don't allow flat networks where all zones can reach all others.
  • Don't treat internal traffic as inherently trusted (skipping encryption east-west).
  • Don't undersize CIDR blocks — re-IP-ing later is costly and disruptive.
  • Don't conflate management/admin access controls with regular application traffic rules.
  • Don't omit the scalability plan even for "simple" designs — growth paths must be explicit.
0
Grade A-AI Skill Framework
Scorecard
Criteria Breakdown
Quick Start
14/15
Workflow
15/15
Examples
17/20
Completeness
18/20
Format
15/15
Conciseness
13/15