Azure administrators eventually reach a point where clicking through the portal is too slow and too inconsistent. Infrastructure as code solves that problem by turning resource configuration into a repeatable deployment artifact. For the AZ-104 exam, the important skill is not becoming a full-time Bicep developer. It is understanding how Azure Resource Manager processes deployments, how Bicep relates to ARM templates and how to make repeatable changes without accidentally replacing or deleting resources.
Bicep and JSON ARM templates describe the desired resources and properties. Azure Resource Manager evaluates that declaration at a deployment scope and creates or updates resources. This makes infrastructure reviewable, versionable and automatable, but it also means an administrator has to understand scope, parameters, dependencies, deployment behavior and permissions.
Bicep is a language for Azure Resource Manager deployments
Bicep provides a cleaner authoring syntax for the same Azure Resource Manager capabilities available through JSON templates. It supports resources, parameters, variables, outputs, modules, conditions and loops without requiring authors to manage the more verbose JSON structure directly.
The deployment engine is still Resource Manager. That matters because RBAC, scopes, provider operations and resource API versions continue to control what happens. Bicep does not bypass Azure governance; it gives the administrator a more maintainable way to describe the deployment.
Microsoft recommends Bicep for many Azure infrastructure-as-code scenarios because it preserves ARM capabilities while making templates easier to read. Within the broader Microsoft Azure infrastructure certifications family, this skill bridges day-to-day administration and the more architecture- and DevOps-oriented work of standardizing environments.
Parameters separate reusable structure from environment-specific values
A useful template should not hard-code every detail. Parameters allow the same Bicep file or ARM template to be deployed into different environments with different names, locations, sizes or feature selections. Defaults can simplify routine use, while allowed values and validation reduce accidental input errors.
The design goal is not to parameterize everything. Excessive parameters turn a template into a difficult form rather than a reusable definition. Stable architectural choices can remain in the template, while values that genuinely differ by environment or deployment should be parameters.
Parameters can also contain sensitive values, but secrets should not be casually stored in source files or parameter files. Mature designs retrieve secrets from appropriate secure stores or use identities so that the deployment does not need to carry long-lived credentials.
Modules keep large deployments understandable
As infrastructure grows, a single template can become hard to read and hard to reuse. Bicep modules allow related resources to be grouped into smaller units. A network module can define a virtual network and subnets, while another module handles monitoring or compute resources.
Modules also create clearer ownership boundaries. A platform team can maintain a secure networking module while application teams consume it with approved parameters. That does not remove the need for policy or review, but it reduces copy-and-paste drift across environments.
For AZ-104, the practical lesson is that declarative deployment should make operations more repeatable. If a template becomes so abstract that administrators cannot predict its effect, it has defeated part of its purpose.
Dependencies determine deployment order
Resource Manager can deploy independent resources in parallel, but some resources depend on others. A network interface may need a subnet, or a virtual machine may need a network interface and disk configuration. Bicep can infer many dependencies from resource references, reducing the need for explicit dependency declarations.
Understanding dependencies helps troubleshoot deployment failures. If a child resource fails because its parent was not created correctly, rerunning random steps in the portal hides the actual problem. Reviewing the dependency relationship and the failed deployment operation leads to a more reproducible fix.
Outputs can also pass important resource values to another stage or module. This supports composition without hard-coding resource IDs that differ across subscriptions and resource groups.
Deployment scope changes what the template can control
Azure deployments can target resource-group, subscription, management-group and tenant scopes. The correct scope depends on the resources being created. A template that creates ordinary workload resources usually targets a resource group. A governance deployment might create policy assignments or resource groups at a broader scope.
Permissions must match the deployment. The caller needs rights to the resources being created and to the deployment operation itself. A valid template can still fail when the deployment identity lacks an action required by one resource provider.
This is another place where infrastructure as code intersects governance. Templates express desired state, but RBAC and Azure Policy still determine whether the caller is allowed to create that state.
Incremental deployment is the normal mental model
In incremental mode, Resource Manager creates resources in the template and updates matching resources while leaving unrelated resources in the resource group alone. That makes it the recommended general deployment behavior. It does not mean that omitted properties on a resource are always preserved; when a resource is redeployed, the declared properties and service defaults still matter.
Historically, complete mode could delete resources not represented in the template. Microsoft now recommends deployment stacks for scenarios that intentionally manage deletion rather than relying on complete-mode behavior. The operational point is simple: never assume a deployment only adds things. Understand how it will treat existing state.
That caution is especially important in shared resource groups. A deployment artifact should have a clear ownership boundary so that one team’s automation does not unexpectedly change another team’s resources.
Use what-if before making consequential changes
The Resource Manager what-if operation previews how a Bicep or ARM deployment is expected to change Azure resources without applying those changes. It can show resources that would be created, modified or removed, giving administrators a chance to catch unintended effects.
What-if is valuable in automated pipelines as well as interactive administration. A reviewer can see the infrastructure delta before approval. The preview is not a substitute for testing because service behavior and runtime dependencies still matter, but it reduces the risk of deploying a template whose scope or parameters were misunderstood.
The habit aligns with the operational mindset described in the site’s Azure administrator role coverage: predictable change matters more than simply knowing that a command exists.
Idempotence is a practical goal
Infrastructure as code is most useful when rerunning a deployment converges toward the desired configuration instead of creating unpredictable duplicates. Resource names, references and declarations should therefore be designed so that repeated execution is safe.
Not every service operation is perfectly stateless, and external systems may introduce side effects, but the template itself should be as deterministic as possible. Avoid scripts that make hidden changes unless those changes are necessary and well controlled. The more configuration is expressed declaratively, the easier it is to compare intended and actual state.
Version control completes the model. A template change can be reviewed, associated with an incident or release and rolled forward in a controlled way. Portal-only changes are much harder to reconstruct later.
Troubleshoot deployments from the resource operation outward
When a deployment fails, inspect the failed operation and error details. Determine whether the problem is syntax, an invalid property, an API-version mismatch, a naming or location restriction, an unmet dependency, RBAC or Policy. The deployment record is usually more informative than repeatedly trying the same template.
Also remember that a successful deployment does not prove the workload is healthy. A VM can deploy successfully and still have an application failure. A network can be created correctly and still have the wrong route for the application. Infrastructure deployment validation and workload validation are different layers.
The broader cloud architecture certification path treats infrastructure as code as a design and governance capability. AZ-104 keeps the emphasis practical: deploy Azure resources consistently, preview changes and know how to diagnose the deployment when something goes wrong.
For AZ-104, focus on predictable administration
A good exam-day sequence is to identify the target scope, decide which values should be parameters, understand the resource dependencies, verify permissions and Policy, preview the deployment where appropriate and then inspect deployment history if a change fails.
That is more useful than memorizing Bicep syntax line by line. The administrator’s responsibility is to make Azure changes repeatable and safe. Bicep and ARM templates are tools for achieving that operational discipline.
Validation should happen before and after deployment
Infrastructure-as-code workflows benefit from several layers of validation. Syntax and type checks catch authoring mistakes. The Resource Manager what-if operation previews expected changes against the target environment. Policy and RBAC determine whether the deployment is permitted. After deployment, resource health and application checks confirm that the resulting environment actually works.
These layers answer different questions. A template can be syntactically valid but blocked by Policy. It can pass Policy and still fail because a resource provider rejects a property or quota is exhausted. It can deploy successfully and still produce an application that cannot reach a dependency. Treating “deployment succeeded” as the final validation state hides those distinctions.
Deployment history is valuable evidence because it records operations and failures associated with a deployment. Administrators should use that record to understand what Resource Manager attempted rather than reconstructing events from memory. Combined with source control, this creates an auditable chain from template change to deployed resource state, which is one of the strongest operational reasons to prefer infrastructure as code over repeated manual configuration.