Amazon Network Engineer (Mid-Level) Interview Preparation Guide

Network Engineer

Amazon

Mid Level

6 rounds

Updated 6/20/2026

Amazon's interview process for mid-level Network Engineers typically consists of a recruiter screening phase, followed by a technical phone screen, and then 4-5 onsite rounds spanning one full day. The process evaluates technical networking expertise, system design thinking, troubleshooting methodology, security awareness, and alignment with Amazon's Leadership Principles. Expect 6-7 weeks total from initial application to offer decision.

Interview Rounds

Recruiter Screening

30 min3 focus topicsculture fit

Technical Phone Screen

60 min5 focus topicstechnical

What to Expect

60-minute technical interview with a senior network engineer or infrastructure specialist. This round assesses hands-on networking knowledge, troubleshooting methodology, and basic system design thinking. Expect a mix of scenario-based questions (network outages, connectivity issues) and technical deep-dives into protocols, tools, and architectures you've worked with. You may be asked to troubleshoot a described network problem, explain a network design decision, or walk through how you'd approach a given infrastructure challenge.

Tips & Advice

Be very clear in your troubleshooting methodology—walk through your diagnostic steps methodically (e.g., 'First I'd verify IP connectivity with ping, then check routing tables, then examine firewall rules'). Use tools you know deeply: netstat, ss, ip route, dig, traceroute, tcpdump, etc. If asked a scenario-based question, ask clarifying questions before jumping to conclusions. For example, if told 'clients can't reach a service,' ask what kind of clients, what service, what error they see. Show your thinking. Be comfortable with OSI model layers and know which tools diagnose issues at each layer. If you don't know something, say so and explain how you'd figure it out. Mention AWS networking if relevant to your background, but don't force it. Have 1-2 real examples ready of complex network problems you solved, with specific tools and outcomes.

Focus Topics

Firewall & Security Rules Configuration

Understanding firewall rule logic, ACLs, NAT, port forwarding, and how security policies affect connectivity.

Practice Interview

Study Questions

Network Monitoring & Diagnostic Tools

Hands-on expertise with tools like ping, traceroute, netstat, ss, dig, nslookup, tcpdump, ip commands, and ability to interpret output to diagnose issues.

Practice Interview

Study Questions

Network Troubleshooting Methodology

Systematic approach to diagnosing network issues: verifying connectivity at each OSI layer, using appropriate diagnostic tools, isolating problems to specific components.

Practice Interview

Study Questions

Network Protocols & OSI Model

Practical knowledge of DNS, DHCP, ARP, TCP/IP, MTU, fragmentation, and ability to map problems to specific OSI layers and relevant protocols.

Practice Interview

Study Questions

Routing & Switching Fundamentals

Deep understanding of routing protocols (BGP, OSPF, static routing), routing tables, switch operation, VLANs, and how traffic moves through networks.

Practice Interview

Study Questions

Onsite Round 1: Network Architecture & Infrastructure Design

60 min4 focus topicssystem design

What to Expect

55-60 minute session focused on designing network infrastructure for a given business scenario or requirement. You'll be asked to design a network architecture (e.g., a multi-region setup, a hybrid cloud network, or infrastructure for a high-traffic application). Expect to diagram the network, discuss component choices, explain how data flows, address redundancy and failover, and justify your design decisions. May include AWS services like VPC, subnets, route tables, and security groups if the scenario is cloud-focused.

Tips & Advice

Start by asking clarifying questions about requirements: scale, latency, redundancy needs, geographic distribution, security constraints, budget. Don't assume—confirm. Diagram clearly on a whiteboard or in a shared document; label all components and data flows. For mid-level, focus on practical architectures, not overly complex designs. Discuss trade-offs explicitly (e.g., 'I chose redundant routers over a single router because it reduces single points of failure, but adds cost and complexity'). Be comfortable explaining why you chose specific technologies. If discussing AWS, explain VPC design, subnet strategy, routing, and security groups. Walk through how a request or packet would flow through your design. Address failure scenarios: what happens if a router fails, a link goes down, or a region becomes unavailable? Show you're thinking about operational resilience.

Focus Topics

Redundancy & High Availability Design

Designing networks with failover mechanisms, redundant paths, load balancing, and strategies to minimize downtime.

Practice Interview

Study Questions

Network Security Architecture

Integrating firewalls, DDoS protection, segmentation, encryption in transit, and access controls into network designs.

Practice Interview

Study Questions

Network Architecture Design Principles

Ability to design scalable, resilient network architectures considering redundancy, load balancing, geographic distribution, and business requirements.

Practice Interview

Study Questions

AWS Networking Services & VPC Design

Practical knowledge of AWS VPC, subnets, route tables, internet gateways, NAT gateways, security groups, NACLs, and how to design resilient cloud networks.

Practice Interview

Study Questions

Onsite Round 2: Network Troubleshooting & Operational Deep Dive

60 min5 focus topicstechnical

What to Expect

55-60 minute session presenting a complex, multi-layered network problem and asking you to diagnose and resolve it. The scenario might simulate a real incident: clients can't reach a service, latency spikes, intermittent connectivity, or unusual packet loss. You'll need to ask clarifying questions, form hypotheses, rule out causes systematically, and propose solutions. Interviewers will test your hands-on diagnostic skills and how you prioritize investigation.

Tips & Advice

Treat this like a real incident: stay calm and methodical. Ask questions to scope the problem (who's affected, when did it start, what's the impact). Don't assume—verify. Walk through your diagnostic steps out loud so the interviewer understands your thinking. Explain which tool you'd use and why at each step. If you hit a dead end, say so and try a different hypothesis. For example: 'DNS works and ping succeeds, so network layer is fine. Let me check if the port is open on the service.' Show you understand which tools diagnose at which layers. Mention monitoring and alerting: how would you have caught this proactively? Discuss remediation: once you fix it, how do you prevent recurrence? Be specific about tools: 'I'd run tcpdump to capture traffic' not 'I'd check the packets.' Mid-level engineers should show strong foundational knowledge and systematic thinking.

Focus Topics

Performance Optimization & MTU Issues

Identifying and fixing packet fragmentation, MTU mismatches, latency issues, and throughput problems in networks.

Practice Interview

Study Questions

DNS & DHCP Troubleshooting

Diagnosing DNS resolution failures, DNS server reachability, DHCP address assignment issues, and resolver configuration problems.

Practice Interview

Study Questions

Routing Failures & Path Issues

Identifying missing routes, incorrect route priority, overlap in CIDR blocks, policy-based routing issues, and incorrect next-hops.

Practice Interview

Study Questions

Firewall & Security Policy Troubleshooting

Diagnosing blocked traffic due to firewall rules, ACLs, NAT issues, or security group misconfigurations.

Practice Interview

Study Questions

Layered Network Troubleshooting (OSI Model Application)

Systematic diagnostics across layers: physical, data link, network, transport, and application layers; knowing which tools diagnose issues at each layer.

Practice Interview

Study Questions

Onsite Round 3: Network Security & Compliance

60 min5 focus topicstechnical

What to Expect

55-60 minute discussion of network security practices, compliance requirements, and secure infrastructure design. You'll discuss how you've implemented security measures, managed access controls, handled security incidents, ensured compliance with standards (if applicable), and thought about threat models. Interviewers assess whether you proactively consider security in your designs and operations.

Tips & Advice

Demonstrate that security is integral to your work, not an afterthought. Prepare specific examples: 'When designing VPNs, I implemented encryption and authentication. When troubleshooting a DDoS, I worked with security to implement rate-limiting rules.' Discuss the principle of least privilege and defense in depth. Be familiar with common security threats relevant to networks: DDoS attacks, man-in-the-middle, DNS spoofing, unauthorized access. Explain how you'd respond to a security incident—document, isolate, investigate. Mention monitoring: how do you detect security issues? Discuss encryption: when and where you use it. If you've worked with compliance frameworks (PCI-DSS, SOC 2), mention relevant experience. For Amazon-specific context, be aware that Amazon values security and compliance highly; show that these are priorities for you too. Avoid being preachy; ground everything in practical examples.

Focus Topics

Security Incident Response & Monitoring

Detecting and responding to security incidents in networks, using monitoring tools to identify anomalies, and following incident response procedures.

Practice Interview

Study Questions

VPN & Secure Remote Access

Designing and implementing VPNs for secure remote access, understanding VPN protocols, authentication mechanisms, and tunnel establishment.

Practice Interview

Study Questions

DDoS Mitigation & Threat Prevention

Understanding DDoS attack vectors, mitigation strategies (rate limiting, filtering, scrubbing), and how to design networks resilient to common threats.

Practice Interview

Study Questions

Network Encryption & Confidentiality

Implementing encryption for data in transit: TLS/SSL, IPsec, VPN tunnels, and understanding when and why encryption is necessary.

Practice Interview

Study Questions

Access Control & Segmentation

Designing network segmentation, VLANs, firewall rules, and access control lists to enforce least-privilege access and prevent unauthorized data flows.

Practice Interview

Study Questions

Onsite Round 4: Behavioral & Amazon Leadership Principles

60 min6 focus topicsbehavioral

What to Expect

55-60 minute behavioral interview assessing alignment with Amazon's 16 Leadership Principles and your ability to work collaboratively, handle ambiguity, own problems, and drive results. Interviewers will ask about past experiences: how you handled conflicts, managed tight deadlines, learned from failures, influenced decisions, and prioritized customer impact. Expect questions like 'Tell me about a time you had to make a decision without perfect information' or 'Describe a conflict with a team member and how you resolved it.' For mid-level, expect emphasis on ownership, collaboration, bias for action, and learning.

Tips & Advice

Prepare 6-8 concrete STAR stories (Situation, Task, Action, Result) that illustrate Amazon Leadership Principles. For mid-level engineers, emphasize ownership (you led or owned a project, not just helped), bias for action (you moved quickly despite incomplete information), and learning and growth (you failed, learned, and improved). Practice stories showing collaboration, conflict resolution, and customer focus. Connect your examples explicitly to Leadership Principles when answering. For example: 'This demonstrates bias for action—we identified the issue and immediately began mitigation rather than waiting for perfect data.' Avoid vague answers; be specific with metrics and outcomes. For networking context, you might discuss: a major infrastructure upgrade you owned, a critical outage you helped resolve, a security vulnerability you discovered and drove to remediation, or a cost optimization you led. Show that you think about impact beyond your immediate work. For Amazon specifically, discuss customer obsession: how you made decisions based on what was best for customers or the business, not just technical preference. Practice briefly so you don't go over time. Be authentic—Amazon interviewers can tell if you're not genuine.

Focus Topics

Conflict Resolution & Difficult Conversations

Handling disagreements with teammates or managers, addressing issues directly and constructively, finding win-win solutions.

Practice Interview

Study Questions

Amazon Leadership Principle: Customer Obsession

Making decisions based on customer/user needs and impact, not internal preferences; thinking about how work serves business goals.

Practice Interview

Study Questions

Learning & Growth Mindset

Demonstrating eagerness to learn new technologies and approaches, handling failure constructively, improving skills continuously.

Practice Interview

Study Questions

Collaboration & Cross-Functional Communication

Working effectively with peers, managers, and other teams; communicating clearly; handling disagreements professionally; supporting team goals.

Practice Interview

Study Questions

Amazon Leadership Principle: Ownership

Taking ownership of projects end-to-end, making decisions, driving results, and taking responsibility for both successes and failures.

Practice Interview

Study Questions

Amazon Leadership Principle: Bias for Action

Making decisions and moving forward quickly with incomplete information, iterating, and learning fast rather than over-analyzing.

Practice Interview

Study Questions

Frequently Asked Network Engineer Interview Questions

Network Architecture and DesignEasyTechnical

43 practiced

Explain the hierarchical network design model of access, distribution (or aggregation), and core layers. For each layer, state primary functions, typical device choices and features enabled there, and how failure at that layer impacts services. Illustrate how you would map this model to a three-floor corporate campus with redundant uplinks between floors.

Sample Answer

**Overview (model)** The hierarchical model separates functions into Access, Distribution (Aggregation), and Core to improve scalability, manageability and fault containment.

**Access layer — primary functions & devices** - Functions: connect end devices (PCs, IP phones, Wi‑Fi APs), enforce port security, VLAN tag/assignment, PoE. - Devices/features: access switches (stackable L2/L3), features like 802.1X, port security, QoS, PoE, storm control. - Failure impact: users on that switch/ports lose connectivity but fault is localized; uplink redundancy or port-channel minimizes impact.

**Distribution (Aggregation) layer** - Functions: policy enforcement, routing between VLANs, aggregation of access switches, QoS boundary, security filtering (ACLs), redundancy. - Devices/features: multilayer switches or small routers, L3 routing, HSRP/VRRP, policy-based routing, NAT for DMZ. - Failure impact: affects multiple access switches/VLANs; redundant distribution pairs mitigate outage.

**Core layer** - Functions: fast, reliable backbone switching/routing, high-speed transport between distribution blocks, minimal service policy. - Devices/features: high‑performance routers/switches, MPLS or OSPF/BGP, ECMP, high throughput interfaces. - Failure impact: wide-scale outage or asymmetric routing; typically mitigated with redundant core paths and diverse uplinks.

**Three-floor campus mapping (example)** - Each floor: access switch stacks delivering PoE to endpoints and APs. - Floor distribution: a pair of distribution switches per floor that aggregate the floor access stacks; run HSRP/VRRP and MLAG to access. - Core: redundant core routers/switches in a central closet/data center connecting all floor distribution devices with 10/40Gbps links; use L3 routing (OSPF) and ECMP. - Redundant uplinks: each access stack has dual uplinks to the two local distribution switches; each distribution has dual uplinks to both core devices (full-mesh or partial-mesh) so any single device or link failure keeps most services reachable.

Network Troubleshooting MethodologyMediumTechnical

81 practiced

Explain how to use iperf (or iperf3) to distinguish between client-side, server-side, and network path bottlenecks. Provide test plans for both TCP and UDP tests, single-direction and bidirectional tests, and how to interpret results like retransmits, jitter, and achievable bandwidth.

Sample Answer

**Approach summary**Describe tests to isolate client, server, or path issues by varying endpoints, direction, parallel streams, and protocol. Use iperf3 on both ends; collect OS counters (netstat, ethtool, ifconfig) alongside.

**TCP single-direction**- Start server:

bash

iperf3 -s

- From client to server (default):

bash

iperf3 -c SERVER_IP -P 1 -t 60

- Increase parallel streams to saturate NIC/CPU: `-P 8`Interpretation:- Low throughput + high retransmits → path loss or congestion.- Throughput limited near client/server NIC capacity + no retransmits → endpoint CPU/NIC limit.- Server CPU high during test → server-side bottleneck.

**TCP bidirectional**

bash

iperf3 -c SERVER_IP -R    # reverse direction
iperf3 -c SERVER_IP --bidir  # simultaneous bilateral

If one direction is worse, bottleneck is near the sender of that direction.

**UDP tests**- Send controlled rate:

bash

iperf3 -c SERVER_IP -u -b 100M -t 30

- Vary -b to find max achievable without loss.Interpretation:- Packet loss or high jitter → path congestion or QoS shaping.- Zero loss but bandwidth plateaus at NIC limit → endpoint.

**Diagnostics and corroboration**- Check retransmits: iperf3 reports `retransmits` (TCP) — path loss/congestion likely.- Check jitter, packet loss (UDP): jitter > few ms or >1% loss indicates path issues.- Cross-check: traceroute, ping with TTL, tcpdump on both ends to see where packets drop.- CPU/NIC counters: `top`, `sar`, `ethtool -S`, interface errors.

**Test plan summary**- Baseline: localhost, then same-rack, then cross-datacenter.- Isolate: swap client/server roles; increase parallelism; change MTU; run at different times.This sequence pinpoints client, server, or network path bottlenecks.

Customer ObsessionEasyTechnical

27 practiced

As part of daily operations you get multiple minor customer requests: one asks for custom routing preference, another asks for additional monitoring, a third asks for a higher SLA. How would you prioritize these requests and what criteria would you use to decide which to implement first?

OSI Model and TCP IP StackMediumTechnical

78 practiced

Provide a step-by-step plan to troubleshoot intermittent DNS failures for users where web browsing is impacted, but some sites resolve correctly. Map likely causes to OSI/TCP-IP layers and include commands/tools you would run (e.g., dig, nslookup, tcpdump, netstat).

OwnershipMediumTechnical

21 practiced

Product and Security disagree about a proposed network change that will slightly increase latency but significantly improve security posture. As the network owner, how do you reconcile the conflict and drive a decision that balances short-term impact and the long-term company goals?

Encryption and Secure ConnectivityEasyTechnical

44 practiced

What are the key security considerations when deploying SD-WAN across branch offices? Discuss overlay encryption choices, segmentation strategies, integration with SASE/ZTNA, controller security, and orchestration concerns.

Network Troubleshooting and ToolsHardSystem Design

68 practiced

Design an automated health-check script or pipeline (languages/tools optional) that runs synthetic network tests (ping, traceroute, dig, iperf3) from multiple locations to a set of application endpoints, aggregates the results, detects anomalies (loss >1%, RTT jump >100ms, DNS resolution failures), and alerts. Describe the data model, storage, alerting thresholds, and how you would avoid alert storms during transient spikes.

Sample Answer

**Clarify requirements / constraints**- Run synthetic network tests (ping, traceroute, dig, iperf3) from multiple geographic locations to N application endpoints, store results, detect anomalies (loss >1%, RTT jump >100ms, DNS failures), alert reliably without storming.

**High-level architecture**- Agents (Go/Python) deployed in multiple PoPs or cloud regions run scheduled tests; push events to Kafka.- Stream processor (Flink/Beam) normalizes, computes short-window aggregates and writes to TSDB (VictoriaMetrics) and object store (Parquet in S3) for raw traces.- Alerting: Prometheus Alertmanager or custom rule engine subscribing to aggregated metrics; Slack/pager/email notifications via escalation channels.- Dashboarding: Grafana with trace drill-down (stored traceroutes/iperf logs).

**Data model (per test event)**- test_id, timestamp, source_location, target_endpoint (URL/IP), test_type (ping/traceroute/dig/iperf3)- metrics: rtt_ms, packet_loss_pct, jitter_ms, throughput_mbps, dns_rcode, dns_ip_list- traceroute_hops: [ {hop, ip, rtt_ms} ]- raw_output_url (S3)- tags: env, app_team

**Storage & retention**- TSDB (VictoriaMetrics/Prometheus remote write) for 1s–1m aggregates, retention 30d for high-res.- Parquet S3 for raw outputs and traces, retention 90–365d.- Index on source_location, target_endpoint, test_type, timestamp.

**Anomaly detection & thresholds**- Primary rules: - packet_loss_pct > 1% (instant) -> candidate anomaly - rtt_ms increase > 100ms compared to baseline (median of last 1h) -> candidate - DNS: non-zero rcode OR no A records -> immediate failure- Use two-stage detection: 1. Statistical check: compare current value to baseline (median + 3*IQR) and absolute thresholds above. 2. Persistence check: condition must hold for K samples or T seconds (e.g., 3 consecutive 1-min samples or sustained 5 minutes) before firing.

**Avoiding alert storms**- Debounce / aggregation: - Require sustained window (see persistence check). - Group alerts by root-cause dimensions (target_endpoint, region, AS) to avoid per-agent duplicates. - Use deduplication keys in Alertmanager: alertname + target_endpoint + root_cause_hash.- Rate limits & escalation: - Per-target rate limit (e.g., max 1 alert / 10 min). - Severity tiers: transient (warning) -> sustained (critical) -> outage (page).- Correlation: - If multiple sources show simultaneous loss to same target, escalate faster. - Use traceroute diffs to detect same failing hop and suppress per-source noise.- Auto-suppression windows: - Short maintenance windows and known rolling deploy windows read from calendar API to suppress expected noisy periods.

**Operational details**- Tests schedule: ping/dig every 30s, traceroute every 5min, iperf3 every 15min (sampled).- Health of agents monitored; missing agents treated separately.- Playbooks linked in alerts with remediation steps and traceroute/iperf raw output links.- Regular baseline re-calculation with rolling 7-day windows to account for diurnal patterns.

This design balances sensitivity (detect real degradation) with resilience to transients (debounce, grouping, correlation), gives teams actionable context (hops, throughput, DNS), and scales via Kafka + stream processing + TSDB.

Learning Agility and Growth MindsetMediumTechnical

52 practiced

Design a 90-minute knowledge-transfer workshop for teaching advanced BGP troubleshooting to mid-level engineers. Provide a lesson outline with time boxes, a hands-on lab exercise (topology and tasks) with expected outcomes, and two assessment questions you would ask to verify participants learned the key concepts.

Sample Answer

**Workshop Title & Goal**Advanced BGP Troubleshooting — enable mid-level engineers to diagnose and fix complex BGP issues in multi-AS, iBGP/ eBGP, and route-policy environments.

**Outline (90 minutes)**- 0–10m: Introduction & learning objectives- 10–25m: Key concepts refresher (BGP path selection, attributes, route reflection, confederations, next-hop, MED, communities)- 25–40m: Common failure modes and diagnostic tools (show commands, bgp debug, traceroute, MRT)- 40–45m: Demo: reading BGP RIB/Adj-RIBs and policy effects- 45–80m: Hands-on lab (35m) — perform tasks below- 80–90m: Review, Q&A, and assessments (10m)

**Hands-on Lab**Topology:- Router R1 (AS 65001), R2 (AS 65002), R3 (AS 65002, RR), R4 (AS 65003). R2 and R3 are iBGP with RR; R3 peers eBGP to R4. R1 eBGP to R2.

Tasks:1. Observe that prefix 10.10.0.0/24 on R4 is not present on R1. Use show ip bgp, show bgp adj-rib and trace to find where it’s dropped.2. Identify if next-hop or route reflection loop prevents advertisement. Fix by adjusting next-hop-self on RR or update-route-maps.3. Simulate MED override and use community to prefer path via AS65003 -> implement and verify.

Expected outcomes:- Engineers locate the failure point via Adj-RIBs and BGP attributes.- Implement corrective config (next-hop-self, route-map, community tagging).- Validate with show ip bgp, traceroute, and traffic verification.

**Assessment Questions**1) Why might an iBGP-learned prefix not be advertised to other iBGP peers and how do you fix it? - Expected answer: iBGP split-horizon: iBGP-learned routes aren’t forwarded; use route reflection or full-mesh, or configure RR. Ensure next-hop correctness.2) You see same prefix from two eBGP neighbors but path chosen is not the one you expect. List the BGP attribute order you’d check and one config action to force the preferred path. - Expected answer: Check weight (vendor), local-pref, AS_PATH, origin, MED, eBGP over iBGP, IGP cost. To force: adjust local-pref, prepend AS_PATH, or set MED/local policy.

Network Segmentation and Security ArchitectureMediumTechnical

67 practiced

For a service that handles cardholder data, describe the network segmentation and controls you would implement to achieve PCI-DSS scope reduction. Include firewall and ACL design, logging and retention settings, segmentation testing, and what evidence you would present to an auditor to demonstrate isolation.

Sample Answer

**Clarify objective**Reduce PCI-DSS scope by isolating cardholder data environment (CDE) so only necessary systems are in-scope.

**Segmentation design**- Logical & physical layers: place CDE in dedicated VLANs/subnets with strict east‑west controls; deploy dedicated firewall tier (stateful NGFW) between CDE and corporate/Internet zones.- Zero-trust microsegmentation for hosts (host-based firewall + network policies) and cloud security groups for cloud workloads.- Management/monitoring on separate management VLAN with ACLs allowing only jump/ bastion hosts.

**Firewall & ACLs**- Deny‑by‑default ruleset; explicit allow for required flows only (list services, ports, source/dest). Example: allow app servers -> payment gateway on TCP 443 only.- Use network object groups, least privilege, and rule comments mapping to business justification.- ACLs on routers to block direct routing between CDE and other networks; use ACL logging for denied flows.

**Logging & retention**- Centralized SIEM ingest of FW, IDS/IPS, host logs, authentication, and flow logs. Retain per PCI: at least 1 year, with 3 months immediately available online.- Timestamp-sync (NTP), immutable storage or WORM for audit logs, access controls on logs.

**Segmentation testing**- Quarterly and after changes: internal/external penetration testing, VLAN hop tests, firewall rule reviews, active network scanning and validation of ACL effectiveness.- Use packet captures and test vectors to prove blocked/allowed flows.

**Evidence for auditor**- Network diagrams with IPs/VLANs and ACL/Firewall rule excerpts annotated to business need.- Firewall rulebase exports, ACL configs, and change-control tickets.- Segmentation test reports, pen-test results, and remediation trackers.- SIEM retention proof (screenshots, export), log integrity checksums, and NTP config.- Access lists showing management isolation and jump-host session logs.

I would present these artifacts and explain operational controls (change management, monitoring, quarterly reviews) to demonstrate continual isolation.

Routing Fundamentals and ProtocolsMediumSystem Design

96 practiced

Design a multi-homed internet edge for an enterprise connecting to two ISPs using BGP. Explain how you would advertise your prefixes, influence inbound and outbound traffic (local-pref, AS_PATH prepend, MED), provide high-level examples of policy choices, and explain how you would prevent routing loops or accidental address leaks.

Sample Answer

**Clarify goals & constraints**I’d build an active/active multi-homed edge to two ISPs (ISP-A, ISP-B) using BGPv4 with clear objectives: high availability, predictable inbound/outbound traffic engineering, and strict leak prevention.

**High-level architecture**- Two edge routers (or an HA pair) running iBGP between them; eBGP sessions to ISP-A and ISP-B.- IGP (OSPF/ISIS) inside DC; iBGP carries external prefixes with next-hop-self on edges.

**Advertising prefixes (egress from us)**- Advertise only your assigned production prefixes to both ISPs.- Implement route-maps to filter: accept only prefixes in your IRR/RPKI ROAs; set max-prefix limits per session; log rejects.- Announce full prefixes to both for redundancy; use communities to signal ISP-specific behaviors.

**Influencing inbound traffic**- AS_PATH prepend on announcements to make one ISP less-preferred: - To prefer ISP-A inbound: prepend on announcements to ISP-B (e.g., prepend your-AS twice).- Use BGP communities where ISPs support “no-export” or local-preference tuning.- For fine-grain, advertise specific subprefixes (de-aggregation) via preferred ISP where allowed.

**Influencing outbound traffic**- Use local-preference in iBGP to prefer one ISP for certain destination ranges or services: - Route-maps on iBGP/route reflects set local-pref 200 for ISP-A routes, 100 for ISP-B.- Use MED to hint preference when both ISPs are in same AS and honor MED (less common across providers).- Combine with policy-based routing for special flows (e.g., DR/backup, SaaS paths).

**Policy examples**- Default: equal-cost, prefer lower IGP cost for egress, symmetric announcements to both ISPs.- Maintenance: set local-pref lower for ISP under maintenance; advertise more-specifics via other ISP.- Cost-based: weight routes by transit cost using route-maps and AS_PATH prepends.

**Prevent loops & accidental leaks**- Implement strict inbound prefix filters using ISP-provided filters and your IRR + RPKI validation.- Configure prefix-limits and hard/soft thresholds on eBGP sessions.- Use AS-path filters to block your own prefixes from being accepted back.- Use BGP TTL-security (eBGP multihop guarded) and max-prefix.- Remove any default route advertisement internally; ensure iBGP sessions use next-hop-self and proper synchronization is disabled.- Monitor with RPKI/RTR, BGP monitoring (BGPmon/routeviews), and alerting for anomalous announcements.

**Operational controls**- Test changes in maintenance windows; use “no-export” communities for test prefixes.- Automate backup/restore configs and keep playbooks for failover.- Document policies, maintain IRR objects and ROAs, and coordinate with ISPs for community mappings.

This approach balances resilience, predictable TE, and safety against loops and leaks.

Practice Network Engineer questions across all topics

Want to create your own tailored preparation guide using our deep research?

Get Started for Free

Interview-Ready Courses

Visual-first, interactive, structured learning paths

Browse Network Engineer jobs

AI-enriched listings across hundreds of company career pages

Explore Jobs

Amazon Network Engineer (Mid-Level) Interview Preparation Guide

Interview Process Overview

Interview Rounds

Recruiter Screening

What to Expect

Tips & Advice

Focus Topics

Key Projects & Technical Ownership Examples

Practice Interview

Study Questions

Professional Background & Experience Summary

Practice Interview

Study Questions

Motivation for Amazon & Role Alignment

Practice Interview

Study Questions

Technical Phone Screen

What to Expect

Tips & Advice

Focus Topics

Firewall & Security Rules Configuration

Practice Interview

Study Questions

Network Monitoring & Diagnostic Tools

Practice Interview

Study Questions

Network Troubleshooting Methodology

Practice Interview

Study Questions

Network Protocols & OSI Model

Practice Interview

Study Questions

Routing & Switching Fundamentals

Practice Interview

Study Questions

Onsite Round 1: Network Architecture & Infrastructure Design

What to Expect

Tips & Advice

Focus Topics

Redundancy & High Availability Design

Practice Interview

Study Questions

Network Security Architecture

Practice Interview

Study Questions

Network Architecture Design Principles

Practice Interview

Study Questions

AWS Networking Services & VPC Design

Practice Interview

Study Questions

Onsite Round 2: Network Troubleshooting & Operational Deep Dive

What to Expect

Tips & Advice

Focus Topics

Performance Optimization & MTU Issues

Practice Interview

Study Questions

DNS & DHCP Troubleshooting

Practice Interview

Study Questions

Routing Failures & Path Issues

Practice Interview

Study Questions

Firewall & Security Policy Troubleshooting

Practice Interview

Study Questions

Layered Network Troubleshooting (OSI Model Application)

Practice Interview

Study Questions

Onsite Round 3: Network Security & Compliance

What to Expect

Tips & Advice

Focus Topics

Security Incident Response & Monitoring

Practice Interview

Study Questions

VPN & Secure Remote Access

Practice Interview

Study Questions