DEV Community: manny300

How to Automate Azure Resource Group Creation with a Bash Script

manny300 — Mon, 08 Jun 2026 18:17:27 +0000

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

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

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."

Now make the script executable:

chmod +x deploy.sh

Then run it:

./deploy.sh

Walking Through the Script

Login check

if ! az account show &>/dev/null; then

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

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

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"

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:

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

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

From Zero to Multi-Region: My experience deploying on Azure for the First Time

manny300 — Sat, 30 May 2026 17:27:37 +0000

Starting this project, I was not as lost as I was with the first one.
If you haven't seen the first one, here it is:

manny300

May 14

A cloud service model decision framework comparing IaaS / PaaS / SaaS trade-offs for three production workloads

#cloudcomputing #devops #solutionarchitect #cloudsolution

2 min read

This time I had some familiarity coming in. The first thing I did was explore the Azure portal, clicked around, created a Resource Group, setup an App Service, and it worked.

Then I moved on to the CLI, which is where things started to feel funny.

First Attempt: Azure Cloud Shell

My first attempt was with Azure Cloud Shell. It did not feel natural to me. My main confusion was around shell scripts. I was not sure if I could write and run a deploy script from inside Cloud Shell.

In hindsight, the answer is yes. You can use a text editor like Vim/Emacs right inside Cloud Shell and execute your script from there. But I did not think of that at the time.

So I moved on to installing the Azure CLI locally on my machine.

That took a couple of days on its own, but working on my local machine felt more natural. The first installation method I tried did not work. I eventually got it working, moved into VS Code, and started writing my deploy script properly.

The Goal

Take the same static website I built for Project 1 and deploy it to Azure using the Web App Service, across two different regions.

I wrote a deploy.sh script and a destroy.sh script. The destroy script is the habit that saves you from racking up charges on resources you forgot about.

The script flow followed Azure's hierarchy:

Create a Resource Group, every resource on Azure must belong to one
Create an App Service Plan, this is where you choose the OS for your web app
Create the Web App on top of that plan
Deploy your files

The App Service Plan is worth understanding properly. It is not just a billing tier. Even though we are working with Platform as a Service, meaning we are not managing the underlying infrastructure ourselves, we still choose the operating system. Azure handles everything below that.

Getting West Europe Working

Getting the West Europe deployment working took some back and forth with the commands. Some flags I used were not recognized by my version of the CLI, and some runtime options that older documentation referenced no
longer exist.
Static site hosting on a Web App Service Plan with a Linux OS, for example, is not supported. The Web App Service Plan works with Windows OS for deploying static sites. Each of these were small walls that required reading error messages carefully, researching, and adjusting.

The Wall: East US Quota Limits

The second half of the challenge was deploying to a second region, East US.
I expected it to work the same way West Europe did. It did not.
The error I kept hitting was about quota. Specifically, the Total VMs limit for East US was set to zero on my subscription. No VMs available meant no App Service Plan could be created, which meant no deployment.

My first instinct was that maybe the SKU was the problem. I was using F1, which is the free tier. I went into the Azure portal and looked through the quota section under the Web App provider. I could see that certain SKUs like P1V4 had limits of 10 or 30 in that region, while F1 was sitting at zero.

I changed the SKU in my script to one of those available tiers, ran the script again, and hit the same wall. The error was not about the SKU specifically. It was about the Total VM quota for the region, and that articular quota had no option to adjust the limit from the portal.

The Rabbit Hole: Resource Providers

Around this time I started paying closer attention to how Azure
organizes its services. I came across Resource Providers, which I had not really thought about before.

Every Azure service belongs to a provider namespace:

Microsoft.Web for App Services
Microsoft.Compute for Virtual Machines

Before you can use any service, the corresponding provider needs to be registered on your subscription. On a free account, some providers are not registered by default, and quotas are locked.

I went down the rabbit hole of manually registering the Compute
provider, only to discover that the Web provider I actually needed had already been registered automatically.
It was a detour, but it was a useful one.

Upgrading to Pay As You Go

I upgraded from the free tier to Pay As You Go. I still have my $200 free credit for the first 30 days, so the cost risk was manageable.
After upgrading, the provider situation improved and quotas became adjustable.
But the East US Total VM limit was still at zero and still had no adjustment option in the portal. I reached out to Microsoft engineering support and submitted a formal quota increase request for two instances.
That request is still being processed.

Finding a Different Path

While that was still on, I found a different path.
Since what I am deploying is a static website, Azure has a dedicated Static Web Apps service that sits outside the App Service quota system entirely. I deployed to it and it worked without hitting any quota restrictions at all. I was able to deploy to two different regions successfully using that service.

I also went back and tested West Europe with the original Web App Service approach, and it worked there as well. So I now have deployments running across multiple regions through two different methods.

The Unanswered Question

As a Pay As You Go subscriber, I would expect to be able to deploy to any region Azure offers. But right now I am restricted to one region for Web App Service deployments while the quota request gets processed.

If anyone has run into this and know the reason for this, I would genuinely like to know. It is the kind of thing that would matter on a real project with a deadline.

Read the Full Project

You can have a look at the project by clicking the link below:

EmmanuelAjibokun / Azure-Web-App

A small web application (a static site is fine; even better, a "Hello, [your name]" Flask app) deployed into Azure App Service in two regions, behind a Resource Group you provisioned entirely from the Azure CLI — no portal clicks for the deployment itself.

Azure Web App

Deploy a Node.js app to Azure using the Azure CLI. This repo contains two deployment scripts:

deploy-app.sh — deploys the local Node.js app from the app/ folder using az webapp up
deploy-static.sh — provisions a Static Web App (East US 2) and a Web App from GitHub (West Europe)

Prerequisites

Azure CLI installed
An active Azure subscription
Git installed

Quickstart

1. Clone the repo

git clone https://github.com/EmmanuelAjibokun/cloud-eng.git
cd azure-web-app

2. Log in to Azure

az login

3. (Optional) Set your active subscription

az account list --output table
az account set --subscription "<your-subscription-id>"

Option A — Deploy the local Node.js app

This deploys the app/ folder directly to an Azure Web App using az webapp up.

chmod +x deploy-app.sh
./deploy-app.sh

What it does:

Checks that you are logged in to the Azure CLI — exits with an error if not
Checks if cloud-decision-east is already…

View on GitHub

If you would like to follow along on the learn-by-doing journey,
comment "github" and I will send you the project guide link. Kindly star the project and follow me on GitHub.

EmmanuelAjibokun (Emmanuel Ajibokun ) · GitHub

A computer programming enthusiast, Geologist by field of study and a fast learner - EmmanuelAjibokun

github.com

A cloud service model decision framework comparing IaaS / PaaS / SaaS trade-offs for three production workloads

manny300 — Thu, 14 May 2026 10:27:54 +0000

From Geology to Cloud Computing: My First Project 🌍

Diving into the world of cloud computing as an applied geology graduate,
having moved from frontend development with React and Next.js to backend
development with Node.js.

This is not just another tech skill to learn. This season could be the
beginning of a career transition for me. Because of that, I paid a
subsidised price to join the TechCrush bootcamp. But I know that is not
enough. If I want to finish with the outcome I desire, I must put in
extra work.

How I Planned the Work

The first thing I did was prompt Claude with some considerations that
included 10 job posting requirements in cloud computing and DevOps, the
course modules that would be covered during the bootcamp, and a sample
task by Forrest Brazeal called the #CloudResumeChallenge. Here is the
prompt I used:

"I'm transitioning my career into cloud engineering, and I feel the
3-month training covers the majority of these opportunities. I want to
have projects for each milestone, in the same order that I would be
doing them in the training. Create a similar guide to the one by
Forrest Brazeal's #CloudResumeChallenge. Juxtapose my learning and job
requirements to map out the projects."

This mapped out 9 projects to work on by the end of my bootcamp.

The first project is what this post is about.

The Humbling Part

I had one introductory class and one main class with my tutor. I
actually started working on the first project before my classes began.
I had studied on my own, watched about 6 YouTube videos, and was
feeling pretty confident.

Then, to my great amusement, I did not seem to understand the task at
all, let alone know where to get started. It was one of the strangest
feelings, and I remember thinking to myself:

"I don't understand what is expected of me."

So I gave AI this prompt:

"I'm just starting out in this career, I don't want the answer
handed out to me, but I need resources that can help me better
understand the question, and information on what to learn in order to
complete the task."

With some targeted reading and research, I was able to complete the
project. 🎉

Read the Full Project

You can read about my findings by clicking the link below:

emmanuelajibokun.github.io

If you would like to follow along on the learn-by-doing journey,
comment "github" and I will send you the project guide link. Kindly
star the project and follow me on GitHub.