Interview Preparation

Bicep is a domain-specific language that compiles to ARM JSON templates. It provides a cleaner, shorter syntax with a type system and compile-time validation while targeting the same Azure Resource Manager API as ARM JSON. It is not a wrapper — it produces identical ARM JSON output.

Shorter syntax, explicit type checking, compile-time errors instead of runtime failures, module support without copy-paste, and no JSON schema noise. ARM JSON requires hundreds of lines for what Bicep expresses in dozens.

A parameter is an external input set by the caller at deployment time. A variable is a computed value derived inside the template and not settable by the caller. Parameters make templates reusable; variables keep derived expressions DRY and avoid duplication.

A module is a separate Bicep file that encapsulates a set of related resources. A root template wires modules together by passing parameter values and consuming outputs. Modules enable ownership boundaries and reuse without duplication, similar to functions in programming.

Bicep builds a dependency graph automatically from symbolic references. If resource B references resource A using A.id or A.properties.x, Bicep infers that A must be created before B. Explicit dependsOn is only needed for side-effects not reflected in a property reference.

What-if runs a dry-run of the deployment and shows exactly what changes ARM would make: creates, modifications, deletions, and no-change resources. It is a mandatory safety check before production deploys because it catches unexpected deletes, policy violations, and unintended replacements.

Declare outputs in the provider module (e.g. output subnetId string = vnet.properties.subnets[0].id). In the root template, reference it as networkModule.outputs.subnetId and pass it as a parameter to the consumer module. This creates a clean data contract between modules without hardcoding resource names.

The existing keyword tells Bicep to read an already-deployed resource from Azure without creating or managing it. This lets you reference properties like resource IDs from pre-existing infrastructure (provisioned outside the current template) without taking ownership of that resource in the deployment.

Use for loops to create multiple similar resources from an array, such as deploying N subnets or N storage accounts. Syntax: resource items 'type@version' = [for item in itemArray: { name: item.name ... }]. The output is an array of resources you can reference by index.

Incremental (default) creates or updates resources in the template and leaves any existing resources not in the template untouched. Complete mode deletes any resource in the target scope that is not present in the template. Incremental is safe for most deployments; complete mode is only appropriate when you want the RG to exactly mirror the template and you have reviewed what-if output for unexpected deletions.

Set the targetScope declaration at the top of the file. Options are resourceGroup (default), subscription, managementGroup, and tenant. Subscription-scoped templates can create resource groups and assign policies. Management group scope targets multiple subscriptions. This enables platform teams to provision entire landing zones from a single Bicep hierarchy.

Use @secure() on string parameters for passwords or keys — ARM never logs them. Reference secrets from Key Vault directly using the getSecret() function or by passing a Key Vault secret reference in the parameters file. Never hardcode secrets in the template or parameters file committed to source control.

The state model. Bicep relies on ARM to track deployment state — no external file to manage. Terraform uses an external state file that the team must provision, secure, lock, and back up. Both achieve idempotency but through fundamentally different mechanisms with different operational overhead.

When the organisation operates or plans to operate infrastructure on multiple cloud providers, when the team already has Terraform expertise and tooling at scale, or when unifying non-Azure resources (like DNS or GitHub teams) with Azure infrastructure under one IaC workflow is a priority.

When the platform is Azure-only, when the team does not want the operational burden of managing remote state, when immediate access to new Azure API features matters, or when deep Azure Policy integration is required. Bicep also has no binary to install in CI/CD — Azure DevOps and GitHub Actions have native tasks.

When Azure releases a new AKS feature, networking capability, or resource type, teams using Bicep can use it immediately because Bicep compiles to the ARM API directly. Teams using Terraform must wait for the AzureRM provider to implement support, which can take weeks to months for non-critical features.

List the deployment operations to identify exactly which resources succeeded and which failed. Fix the root cause of the failure. Re-run the deployment in incremental mode — ARM will skip already-created resources and only create or update the missing ones. Never delete and rebuild when a partial deployment exists; understand the state first.

First check whether the cluster's managed identity has the Network Contributor role on the subnet or resource group. This is the most common cause. Also verify the identity type is UserAssigned and the identity resource was deployed before the cluster. Get the failing event with az deployment operation group list and look at the status message.

What-if catches unexpected property changes, unintended deletions (especially in complete mode), and policy violations before any resource is affected. Running it in dev also validates that the what-if gate in prod will work correctly. The command is fast and the cost of skipping it is a production incident waiting to happen.

Start with Azure Verified Modules as the baseline. Create a private Bicep Registry (backed by an Azure Container Registry) for organisation-specific modules with standard naming, tagging, and security configurations pre-applied. Teams consume versioned modules from the registry rather than copy-pasting templates. A platform team owns the registry and reviews module changes through pull requests.

In a well-functioning pipeline: (1) az bicep build on every pull request commit to catch compile errors early, (2) az deployment validate in the dev stage to confirm ARM acceptance, (3) az deployment what-if with a mandatory approval gate before any production target, (4) az deployment create in production with operation-level logs captured and retention policy set. All stages use a service principal or managed identity with least-privilege RBAC.