Amazon Network Engineer (Entry Level) - Comprehensive Interview Preparation Guide

Direct answer
The TCP/IP (Internet) model has four layers: Link, Internet, Transport, and Application. It maps onto the seven-layer OSI model by collapsing OSI's bottom two layers into "Link" and its top three into "Application."

Structured elaboration

Both models describe the same reality; they just carve it up at different granularity. OSI was designed as a general, vendor-neutral reference standard, drawn up before the protocols that would actually win were finalized, so it separates concerns the real internet protocol suite never bothered to split (nothing on the modern internet implements a distinct Session or Presentation layer as its own protocol). TCP/IP is the model that grew directly out of the protocols that were actually built and deployed, so it only has as many layers as the real stack needs to describe.

Worked example
Take a single HTTPS request. In TCP/IP terms: Application layer is HTTPS/TLS+HTTP, Transport is TCP, Internet is IP, Link is Ethernet or Wi-Fi. In OSI terms, the same request spans Layer 7 (HTTP semantics), arguably Layer 6 (TLS's encryption/format role, though in practice TLS libraries sit logically between transport and application), Layer 4 (TCP), Layer 3 (IP), and Layers 2/1 (the local network technology). Neither model is "more correct"; TCP/IP is more useful for describing what's actually running, OSI is more useful for a shared vocabulary when discussing where a NEW piece of functionality should live.

Trade-offs & pitfalls
A common mistake is treating the OSI-to-TCP/IP mapping as one-to-one instead of many-to-one. Session and Presentation don't disappear in TCP/IP, they're just not modeled as distinct layers because no widely deployed protocol maps cleanly onto only one of them. When someone asks "what OSI layer does TLS operate at," the honest answer is "it doesn't map cleanly, and that's expected," not a forced single number.

Situation / cause (why summarization can blackhole traffic)

• Route aggregation can create blackholes in two common ways:
  1. The aggregator installs/announces a summary that points locally (null0 or a wrong next-hop). Upstream routers then send traffic for more-specifics toward the aggregator where they’re dropped.
  2. The aggregator suppresses propagation of the more-specifics (e.g., use of summary-only or policy that filters specifics) so remote peers only see the summary and forward toward the aggregator instead of the true specific next-hop.

How to detect the specific problem

• On the distribution router and affected devices run:
  • show ip route 172.16.8.0/24 — verify which route is in RIB (summary vs specific).
  • show ip bgp 172.16.0.0/20 longer-prefixes — check if specifics exist in BGP table.
  • show ip cef 172.16.8.1 (or traceroute) — find forwarding next-hop and where packets are dropped.
  • debug ip bgp / netflow/sFlow to see ingress nexthops and where traffic goes.
    Look for: summary present with next-hop null0 or local; specifics suppressed/absent from RIB while present on another next-hop.

Configuration and remediation options (preserve reachability, limit table growth)

• Prefer preserving real specifics where needed: selectively advertise or redistribute only the important /24s instead of all specifics.
• Remove summary-only behavior: don’t use aggregate that suppresses specifics. On Cisco: avoid “aggregate-address ... summary-only” or remove equivalent policy.
• Use targeted/conditional aggregation: aggregate only prefixes from a particular upstream or VRF so that other peers still learn specifics.
• Install static host routes or generate-only routes for critical prefixes pointing to correct next-hop (less preferred but surgical).
• Use BGP policy to control reachability without exploding table: tag/communities on specifics so you only advertise those to certain peers; use prefix-lists to export only selected specifics.
• If aggregator must be the advertised owner, use BGP next-hop and attribute tuning (local-preference/AS-path/weight) to steer traffic to the correct path, or use an attribute-map with aggregate-address to preserve ORIGIN or set next-hop correctly.
• Consider BGP add-path or EVPN/L3VPN solutions if you need multiple-path visibility without massive table growth.

Recommendation
Audit where specifics are learned and where the aggregate is advertised. Prefer fixing the export policy (advertise needed specifics or remove suppression) or implement selective advertisement with communities so you keep reachability for critical /24s while still summarizing everything else.

Direct answer
When a deadline, a client, or a business ask pushes toward something that conflicts with a principle a company has committed to, such as privacy, security, or data quality, the strongest answers show three things: you noticed the conflict explicitly rather than complying without registering it, you raised it through the right channel rather than either silently complying or unilaterally blocking the work, and you drove toward a resolution rather than just splitting the difference.

Structured elaboration

• Notice: name the specific moment you recognized the tension, and what concrete detail made you pause.
• Raise it: describe how you raised it, ideally backed by data or a concrete risk rather than an appeal to principle alone. A values-based objection lands far better when it is backed by the actual risk it protects against.
• Navigate: what you actually did in the interim, whether you proposed a compromise or a phased approach, who you looped in, and how you kept the relationship functional even while disagreeing.
• Outcome: what actually happened. An honest outcome, including "I was overruled and here is what I did next," is often more credible than a suspiciously clean win.

Worked example
A team was under pressure to ship a change quickly, and the fastest path meant skipping a validation step that existed specifically to catch a known class of data-quality problem. Rather than quietly skipping it or unilaterally blocking the release, the response was to time-box a reduced version of the validation, checking the highest-risk subset in the time available, and to flag explicitly and in writing what wasn't covered and what the residual risk was, so the decision to accept that risk was made deliberately by the right people rather than by default. The release shipped on time, and the flagged gap was closed within the following two days as agreed, rather than being silently forgotten.

Trade-offs and pitfalls
A story where you unilaterally blocked the work and were later vindicated can read as inflexible if it doesn't also show you understood the business pressure; the strongest answers show empathy for that pressure while still holding the line. A story where you quietly went along with the shortcut is not really an example of this competency at all; the action needs to show you actively surfaced the tension, not merely noticed it internally. Vague appeals to "our values" without a concrete risk attached tend to land weaker than a specific technical or business risk, clearly stated.

Clarify goals & constraints

• Zero/near-zero downtime, full policy parity, maintain stateful behavior for sessions, non-disruptive rollback ability, operate across AZs/segments.

Plan overview

1. Policy discovery & translation

   • Export rules, NATs, IPSets from appliances. Normalize to cloud-firewall constructs. Flag unsupported features and create compensating controls (SGs, WAF rules).

2. Validation via shadowing (mirroring)

   • Use network TAP or switch SPAN to mirror production flows to cloud-managed firewall in passive mode. Validate rule hits, verdict parity, and latency impact.
   • Log and compare decisions over a 2–4 week window; feed mismatches to a policy reconciliation ticket list.

3. Staged cutover (by segment/AZ)

   • Create cutover groups: dev, staging, low-risk AZs, then high-risk AZs.
   • For each group: move one AZ/segment at a time; keep original appliance in path for a warm standby.

4. Traffic steering techniques

   • East-west: update routing (BGP/OSPF) or use policy-based routing to prefer cloud firewall path; use ECMP tie-breakers to control flows.
   • North-south: use DNS with low TTL + weighted records, or update public route table / edge NAT to point to cloud firewall.
   • For stateful continuity: enable session synchronization where possible; use connection drains and keep-alives.

5. Capacity validation

   • Baseline existing throughput/conn/sec. Load-test cloud firewall (synthetic traffic + replayed pcap) to verify headroom and CPU/memory scaling under autoscaling policies.

6. Monitoring & regression detection

   • Monitor KPIs: latency, packet drop rate, connection failure rate, rule hit rates, CPU/memory, auth failures.
   • Implement real-time alerts and dashboards; run automated daily parity reports comparing decisions.

7. Rollback procedures

   • Prebuilt runbook: re-advertise original routes, revert DNS/edge NAT, reinsert appliance inline. Validate connectivity and session re-establishment.
   • Use canary timers: if KPIs breach thresholds within X minutes, trigger automated or manual rollback.

Operational controls

• Change windows, communication plan, runbooks, and a post-cutover audit.

Approach summary
I’d secure BGP by protecting the transport, enforcing strict route acceptance/advertise policies, validating origin with RPKI, using communities and limits to control leaks, and continuously monitoring for anomalies.

Session protection

• Use TCP MD5 or preferably TCP-AO between your routers and ISP-facing peers to prevent spoofed TCP resets and session hijacks. TCP-AO is stronger (per-packet keys, replay protection); ensure both sides support it and manage keys securely (rotate, store in vault).

Route acceptance controls

• Implement strict prefix filtering: accept only prefixes your ISP will advertise (for customer routes) and only expected prefixes from upstream. Use exact prefix-list/route-map objects and export only your assigned prefixes.
• Configure maximum-prefix limits per-session with reasonable headroom and set soft/hard actions (log then shut) to avoid accidental floods.

Origin validation

• Enable RPKI-based Origin Validation (ROA). Prefer “reject” or “de-preference” invalid origins in the RIB/loc-RIB; log and alert on invalids.

Operational controls

• Use BGP communities from ISPs to control prepending, blackholing, or selective announcements. Tag your routes for easy troubleshooting.
• Use NO_EXPORT where appropriate for customer routes to avoid leaks.

Monitoring & detection

• Subscribe to route collectors (RIPE RIS, RouteViews) and run your own collector to detect global announcements of your prefixes.
• Alert on origin ASN changes, unexpected path changes, sudden prefix counts, or ROA invalidations.
• Maintain NetFlow/sFlow and BGP monitoring dashboards, automated playbooks for mitigation (withdraw, contact ISP, ROA fix).

Recommended checklist (multi-homed to two ISPs)

1. Enable TCP-AO with rotated keys on both uplinks.
2. Implement strict inbound prefix-lists per ISP (only expected customer/peer prefixes).
3. Set max-prefix with logging and shut thresholds.
4. Apply outbound filters to advertise only your assigned prefixes.
5. Publish and maintain ROAs; enable RPKI validation.
6. Tag routes with communities for policy control and work with ISPs on community meanings.
7. Deploy route collector monitoring + alerts for origin/prefix changes.
8. Document escalation contacts and run regular BGP hijack drills.

Definition & Purpose
Private VLANs (PVLANs) extend VLAN segmentation by subdividing a primary VLAN into isolated and community secondary VLANs to limit L2 communication while sharing a common gateway. Useful for multi-tenant hosting, public cloud VLANs, and service-provider port separation.

Port Types

• Promiscuous port: Can communicate with all ports in the primary and all secondary VLANs (typically gateway/SVI, firewall, router).
• Isolated port: Cannot communicate with any other secondary port; only with promiscuous ports.
• Community port: Can communicate with other ports in the same community and with promiscuous ports, but not with isolated or other communities.
• Primary VLAN: The overarching VLAN that groups the PVLAN structure.

Traffic Flow

• Isolated -> Promiscuous: allowed
• Isolated -> Isolated (same PVLAN): blocked
• Community A -> Community A: allowed
• Community A -> Community B: blocked
• Any secondary -> Promiscuous: allowed

Use-cases

• Multi-tenant hosting: tenants’ VMs on isolated ports to prevent east-west attacks, shared gateway on promiscuous.
• Service segments: devices in same app tier use community VLANs; backend DB on isolated.
• Hotel/guest Wi‑Fi: guests isolated from each other, can reach internet gateway.

Configuration considerations (SVI/gateway mapping)

• Create primary VLAN SVI for routing and map secondary PVLANs on switch (switchport private-vlan mapping).
• Promiscuous SVI binds to primary VLAN and must be reachable by routing/ACLs.
• For L3 gateway on a router, configure subinterface or SVI on primary VLAN; ensure secondary-to-primary mapping exists on VTP/trunk devices and allowed on trunks.
• Apply ACLs at promiscuous SVI for inter-secondary traffic control and inspect ARP/ARP proxy behavior (some platforms require ARP suppression).
• Ensure trunking supports PVLANs (allow primary and secondary VLAN IDs) and document PVLAN mapping end-to-end.

Overview / short comparison
SNMP polling is pull-based, low-bandwidth but high-latency for many metrics and relies on MIBs; streaming telemetry (gNMI/gRPC + OpenConfig/YANG) is push-based, efficient, supports structured data and near-real-time insight.

Operational benefits (10,000 devices)

• Lower polling overhead and reduced SNMP poll storm risk.
• Near real-time alerts and finer fidelity (event-driven, sampled, or periodic streams).
• Standardized, vendor-neutral models (OpenConfig) improve cross-vendor correlation and automation.
• Better scalability: collectors ingest streams rather than polling each device on schedule.

Tooling & collector changes

• Replace/augment SNMP NMS with gNMI-capable collectors (e.g., Telegraf, Prometheus remote write adapters, OpenConfig-capable collectors like OpenTelemetry agents, gNMI-gRPC proxies).
• Implement message bus (Kafka) for scale, buffering, and replay.
• ETL/normalization layer to map vendor YANG to canonical OpenConfig schema.
• Migration scripts, config management (Ansible/Crosswork) to enable telemetry on devices.

Vendor compatibility risks

• Older devices may lack gNMI or OpenConfig support; require software upgrades, replacements, or SNMP-to-gNMI gateways.
• Partial YANG coverage across vendors necessitates per-vendor mapping and testing.
• Feature parity gaps (some telemetry counters/configs only available via vendor-specific models).

Security implications

• gRPC with TLS + mutual authentication recommended (mTLS).
• Proper cert lifecycle, PKI, and key management at scale.
• Secure collectors (RBAC, hardened endpoints), network-level isolation (VPNs or dedicated management fabric).
• Monitor for data exfiltration; apply rate limits and encryption in transit and at rest.

Observability / telemetry model improvements

• Strongly-typed, hierarchical data (YANG/OpenConfig) enables consistent dashboards, deterministic alerts, and automated remediation.
• Metadata (timestamps, sequence numbers, sensor paths) improves correlation and root-cause analysis.
• Ability to subscribe to state changes reduces blind spots versus periodic SNMP polls.

Migration approach (high level)

• Inventory device capabilities → pilot 100 devices across vendors → deploy collectors and Kafka → run gNMI in parallel with SNMP for 3 months → validate parity, automate onboarding → roll out in waves, retire SNMP where appropriate.

Direct answer

Converting uneven team capacity into a believable delivery forecast means starting from real, not nominal, person-time (accounting for vacations, ramp-up, and hiring timelines), applying a deliberate buffer for the work that always eats capacity but never appears on a roadmap, and taking the resulting gap, not a guess, to leadership as the basis for a headcount or budget ask, before the plan is committed publicly.

Structured elaboration

• Start from nominal capacity, then subtract what's real. Multiply headcount by the planning period to get a nominal ceiling, then subtract planned time off and add back new hires only at their actual ramp rate, since a new hire's first weeks are rarely full productive capacity.
• Apply a buffer. Reserve a deliberate percentage of the remaining time for on-call, meetings, and unplanned work, since a forecast built on 100 percent utilization is fiction and will slip on contact with the first unplanned incident.
• Compare against demand. Convert the committed backlog into the same person-time unit as capacity, and be explicit about the resulting gap or surplus, rather than quietly hoping it works out.
• Get budget or headcount approved without disrupting ongoing work. Bring the specific gap, in the same units used for the forecast, to leadership before committing to the plan, with named options to close it (added headcount, a contractor, or an explicit scope cut), so the ask is a concrete trade-off decision rather than an open-ended request.

Worked example

A team of 5 engineers is planning a 12-week quarter, a nominal 60 person-weeks of capacity.

• One planned parental leave removes 6 person-weeks: 60 minus 6 equals 54.
• A new hire joins in week 7, ramping at 50 percent for their first 4 weeks (2 effective person-weeks) and full speed for the final 2 weeks of the quarter (2 effective person-weeks), adding 4 effective person-weeks rather than the 6 nominal weeks a fully ramped person would contribute in that span: 54 plus 4 equals 58 raw available person-weeks.
• Applying a 20 percent buffer for on-call, meetings, and unplanned work: 58 times 0.8 equals about 46 committed person-weeks.
• The backlog the team has been asked to deliver this quarter is estimated at 55 person-weeks.
• Gap: 55 minus 46 equals 9 person-weeks short, about 16 percent of demand.

Taken to leadership before the quarter's plan is finalized: either fund a contractor for roughly 9 person-weeks of the quarter, or agree explicitly on which 9 person-weeks of backlog move to next quarter. Either way, the decision is made and documented before the roadmap is communicated externally, not discovered mid-quarter.

The same convert-to-forecast-plus-buffer discipline applies when the constrained resource is infrastructure rather than headcount. For a network capacity plan forecasting 40 percent annual traffic growth, the same shape holds: convert the growth forecast into a specific utilization threshold (for example, an upgrade trigger at 70 percent link utilization on a given segment), stage the capital request into phased upgrades tied to when each segment is projected to cross that threshold instead of one lump-sum ask, and get each phase approved on its own timeline so operations are never disrupted by an all-at-once cutover.

Trade-offs and pitfalls

The most common mistake is planning off nominal headcount times weeks, without subtracting real ramp-up and time-off effects, which produces a forecast that looks fine on a spreadsheet and fails the first month. A second mistake is presenting the gap as a vague concern rather than a specific number with named options, which makes it easy for leadership to defer a decision until the shortfall is already a missed commitment. Building in too large a buffer is its own failure mode: an overly conservative estimate under-promises capacity the team actually has and can erode trust in future forecasts just as much as an overly optimistic one.

Approach (goal)

Prefer ISP‑A for outbound (egress) while allowing inbound steering via communities and AS‑path prepending to influence remote selection. Use local‑pref to select egress, AS‑path prepend to make routes via ISP‑B less attractive to peers, and accept ISP communities to let them signal preferred ingress.

Outbound control (local‑pref)

• Import routes learned from both ISPs.
• Apply a route‑map that sets higher local‑preference for routes received from ISP‑A.
• Example (Cisco IOS):

route-map SET-LOCALPREF-ISP-A permit 10
 match ip address prefix-list MY-PREFIXES
 set local-preference 200
!
route-map SET-LOCALPREF-ISP-B permit 10
 match ip address prefix-list MY-PREFIXES
 set local-preference 100
!
router bgp 65000
 neighbor X.X.X.X route-map SET-LOCALPREF-ISP-A in  ! ISP-A
 neighbor Y.Y.Y.Y route-map SET-LOCALPREF-ISP-B in  ! ISP-B

Inbound control (AS‑path prepend + communities)

• Use AS‑path prepending on announcements to ISP‑B to make that path longer so remote ASes prefer ISP‑A.
• Allow customer‑provided communities from peers (if supported) so specific upstreams can steer traffic. Example:

route-map PREPEND-TO-ISP-B permit 10
 set as-path prepend 65000 65000 65000
!
neighbor Y.Y.Y.Y route-map PREPEND-TO-ISP-B out

• For fine‑grained inbound steering, tag routes with community values ISP-A/ISP-B provide (e.g., NO_EXPORT, prefer-this‑peer) and apply when advertising.

Testing & Validation

• Verify RIB/BGP: show ip bgp neighbors, show bgp routes and local-pref values.
• Check outbound path: traceroute to external destinations; confirm egress via ISP‑A.
• Validate inbound influence: from public looking glasses / RIPE NCC, check AS‑path and which ISP origin peers choose.
• Use traffic captures (NetFlow/sFlow) at PE to confirm actual egress ratios.
• Staged rollout: apply to a subset of prefixes, monitor for 24–72 hours, then expand.
• Monitor BGP convergence and check for unintended route flaps.

Tradeoffs / Notes

• Upstream policies may override attempts to steer; coordinate with ISPs and document accepted communities.
• Prepending is heuristic — not deterministic for all peers; communities are more reliable when supported.

Direct answer

Choosing between deliberately degrading a lower-priority business function and letting congestion continue unmanaged is a business-impact decision dressed as a technical one, and treating it that way, gathering the SAME evidence and approvals you would for any consequential business trade-off, rather than making the call alone as a purely technical judgment, is what actually protects both the business and yourself.

Structured elaboration

1. Assess business impact concretely, not just technically: quantify, as precisely as time allows, what "lower-priority business function" actually means in revenue, customer, or SLA terms, and compare that against the projected impact of continued, unmanaged congestion (which customers, which SLAs, how much revenue) so the decision is grounded in comparable, concrete terms rather than a vague technical instinct about which is "worse."
2. Identify who actually needs to be involved in this decision: this is not purely a network-engineering call, since it deliberately trades one business function's degradation for another's protection; the OWNERS of the function being degraded need to be consulted or at minimum informed before the decision is executed, not after, given they're the ones who can best assess whether that specific trade-off is acceptable from their side.
3. Determine what approvals are actually required, and get them BEFORE acting where the timeline allows: for a decision with this level of business consequence, a single network engineer unilaterally choosing which business function to sacrifice, without any sign-off from someone with the authority and context to weigh that trade-off, is a governance gap; if the situation is severe enough that waiting for approval risks worse outcomes, have a PRE-AGREED escalation path for exactly this kind of emergency decision, rather than improvising the approval process live for the first time during the incident.
4. Communicate proactively to affected stakeholders and customers, not just internally, framing what's being deprioritized and why, ideally BEFORE they notice the degradation themselves rather than only reactively once they report it.
5. Build in an explicit rollback plan and trigger condition: define in advance what condition would cause you to REVERSE the traffic-shaping decision (the primary congestion resolving, or the "lower-priority" function's degradation turning out to be worse than expected), rather than treating the shaping decision as a one-way, unmonitored action.
6. Document for post-incident review: capture the reasoning, who was consulted, what alternatives were considered, and what the actual measured impact was on both sides of the trade-off, since a decision this consequential deserves a thorough after-the-fact review regardless of how it turns out.

Worked example

Applying traffic shaping specifically to a batch-reporting feature (assessed as lower-priority, with a known, currently-acceptable SLA for delay) to protect the primary customer-facing transactional service from congestion-driven failures: before applying, I'd confirm the batch-reporting feature's OWNER agrees this specific SLA hit is acceptable given the alternative, get a quick sign-off from an on-call incident commander or equivalent authority given the time pressure, notify affected stakeholders proactively with a specific expected duration, and set an explicit trigger (once transactional congestion drops below a defined threshold) to lift the shaping.

Trade-offs & pitfalls

Making this kind of decision unilaterally, purely as a technical judgment call, without involving the people who actually own the function being sacrificed, is a common failure mode under time pressure; even a brief, fast consultation is usually better than none, and a pre-agreed emergency-escalation path removes the need to improvise that process for the first time during a live incident. Skipping proactive communication in favor of just acting and explaining later, if at all, damages trust with the very stakeholders whose function you just deprioritized on their behalf.