Alex Here - Blog

What I Learned About Infra Interviews Last Weekend

· Alex Here· 4min read· 731 words

Last Saturday I met up with a senior of mine who’d been grinding away at their infrastructure interview prep. We chatted and he started walking me through what he’d been studying—different scenarios, real interview questions he’d encountered, the whole process.

I was honestly surprised by how realistic everything was. These weren’t textbook “what is TCP” questions. The scenarios had constraints, trade-offs, incomplete information. Just like actual industry production.

What hit me hardest was realizing how hard this actually is. I’d assumed infra interviews were about knowing your tools and protocols. But watching my senior work through these scenarios, I saw how much it demands—systems thinking under pressure, knowing what to ignore and what to investigate first. It’s not just knowledge. It’s judgment.

So I went home and pulled together the resources I found online. Here’s what I found, organized by level.

Level 1: CCNA Scenario Questions — The Foundation

Before you can architect cloud systems or debug Kubernetes clusters, you need to understand networks. The scenario-based CCNA questions cover the bread-and-butter stuff: IP addressing, subnetting, VLAN configuration, and basic routing with OSPF and EIGRP.

What makes these useful is the scenario format. Instead of “what is a VLAN?” you get “a user in VLAN 10 can’t reach a server in VLAN 20—walk me through your troubleshooting steps.” This forces you to think through the actual configuration and troubleshooting process, not just recall definitions.

The security sections are solid too—port security, ACLs, wireless configuration. Even if you’re not going for a pure networking role, every DevOps engineer eventually hits a point where “it’s a network problem” becomes their responsibility to solve.

Good for: Solidifying fundamentals, junior-to-mid roles, anyone who feels shaky on networking basics.

Level 2: AWS Scenario Questions — Cloud-Native Thinking

Once you have the networking foundation, cloud scenarios add the layer of managed services and distributed architecture. The AWS scenario-based questions focus on real-world problems: designing VPC architectures, handling multi-AZ failover, optimizing costs while maintaining availability, integrating Lambda with S3 and EC2.

These scenarios force you to think about trade-offs. Cost versus availability. Latency versus consistency. Security versus convenience. That’s exactly what infrastructure interviews test now—can you design something that works under constraints, not just something that works in a demo environment.

The integration scenarios are particularly good. How do you handle event-driven architectures? What’s your approach when a Lambda function needs to process millions of S3 uploads? These aren’t textbook questions—they’re problems people actually face.

Good for: Cloud engineers, DevOps roles, anyone working with AWS infrastructure.

Level 3: Advanced Networking — The Deep Dive

The advanced networking interview questions move past configuration into architecture and troubleshooting at scale. Think TCP/IP stack behavior, asymmetric routing, packet-level analysis, BGP decision-making.

These aren’t questions you can fake with surface knowledge. When someone asks you to explain why TCP slow start matters in high-latency environments, or how you’d diagnose intermittent packet loss in a multi-hop path, you either know it or you don’t.

The value here is in the depth. Senior infrastructure roles expect you to understand why things work, not just that they work. When your application is slow, can you determine if it’s DNS, TCP congestion, routing asymmetry, or something else entirely?

Good for: Senior/staff roles, network engineers, SRE positions where you’re expected to debug anything.

What I’m Taking Away

Going through these resources highlighted gaps I didn’t know I had. I can spin up an EC2 instance and configure a VPC, but ask me to optimize network topology for cross-region latency and I’m making educated guesses. I know what TCP does, but ask me about specific congestion control algorithms and I start reaching.

The pattern across all three levels is clear: modern infra interviews test problem-solving under constraints. They want to see your process—how you break down ambiguous problems, what you check first, how you validate your assumptions.

My plan now is to work through scenarios from each level, not just read them. Actually draw out network diagrams. Write sample troubleshooting runbooks. Think through the failure modes and how I’d detect them. That’s the difference between knowing about something and knowing how to use it.


Resources mentioned: