A senior engineer’s guide to balancing Azure’s portal convenience with IaC discipline. Learn practical strategies to prevent configuration drift and manage your team’s workflow without losing your mind.

IaC vs. The Portal: My Line in the Azure Sand

I still remember the pager alert. It was a Tuesday, 3:00 AM. A high-severity security alert fired because a critical production database, prod-sql-aurora-01, suddenly had its public network access enabled. Total panic. We dug in, and the root cause was as simple as it was infuriating. A junior engineer, trying to debug a connection issue for a new BI tool, had “temporarily” opened the firewall rule in the Azure Portal. He swore he’d close it right after. He didn’t. What’s worse is that our nightly Terraform pipeline ran, saw the manual change as drift, and dutifully “fixed” it by reverting it. The security scanner, however, caught it in that 15-minute window of exposure. That incident cost us a week of security audits and a lot of lost sleep. It perfectly illustrates the tug-of-war every Azure team faces: where do you draw the line between Infrastructure as Code (IaC) and the convenience of the portal?

The Root of the Problem: Speed vs. Stability

Let’s be honest, the conflict exists for a good reason. The Azure Portal is fantastic for discovery, learning, and quick, one-off troubleshooting. You can visualize network security groups (NSGs), click through settings, and figure out what you need. It’s fast. IaC tools like Terraform, Bicep, or ARM templates, on the other hand, are built for consistency, repeatability, and safety. They are the source of truth for your production environment.

When you mix the two without a clear strategy, you get configuration drift. The state of your live environment no longer matches the state defined in your code. This is how outages happen. This is how security vulnerabilities sneak in. The portal becomes a source of lies, and your IaC becomes a weapon that can undo critical, undocumented “fixes.”

A Word of Warning: Configuration drift is the silent killer of cloud environments. Every manual change is a ticking time bomb, waiting for the next automated pipeline run to detonate it.

So, how do we manage this without becoming the “Department of No”? Here are three strategies I’ve used, ranging from a quick band-aid to a full cultural shift.

Solution 1: The “Break-Glass” Protocol (The Quick Fix)

This is the most realistic starting point for most teams. You acknowledge that emergencies happen and sometimes a change must be made in the portal immediately. But you wrap it in a strict, non-negotiable process.

This is a “hacky” fix because it relies entirely on human discipline, but it’s a thousand times better than nothing. The process looks like this:

1. Declare an Incident: A P1/P2 ticket is created. This isn’t just a casual change; it’s a formal incident.
2. Get Approval: A team lead or manager must approve the manual intervention in the ticket. This creates an audit trail.
3. Make the Manual Change: The on-call engineer makes the required change in the Azure Portal.
4. Backport to Code Immediately: This is the most critical step. The incident ticket cannot be closed until a new task is created, assigned, and prioritized to get that exact same change reflected in the IaC source code. The goal is to have the change in your `main` branch within hours, not days.

This creates friction on purpose. It makes using the portal for changes painful enough that people will only do it when absolutely necessary.

Solution 2: The “Immutable Sandbox” Strategy (The Permanent Fix)

This is where we want to live. The core principle is simple: your core environments (staging, production) are effectively immutable from the portal. Your team’s permissions reflect this.

• Production/Staging Subscriptions: Developers and most engineers get Reader access. That’s it. They can look, but they can’t touch. Only the CI/CD service principal has Contributor rights to apply IaC changes.
• The Sandbox Subscription: You create a separate “dev” or “sandbox” Azure subscription (or at least a resource group) where your team gets Contributor access. This is their playground. They can click, create, destroy, and learn in the portal to their heart’s content.

When a developer needs to figure out how to configure, say, an Azure App Service with a private endpoint, they do it in the sandbox. Once they have a working configuration, their “deliverable” isn’t the resource itself—it’s the Bicep or Terraform code that creates it. That code then goes through a proper pull request and pipeline deployment to the real environments.

You can enforce this with Azure Policy, creating rules that deny manual resource creation or modification in protected subscriptions. Here’s a conceptual policy snippet that could, for instance, deny updates to NSGs unless initiated by your service principal:

{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Network/networkSecurityGroups"
        },
        {
          "field": "name",
          "like": "prod-*"
        },
        {
          "not": {
            "field": "identity.principalId",
            "equals": "YOUR_CICD_SERVICE_PRINCIPAL_ID"
          }
        }
      ]
    },
    "then": {
      "effect": "deny"
    }
  }
}

Solution 3: The “Drift Detection” Hammer (The ‘Nuclear’ Option)

Sometimes, you inherit a messy environment or you just can’t get the discipline right. In these cases, you can’t prevent the drift, so you must aggressively detect and report it.

The idea is to set up an automated job (e.g., in Azure DevOps Pipelines, GitHub Actions) that runs on a schedule—say, every hour. This job’s sole purpose is to run a read-only IaC command against your live environment and compare it to your code.

For Terraform, this would be:

terraform init -reconfigure
terraform plan -detailed-exitcode

The -detailed-exitcode flag is key. It returns an exit code of `2` if there is drift. Your automation can catch this and immediately fire a high-priority alert into a Slack channel, Teams, or PagerDuty. The message would be something like: “DRIFT DETECTED in `prod-networking`! A manual change was made outside of Terraform. Revert immediately!“

This is “nuclear” because it can be noisy, but it makes any manual change impossible to hide. It forces the conversation and makes the “invisible” problem of drift painfully visible to the entire team.

Choosing Your Strategy

There’s no single right answer, and many teams use a hybrid approach. Here’s how I see them stacking up:

My advice? Start with the “Break-Glass” protocol today. It’s just documentation. While you’re practicing that discipline, work on implementing the “Immutable Sandbox” strategy. That’s your north star. If you’re in a real mess, the “Drift Detection” hammer can be a powerful tool to force the change. The portal is a tool, not a crutch. Use it for what it’s great at—discovery—but let your code be the undeniable source of truth.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions