The Genius of `resourceGroup().location`: Writing Bicep That Adapts to Reality

Mid/Senior Engineer Asked at: Microsoft, any company on Azure

Q: How do you design Bicep templates to be portable and context-aware, specifically regarding resource location, without requiring complex parameter files?

Why this matters: This is a question about elegance and leverage. The interviewer is testing if you can write code that is not just functional, but intelligent. Can you design a system that reduces its own configuration surface by being aware of its environment?

Interview frequency: High. This separates candidates who write scripts from those who design systems.

❌ The Death Trap

The candidate defaults to the most basic answer: just make everything a parameter. They solve the problem but miss the opportunity to demonstrate a deeper, more elegant architectural pattern.

"I would just create a parameter for location, like `param location string`. Then, for each environment, I would have a different parameter file, like `eastus.bicepparam`, that sets the location to 'eastus'. You pass that in during deployment."

This is a correct but brute-force solution. It creates operational overhead (managing multiple parameter files) and misses the core insight that the deployment target *already knows* its location.

🔄 The Reframe

What they're really asking: "How do you leverage the inherent context of the target environment to create self-configuring templates? Can you use Bicep's functions to make your infrastructure code smarter and less dependent on external configuration?"

This reframes the question from simple parameterization to a more advanced topic: creating intelligent, context-aware systems that reduce human error and cognitive load.

🧠 The Mental Model

The "Chameleon Template" model. A good template shouldn't be a rigid, monochrome object. It should be a chameleon that automatically adapts its color (location) to its surroundings (the Resource Group).

1. The Brittle Template: A template with a hardcoded `location = 'eastus'` is a rock. It can only ever exist in one place. This is a liability.

2. The Naive Template: A template with a mandatory `param location string` is a blank slate. It requires the user to know and provide the context every single time. This shifts the burden but doesn't solve it.

3. The Chameleon Template: A template that uses `param location string = resourceGroup().location` is intelligent. Its default behavior is to blend in with its surroundings. It doesn't need to be told where it is; it discovers its own context.

📖 The War Story

Situation: "I was on a platform team responsible for providing a standard 'web app + database' Bicep template for dozens of development teams across the globe."

Challenge: "Our teams were deploying to resource groups in multiple Azure regions for data sovereignty and latency reasons—`East US`, `West Europe`, `Australia East`. Our 'reusable' template had a mandatory `location` parameter. This led to a constant stream of support tickets and deployment failures because developers would forget to create a `westeurope.bicepparam` file, or they'd accidentally deploy a European service to a US resource group by using the wrong parameter file."

Stakes: "This wasn't just an annoyance; it was a source of real risk. An accidental cross-region deployment could violate GDPR. The cognitive overhead of managing location parameters was slowing down every team and creating unnecessary friction."

✅ The Answer

My Thinking Process:

"My first principle was to reduce the number of decisions a developer has to make. The location of a resource is rarely an arbitrary choice; 99% of the time, it should match the location of the resource group it lives in. The template should enforce this 'common sense' by default. The solution wasn't better documentation; it was a smarter template."

What I Did: From Naive to Chameleon

I refactored our template to be context-aware by making one simple, powerful change. I changed our `location` parameter to use a default value provided by the `resourceGroup()` Bicep function.

The Old, Naive Way:

// Requires the user to always know and provide the location.
param location string
            

The New, Intelligent Way:

// The template discovers its own location by default.
param location string = resourceGroup().location
            

I explained to the team that `resourceGroup()` is a function that gives the Bicep template a form of self-awareness. It can inspect the properties of its deployment target. By setting the `location` parameter's default value to `resourceGroup().location`, we were telling the template: "By default, exist where you are being deployed."

The Outcome:

"This single line of code eliminated an entire class of human error. We removed the need for location-specific parameter files for 99% of our use cases. Developer velocity increased because the 'right' thing to do was now the *automatic* thing to do. The template became truly portable; we could hand the same file to a team in the US or Europe, and it would just work, adapting to its local context."

What I Learned:

"I learned that the best code isn't just code that works; it's code that reduces cognitive load. The `resourceGroup().location` function is a perfect example of this. It's a simple piece of syntax that embodies a powerful architectural principle: leverage the context of your environment to create self-configuring systems. It's the difference between building a tool and building an intelligent agent."

🎯 The Memorable Hook

"A dumb template forces you to tell it where it is. A smart template asks the room. The most elegant code is aware of its own context."

This connects a specific technical feature to the first-principles concept of self-awareness and context, demonstrating a deeper architectural insight.

💭 Inevitable Follow-ups

Q: "What if you have a legitimate use case where a resource needs to be in a different region from its resource group, for example, a central logging workspace?"

Be ready: "That's the beauty of using a default value instead of hardcoding it. The `resourceGroup().location` provides a smart, 99% correct default. But because it's still a parameter, a user with a specific need can always override it by providing an explicit value in a parameter file or on the command line. It provides a 'paved road' for the common case without blocking the 'off-road' exception."

Q: "What are some other context-aware functions in Bicep you find valuable?"

Be ready: "The `subscription()` and `tenant()` functions are equally powerful. `subscription().subscriptionId` allows you to construct fully-qualified resource IDs without hardcoding the subscription, making templates portable across different Azure subscriptions. Similarly, `tenant().tenantId` is essential for configuring identity and access management resources that are tied to the specific Azure Active Directory tenant."