The Architect's First Five Decisions: Why Creating an Azure VNet is a System Design Interview
Q: You're leading a new project to build a GDPR-compliant analytics service for your company's European customers. Before any code is written, you need to establish the foundational network in Azure. Walk me through the VNet creation wizard and justify your choices.
Why this matters: They're not testing your ability to click buttons in a UI. They're testing your strategic thinking. The VNet wizard is a series of long-term, high-consequence commitments. This question reveals if you understand the weight of these decisions.
Interview frequency: High. This is the "Hello, World!" of cloud architecture interviews.
❌ The Death Trap
The unprepared candidate treats this like a driving test, narrating their clicks without explaining the rules of the road. They describe *what* they are doing, but not *why* it's the correct—or only—choice.
"Most people say: 'First, I'll choose a subscription. Then I'll make a new resource group called 'test-rg'. I'll name the VNet 'my-vnet' and pick a region, like North Europe. I'll accept the default IP address and subnet, then click create.'"
This answer is a fatal error. It shows a lack of deliberation, communicates zero understanding of business constraints, and treats irreversible decisions like casual choices.
🔄 The Reframe
What they're really asking: "Prove you understand that a VNet is not a resource, but a contract. Justify the five foundational clauses of that contract: Billing, Organization, Location, Territory, and Zoning."
This reveals your ability to connect abstract business requirements (like GDPR) to concrete technical choices (like a region). It shows you think about cost, management, and physical reality, not just virtual machines.
🧠 The Mental Model
The VNet creation screen isn't a form; it's a blueprint for a new digital facility. These are the Architect's First Five Decisions.
This isn't just a dropdown. This is the financial commitment. It dictates who pays for every CPU cycle and every byte transferred within this network. Choosing the right one is about cost allocation and budget ownership.
This defines the lifecycle. A Resource Group is a container that bundles resources for management. Everything in it can be deployed, managed, and, most importantly, *deleted* together. This decision is about operational sanity.
This is the most profound physical decision. You are choosing a specific data center in a specific country. This impacts latency for your users, data sovereignty for compliance (like GDPR), and availability. It anchors your virtual world to a physical place.
This is the hardest decision to reverse. You are claiming a private territory in the vastness of the internet. It must be large enough for future growth and unique enough not to conflict with any other network you might connect to (like your on-premise network). A mistake here is catastrophic.
This isn't just a "default." It's the first plot of land you're zoning for a specific purpose. You are carving out a piece of your larger territory and giving it a specific role, preparing it for your first set of resources.
📖 The War Story
Situation: "We were launching a new GDPR-compliant analytics service for our German customers. I was tasked with creating the foundational infrastructure in Azure."
Challenge: "The two non-negotiable constraints were latency and data residency. All customer data had to remain within German borders, and the experience needed to be fast for users in Berlin and Frankfurt."
Stakes: "A wrong choice on the Region meant an immediate violation of GDPR, leading to massive fines. A wrong choice on the IP space could have crippled our ability to connect this service back to our corporate network later."
✅ The Answer
My Thinking Process:
"I'd approach the VNet creation wizard not as a series of fields to fill, but as a checklist of foundational commitments. My entire focus would be on satisfying the business constraints of GDPR and latency."
What I Did:
"Here's how I would walk through it, justifying each of the five architectural decisions:"
1. Subscription: "I'd select our `Production-EU` subscription. This ensures the costs are correctly billed to our European business unit."
2. Resource Group: "I'd create a new one named `rg-analytics-de-prod`. This naming convention (resource-workload-region-environment) allows us to instantly identify its purpose and manage its lifecycle. If we decommission the service, we delete the RG, and everything vanishes."
3. Region: "This is the most critical choice. I'd select `Germany West Central`. This is a hard requirement from the GDPR constraint, ensuring data residency. It also provides the lowest possible latency to our target users."
4. IP Address Space: "I'd define the space as 10.40.0.0/16. I'd first check with our central networking team to ensure this range doesn't overlap with our existing on-premise networks or other VNets. A /16 gives us over 65,000 IPs, providing ample room for future expansion."
5. Subnet: "I wouldn't accept the name 'default'. I'd rename it to snet-webtier-prod-01 and assign it a smaller range like 10.40.1.0/24. This is intentional zoning. It clearly designates this subnet for our web servers and leaves the rest of the address space available for other tiers, like application and data subnets."
"After making these five deliberate choices, I would review and create the network."
What I Learned:
"The fact that an Azure VNet itself is free is a powerful lesson. The cloud doesn't charge you for making a plan; it charges you for executing it. The most valuable work in cloud architecture happens at the blueprint stage, and the VNet is the master blueprint."
🎯 The Memorable Hook
"In the cloud, you can change your code every minute, but you can't easily move your country. Choose your VNet's Region and IP space as if they are permanent, because for practical purposes, they are."
This shows you understand the difference between ephemeral and permanent decisions in cloud architecture. It demonstrates a maturity that goes beyond just technical details.
💭 Inevitable Follow-ups
Q: "You mentioned the VNet is free. What are you actually charged for, then?"
Be ready: "You're charged for the resources *within* the VNet and the *traffic* that flows through it. Things like VMs, Load Balancers, VPN Gateways, and data transfer costs. The VNet is the city plan; you pay for the buildings and the traffic on the roads, not the plan itself."
Q: "What happens if you choose an IP address space that later conflicts with your on-premise network when you try to connect them?"
Be ready: "That's a nightmare scenario and a classic architectural failure. You can't directly connect them. The 'fix' is incredibly painful: you must build an entirely new VNet with a correct IP range and migrate every single resource into it, which involves downtime and significant engineering effort. This is why Decision #4 is so critical."
