The current AZ-104 blueprint explicitly measures automation of Azure resource deployment with ARM templates or Bicep files. It also says Azure Administrator candidates should have experience with PowerShell and Azure CLI. These tools overlap in what they can accomplish, but they represent different administrative styles. The AZ-104 exam is easier when you understand when declarative infrastructure definitions are better than a sequence of imperative commands and when scripting is the faster operational choice.
A practical distinction is this: Bicep and ARM templates describe the desired resource deployment, while PowerShell and Azure CLI execute commands. Administrators use both. A repeatable environment may be declared in code, while a script can inspect state, perform operational tasks, or drive deployments. The objective is not to pick one universal tool; it is to choose the tool that matches the job.
Think declaratively with ARM templates and Bicep
Declarative infrastructure describes what the final environment should look like. The deployment engine determines the operations required to reach that state. This is useful for repeatability, source control, peer review, and consistent deployment across environments. Bicep provides a more concise authoring experience that compiles to Azure Resource Manager template JSON.
The April 2026 objectives ask candidates to interpret templates and Bicep files, modify existing definitions, deploy resources, and export or convert deployments. That means you should be comfortable reading parameters, resource declarations, references, dependencies, and outputs rather than only knowing that “Bicep is infrastructure as code.”
When the scenario says the organization must reproduce the same environment reliably, a declarative definition is usually stronger than a long sequence of manually executed commands.
Use parameters and modules to avoid copied environments
A reusable deployment separates environment-specific values from the resource structure. Parameters can vary names, sizes, regions, address ranges, and other inputs without duplicating the whole file. Bicep modules can divide a larger deployment into logical components while preserving dependency relationships.
This design improves reviewability. A networking module can define the VNet and subnets, a compute module can deploy VMs or an App Service, and environment parameters can select production values. The goal is not maximal modularization; it is reducing repeated code and making the deployment intent understandable.
On the exam, look for requirements such as “least administrative effort,” “repeatable deployment,” or “deploy the same infrastructure to several environments.” Those clues often favor template-based automation.
Know when PowerShell is the better administrative tool
PowerShell is excellent for interactive administration and scripting against Azure resources, especially when teams already use PowerShell for Windows, identity, and automation. It can enumerate resources, transform objects in a pipeline, apply changes, and call Azure cmdlets. A useful contextual article explains why PowerShell is a cross-platform administration skill rather than a certification product of its own.
For AZ-104, focus on using PowerShell as an administrative interface rather than memorizing every cmdlet. If a scenario asks you to automate an operational action across many resources, PowerShell can be an appropriate answer. If it asks you to define an entire repeatable deployment, a Bicep or ARM template may be cleaner.
Command-line troubleshooting is also valuable. Techniques such as the PowerShell connectivity tests used by system administrators reinforce the broader skill of validating DNS, ports, and network reachability while working in Azure.
Use Azure CLI when concise command automation fits
Azure CLI provides a command-oriented interface that works well in shells and cross-platform automation. Many teams choose it for scripts, CI/CD jobs, and quick administrative tasks. The syntax differs from PowerShell, but the exam-level decision is usually about the administrative outcome rather than memorizing equivalent commands in both tools.
If a scenario says an administrator must create, update, query, or script a resource from a shell, Azure CLI may be suitable. If the organization standardizes on PowerShell and needs object-rich pipeline behavior, PowerShell may fit better. If the requirement is repeatable desired-state deployment, a declarative file is usually the more maintainable artifact.
Tool preference is less important than understanding the difference between a script that performs steps and a template that declares infrastructure.
Connect infrastructure as code to version control and review
Infrastructure as code is most valuable when it becomes part of an engineering process. Templates can be stored in version control, reviewed through pull requests, tested in non-production environments, and deployed through a pipeline. This creates a traceable record of infrastructure change and reduces one-off portal configuration.
The broader Azure DevOps toolchain is relevant because infrastructure definitions often move through the same source-control and CI/CD practices as application code. However, AZ-104 remains focused on Azure administration and template deployment, not on mastering an entire DevOps platform.
Candidates considering AZ-400 will encounter deeper DevOps automation patterns. For AZ-104, be able to recognize why versioned, repeatable deployments are safer than undocumented manual configuration.
Interpret an existing deployment before rewriting it
The blueprint explicitly includes interpreting and modifying existing ARM templates and Bicep files. That is a different skill from starting from a blank file. Administrators inherit infrastructure code written by other people and must understand resource names, parameters, parent-child relationships, references, and dependencies before making a change.
When a deployment fails, read the error in the context of the declared resources. A dependency may not be available, a parameter may be invalid for the region, a resource name may violate a rule, or the deploying identity may lack permission. Re-running the same deployment without understanding the failure can create more noise without changing the outcome.
Export and conversion features can help bootstrap code from existing resources, but generated output should still be reviewed. Infrastructure that happens to exist is not automatically a good reusable design.
Use idempotence and scope as quality checks
A good declarative deployment can be applied repeatedly without creating unintended duplicate resources. That property makes infrastructure automation safer and supports controlled change. Scripts can also be written defensively so they inspect current state before creating or changing objects, but that behavior must be designed into the script.
Scope matters too. A deployment can target resource groups, subscriptions, or other supported scopes depending on the resource and template design. The administrator should understand where the resources belong and which identity has permission to deploy them.
Automation does not bypass governance. Azure Policy, RBAC, locks, and resource-provider requirements can still affect a template or script. A failed automated deployment can therefore be a governance problem rather than a syntax problem.
Choose the tool from the requirement
Practice by translating requirements into an automation style. “Deploy the same network and compute stack to three environments” suggests Bicep or ARM templates. “Query all VMs and stop the ones matching a condition” suggests PowerShell or Azure CLI. “Integrate infrastructure changes into a source-controlled pipeline” suggests infrastructure as code plus CI/CD. “Troubleshoot a one-time resource state” may need an interactive command rather than a new template.
The best AZ-104 answers are usually maintainable and operationally realistic. Avoid selecting a template simply because the word automation appears, and avoid choosing a shell command when the requirement is repeatable desired-state deployment.
Once you understand the boundary between declarative deployment and imperative administration, Bicep, ARM, PowerShell, and Azure CLI stop competing with one another. They become complementary tools in the Azure administrator’s workflow.
Automation identities still need least privilege
A template or script acts through an identity, and that identity needs permission at the target scope. Giving an automation account Owner rights everywhere is convenient but weak security. A better design grants only the roles required for the deployment or operational task and keeps credentials or workload identities protected from unnecessary exposure.
This matters in pipelines as well as interactive administration. If a deployment pipeline can change production infrastructure, compromise of its secret or federated identity can become a direct infrastructure compromise. Version control protects the code history, but identity controls protect the authority used when that code runs. Both are required for trustworthy automation.
When an automated deployment receives an authorization error, inspect the role assignment and scope before rewriting the template. Conversely, when an identity has permission but Azure Policy denies the resource configuration, the failure is governance rather than RBAC. Separating syntax, deployment scope, identity, and policy makes automation troubleshooting far more efficient.
Make scripts safe to rerun
Imperative scripts should be written with the expectation that they may run more than once. A script that blindly creates a resource every time can fail or produce duplicates, while one that checks current state and applies only the required change is easier to operate. Error handling, clear output, parameter validation, and predictable exit behavior also matter when scripts become part of scheduled jobs or pipelines.
For AZ-104, you do not need to build a large automation framework, but you should recognize why a reliable administrative script checks assumptions before making destructive changes. Repeatability is not only a template concern; it is a quality standard for all automation.
Finally, treat automation output as operational evidence. A script or deployment should make failures visible, record what changed, and return enough information for another administrator to diagnose the result. Silent partial success is dangerous because it leaves infrastructure in an uncertain state.
A useful final check is to separate the identity used to deploy infrastructure from the identity used by the workload after deployment. The pipeline may need permission to create resources without granting the running application broad management rights. Keeping those identities distinct limits blast radius and makes audit trails easier to interpret when an automated change fails or a credential is compromised.
Continue exploring the technologies and certification concepts that matter most to you.