DEV Community

manny300
manny300

Posted on

How to Automate Azure Resource Group Creation with a Bash Script

#cloudcomputing #azure #devops #bash

If you are just getting started with Azure CLI and Bash scripting, this post is for you. I will walk you through how I automated the creation of Azure resource groups for multiple environments using a single Bash script — something that was taking a cloud admin several manual steps every week.

This is Project 2 in my TechRush Cloud Engineering bootcamp series. If you want to see where this journey started, you can read my previous post where I tackled deploying a web app across two Azure regions for the first time. That project involved real blockers — quota limits, CLI version mismatches, and a deep dive into Azure Resource Providers. This one went smoother, and I think that is because the previous project was the hard school.

The Problem

Imagine a cloud administrator who has to create five resource groups every single week, one for each active project:

Project-A-RG
Project-B-RG
Project-C-RG
Project-D-RG
Project-E-RG
Enter fullscreen mode Exit fullscreen mode

Every week. By hand. Management's response was simple: automate it.

But here is where the task gets more interesting. Instead of creating one flat resource group per project, the better approach is to create four resource groups per project — one for each environment:

  • Dev
  • Test
  • UAT
  • Production

This matters because each environment needs its own access controls, cost tracking, and lifecycle rules. You do not want your Development environment sharing a resource group with Production. Keeping them separate is a real-world cloud best practice, not just a bootcamp exercise.

What You Will Need

Before running this script, make sure you have the following set up:

  • Azure CLI installed on your local machine. You can follow the official installation guide.
  • An active Azure account. A free account works fine for this.
  • A terminal that runs Bash — Linux, macOS, or WSL on Windows.

Understanding the Design

The core idea behind this script is parameterization. Instead of hardcoding project names, the script accepts a project name as input and uses it as a prefix for every resource group it creates.

So if you enter Project-A, you get:

Project-A-RG-Dev
Project-A-RG-Test
Project-A-RG-UAT
Project-A-RG-Production
Enter fullscreen mode Exit fullscreen mode

Next week, you run the same script, enter Project-B, and get the same structure with a different prefix. The script never changes. Only the input does.

The RG in the middle is there to make the resource type clear at a glance. When you are looking at a list of twenty Azure resources, names that include what the resource is save you a lot of time.

The Script

Create a file called deploy.sh and paste the following:

#!/bin/bash

# Check if the user is logged into Azure
if ! az account show &>/dev/null; then
  echo "Not logged in. Run 'az login' first."
  exit 1
fi

# Prompt the user for a project name
read -p "Enter Project Name: " ProjectName

# Validate that the input is not empty
if [[ "$ProjectName" == '' ]]; then
  echo "Project Name cannot be empty."
  exit 1
fi

# Inform the user that resource group creation is starting
echo "Creating resource groups for $ProjectName..."

# Create one resource group per environment
az group create --name "$ProjectName-RG-Dev"        --location "eastus"
az group create --name "$ProjectName-RG-Test"       --location "eastus"
az group create --name "$ProjectName-RG-UAT"        --location "eastus"
az group create --name "$ProjectName-RG-Production" --location "eastus"

echo "Resource groups created successfully."
Enter fullscreen mode Exit fullscreen mode

Now make the script executable:

chmod +x deploy.sh
Enter fullscreen mode Exit fullscreen mode

Then run it:

./deploy.sh
Enter fullscreen mode Exit fullscreen mode

Walking Through the Script

Login check

if ! az account show &>/dev/null; then
Enter fullscreen mode Exit fullscreen mode

The very first thing the script does is check whether you are already logged into Azure. If you are not, it stops immediately and tells you exactly what to do. This is called a guard clause — you check your preconditions before doing any real work. It prevents confusing errors further down.

Input prompt

read -p "Enter Project Name: " ProjectName
Enter fullscreen mode Exit fullscreen mode

The read command pauses the script and waits for you to type something. Whatever you type gets stored in the variable ProjectName. The -p flag lets you show a prompt message at the same time.

Empty input validation

if [[ "$ProjectName" == '' ]]; then
Enter fullscreen mode Exit fullscreen mode

If the user just presses Enter without typing anything, ProjectName will be empty. Without this check, the script would go ahead and try to create resource groups with names like -RG-Dev, which is not useful to anyone. This check catches that and exits cleanly.

Resource group creation

az group create --name "$ProjectName-RG-Dev" --location "eastus"
Enter fullscreen mode Exit fullscreen mode

This is the Azure CLI command that does the actual work. The --name flag uses string interpolation to combine the variable with the environment suffix. The --location flag tells Azure which region to deploy to. You can change eastus to any region that is available on your subscription.

What the Result Looks Like

After running the script with FI_deparment as the project name (from the actual assignment run), the Azure portal showed the following resource groups created successfully:

Azure portal showing four resource groups: FI_deparment-RG-Dev, FI_deparment-RG-Test, FI_deparment-RG-UAT, FI_deparment-RG-Production

What I Would Improve in a v2

Shipping something that works is step one. Thinking about what comes next is what separates a script you wrote once from a script a team can actually use.

Two things I would change:

1. Add a location prompt

Right now the region is hardcoded to eastus. A slightly better script would also ask the user for their preferred region. Different teams or clients might need resources in different geographies, and hardcoding a region removes that flexibility.

2. Replace the four az group create lines with a loop

The current script has four nearly identical lines. If the environments ever changed — say, you needed to add a Staging environment — you would have to manually add another line. A loop over an array is cleaner and easier to extend:

environments=("Dev" "Test" "UAT" "Production")

for env in "${environments[@]}"; do
  az group create --name "$ProjectName-RG-$env" --location "eastus"
done
Enter fullscreen mode Exit fullscreen mode

Same result, but now adding a new environment is a one-word change.

Key Takeaways

  • Parameterize, do not hardcode. A script that accepts input is reusable. A script with hardcoded values is a one-time tool.
  • Validate your inputs early. Check that required values exist before doing any real work.
  • Name things clearly. ProjectName-RG-Dev tells you the project, the resource type, and the environment at a glance.
  • Separate environments into separate resource groups. Dev and Production should never share a resource group in a real setup.
  • Write a destroy script alongside every deploy script. I did not need it here, but the habit of writing a teardown script is what keeps your Azure bill from surprising you.

What Is Next

Assignment 3 is more complex. It covers two scenarios: a one-click deploy script that provisions a full environment stack for non-technical staff, and a university migration to Azure where each department gets its own set of resources — with a requirement to support 20 more departments the following year. That last part is a design thinking challenge, not just a scripting challenge.

I will write about that one too. Follow along on my Dev.to profile if you want to see how it goes.

You can find the full script and repo here: github.com/EmmanuelAjibokun/Techcrush-Ass-2

Top comments (0)