How would you introduce infrastructure as code for an Azure-hosted product that is currently configured manually in the portal?

Manage cloud infrastructure as code

Uses declarative infrastructure, reviewed plans, environment parameters, protected deployment identities, state management, and drift control without hiding operational risk.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would inventory the current resources and decide clear ownership before writing templates. The desired infrastructure would live in version control as declarative Bicep or Terraform modules, with environment differences supplied through parameters rather than copied templates. Pull requests would validate and preview changes with Bicep what-if or Terraform plan, and a protected pipeline identity would apply the reviewed change. Secrets would be referenced from a secret store instead of committed as parameter values.

Full answer below

Practice focus

Declarative infrastructure, Bicep and Terraform trade-offs, plans, state, modules, environments, secrets, drift, permissions, and safe adoption.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Infrastructure as code turns cloud configuration into a reviewable and repeatable part of delivery. The difficult parts are ownership, state, permissions, migration from existing resources, and the blast radius of an incorrect change.
I would inventory the current resources and decide clear ownership before writing templates. The desired infrastructure would live in version control as declarative Bicep or Terraform modules, with environment differences supplied through parameters rather than copied templates. Pull requests would validate and preview changes with Bicep what-if or Terraform plan, and a protected pipeline identity would apply the reviewed change. Secrets would be referenced from a secret store instead of committed as parameter values.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would split modules around operational boundaries such as networking, data, identity, and application hosting, while keeping dependencies and outputs explicit. Terraform state would be remote, encrypted, access-controlled, backed up, and locked during changes; Bicep relies on Azure Resource Manager state but still needs deployment history and safe scoping. Existing resources would be imported or represented gradually instead of recreated blindly. Portal changes would be restricted, detected as drift, and reconciled back into code after an approved emergency.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I would limit blast radius with separate subscriptions or resource groups, scoped identities, policy checks, and smaller deployment units. With Terraform, the pipeline can save and apply the reviewed execution plan; with Bicep, it deploys the reviewed template revision and repeats what-if immediately before deployment because the preview is not an executable plan. Some infrastructure changes are not transactionally reversible, so recovery can mean a forward fix, data restore, or parallel replacement rather than a generic rollback. I would test modules in disposable environments, exercise teardown where safe, document resources that must be retained, and keep the recovery pipeline available even if the primary environment is unavailable.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Copying one complete template per environment.
Giving the pipeline broad subscription-owner permissions.
Storing Terraform state locally or treating it as ordinary source code.
Running apply without reviewing the actual plan or what-if output.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Manual portal changes are normal and never reconciled into code.
A small application change can replace unrelated databases or networks.
State, secrets, and deployment credentials share the same weak access boundary.
The team assumes every infrastructure operation has a simple rollback.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would you adopt existing manually created resources?
What is different about state management in Terraform and Bicep?
How would you handle an emergency portal change?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.