Azure provides multiple ways to interact with and provision resources, each designed to suit different workflows and preferences. Whether through graphical interfaces, command-line tools, or declarative infrastructure-as-code (IaC) frameworks, the goal remains the same: enabling users to define and deploy cloud resources efficiently.

Recently, I gave a lecture to a Microsoft Leap intern whom I was mentoring at Microsoft. One of the key topics we discussed was the landscape of Azure client tools and how they interact with the Azure Resource Manager (ARM) REST API. Understanding these tools is crucial for effectively managing Azure infrastructure and ensuring a smooth operational workflow.

This article explores the core client tools for managing Azure, breaking down their interaction with the ARM API and how they compare in real-world scenarios.

Azure Resource Manager (ARM) and the REST API

At the heart of Azure’s provisioning model is the Azure Resource Manager (ARM), which exposes a REST API for managing cloud resources. Every action taken — whether through the Azure portal, CLI, PowerShell, or an IaC tool like Terraform — ultimately interacts with this REST API. When a user requests a virtual machine, for example, that request is sent to ARM, which processes it and provisions the resource accordingly. This API-driven approach standardizes resource management across all Azure client tools.

Azure Portal: The GUI Interface

The Azure portal is the most widely recognized interface for interacting with Azure. It provides a web-based UI that simplifies resource deployment through guided wizards. Every click in the portal translates into REST API calls behind the scenes. When provisioning a resource, the portal generates an ARM template that can be exported for reuse. The portal is best suited for quick, manual changes and exploratory work, such as discovering how to configure and use new services and exporting their configuration as ARM templates, either through observation of deployments or the ARM export tool. While convenient for these purposes, relying solely on the portal introduces limitations, particularly in repeatability and automation.

ARM Templates: Declarative Infrastructure as Code

ARM templates provide a way to define Azure infrastructure declaratively using JSON. Instead of manually provisioning resources, users describe the desired state in an ARM template, which is then submitted to Azure for execution. This method allows for consistency and repeatability and has strong backward compatibility. ARM templates are also used for Azure Policy mutable operations, such as “create if not exists,” and for building Azure automation directly into software systems.

Bicep: A More Readable Alternative to ARM Templates

Bicep is a domain-specific language (DSL) that simplifies ARM template authoring. It retains the same declarative approach but replaces JSON with a more concise syntax. Bicep scripts compile down to ARM templates before being executed, meaning the underlying deployment mechanism remains unchanged. The advantage of Bicep is its improved readability and maintainability, making it a preferred choice for infrastructure-as-code practitioners working within an Azure-centric declarative deployment approach.

Azure CLI and PowerShell: Command-Line Interfaces

For those who prefer scripting over GUI interactions, Azure CLI and PowerShell offer command-line access to Azure resources. Both tools execute commands that translate into REST API calls, providing a way to automate deployments and operational tasks.

  • Azure CLI: Designed for cross-platform use, it follows a straightforward syntax and is well-suited for automation in CI/CD pipelines.
  • PowerShell: More integrated with Windows environments, offering object-oriented scripting capabilities that align with traditional Windows administration workflows.

Both tools are particularly useful for gathering codes and input values for IaC work or testing small changes and experimentation.

Terraform: Multi-Cloud Infrastructure as Code

Terraform extends beyond Azure’s native tooling by providing a cloud-agnostic IaC framework. Using HashiCorp Configuration Language (HCL), Terraform enables infrastructure provisioning across multiple cloud providers with a consistent workflow. Unlike ARM templates and Bicep, which are Azure-specific, Terraform abstracts cloud interactions through provider extensions. By using the Azure Resource Manager (azurerm) provider, Terraform generates REST API requests similar to those from Azure-native tools. Terraform’s strengths lie in its modularity, reusability, and ability to enforce infrastructure state management. The terraform plan and terraform apply commands provide a structured approach to infrastructure deployment, making it the preferred choice for multi-cloud environments and complex IaC strategies.

Choosing the Right Tool for the Job

Each Azure client tool has its place depending on the use case:

  • Azure Portal: Best for quick, manual changes and exploratory work such as discovering how to configure and use new services and exporting their configuration as ARM templates either through observation of deployments or the ARM export tool.
  • ARM Templates: The native language of Azure, has strong backwards compatibility, and is used for Azure Policy mutable operations such as “create if not exists” and for building Azure automation into software systems.
  • Bicep: Suitable for IaC practitioners working in Azure-centric declarative deployments.
  • Azure CLI & PowerShell: Ideal for gathering codes and input values for IaC work or testing small changes and experimentation.
  • Terraform: Preferred for multi-cloud environments and complex IaC strategies.

Conclusion

Azure’s client tools provide a range of options for managing cloud resources, from graphical interfaces to fully automated deployments. Understanding their strengths and trade-offs helps teams select the right tool for their needs. Whether using the Azure portal for quick tasks, ARM templates for automation within software systems, Bicep for simplified ARM authoring, or Terraform for cross-cloud consistency, the key is aligning the tool with the operational and scalability goals of the organization.