DEV Community: manny300

I Built an IAM System That Onboards and Offboards Users in Under 60 Seconds

manny300 — Wed, 12 Aug 2026 11:26:22 +0000

If you are just getting started with Identity and Access Management on Azure, this post is for you. I will walk you through how I designed and automated a complete access governance system for a fictional fintech company; covering infrastructure provisioning, intern onboarding, and zero-trust offboarding. Using Bash scripts, Azure RBAC, and GitHub Actions CI/CD pipelines.

This is the kind of project that sits at the intersection of cloud engineering and security. It is not glamorous, but it is one of those solutions that keep organizations from ending up in the news for all the wrong reasons.

This is One of my Capstone projects in my TechCrush Cloud Engineering bootcamp series. If you want to see where this journey started, you can read my previous posts where I tackled deploying a web app across two Azure regions and automating resource group creation for multi-environment workflows.

The Problem

VerdantPay is a fintech company growing fast. They bring on interns every cycle, they have permanent engineering teams working across web and database tiers, and people leave. The company needs three things to happen reliably:

When infrastructure is provisioned, the network, resource groups, security groups, and RBAC role assignments should all be created in one operation with a full audit trail.
When an intern joins, they should be added to the correct security group in one command.
When someone leaves, every group membership, every role assignment, and the account itself should be revoked and verified. Not tomorrow. Not when someone remembers. Immediately.

The third one is the one that matters most. A departed engineer who still has Contributor access to your production resource group is not a hypothetical risk. It is one that shows up in compliance audits and incident reports.

What You Will Need

Before running any of these scripts, make sure you have:

Azure CLI installed on your local machine. Follow the official installation guide.
An active Azure account with at least Pay-As-You-Go. A free account works for most of this, but you will need Entra ID (Azure AD) permissions to create groups and manage users.
A GitHub repository with AZURE_CREDENTIALS configured as a repository secret for the CI/CD pipelines.
A terminal that runs Bash; Linux, macOS, or WSL on Windows.

Understanding the Design

The Principle: Least Privilege, Enforced by Structure

The core design decision behind this entire system is that role assignments are made to Azure AD groups, not to individual users.

When you assign a role directly to a user, revoking access means finding every individual assignment across every scope. When you assign roles to groups, revoking access means removing the user from the group. One operation. One place to audit.

The Role Matrix

Before writing a single line of code, I built a role matrix. Every group, its scope, its permission level, whether the access is time-bound, and the justification for why that level was chosen and not a higher one.

Group	Scope	Azure Role	Time-bound	Why This Level
InternWebDevs	web-subnet	Reader	Yes, 6 weeks	Interns need to inspect web-tier resources. Contributor would let them modify infrastructure they should not touch.
InternDBReadOnly	db-subnet	Reader	Yes, 6 weeks	Interns need to inspect DB config. They must not modify the database or its network rules.
WebAdmins	web-subnet	Contributor	No, permanent	Web admins manage the web tier. Owner is not needed because they do not manage access.
DBAdmins	db-subnet	Contributor	No, permanent	DB admins manage the database tier. Reader covers infrastructure. Data actions are granted separately.

The rule: no group or role assignment is created without a corresponding row in this matrix.

The Architecture

The system has three layers: automation scripts, Azure AD groups, and Azure infrastructure, connected by GitHub Actions pipelines.

The provisioning script creates the resource group, VNet, subnets, AD groups, and role assignments. The onboarding script adds a user to a group. The offboarding script revokes everything and verifies the revocation. GitHub Actions orchestrates the provisioning and offboarding pipelines with full artifact logging.

The Scripts

1. Provisioning: `provision.sh`

This script builds the entire infrastructure and access control layer in one run.

#!/bin/bash
set -euo pipefail

LOG_FILE="provision-log.txt"
TIMESTAMP=$(date -u '+%Y-%m-%dT%H:%M:%SZ')

log() {
    echo "[$TIMESTAMP] $1" | tee -a "$LOG_FILE"
}

log "Starting provisioning..."

SUBSCRIPTION_ID=$(az account show --query id -o tsv)

# 1. Create Resource Group
RG_NAME="verdantpay-rg"
LOCATION="eastus"

log "Creating Resource Group: $RG_NAME in $LOCATION"
az group create --name $RG_NAME --location $LOCATION -o json >> "$LOG_FILE"

# 2. Create VNet and Subnets
VNET_NAME="verdantpay-vnet"

az network vnet create \
    --resource-group $RG_NAME \
    --name $VNET_NAME \
    --address-prefix "10.0.0.0/16" -o json >> "$LOG_FILE"

az network vnet subnet create \
    --resource-group $RG_NAME \
    --vnet-name $VNET_NAME \
    --name "web-subnet" \
    --address-prefixes "10.0.1.0/24" -o json >> "$LOG_FILE"

az network vnet subnet create \
    --resource-group $RG_NAME \
    --vnet-name $VNET_NAME \
    --name "db-subnet" \
    --address-prefixes "10.0.2.0/24" -o json >> "$LOG_FILE"

What matters here:

set -euo pipefail at the top is non-negotiable. If any command fails, the script stops. If any variable is unset, the script stops. In infrastructure automation, a script that silently continues after a failure is worse than a script that crashes loudly.

The script also checks whether subnets and groups already exist before creating them. This makes the script idempotent you can run it ten times and get the same result. This matters in CI/CD where pipelines re-run on retries.

Creating AD Groups and Role Assignments

create_ad_group() {
    local group_name=$1
    GROUP_ID=$(az ad group show --group "$group_name" --query id -o tsv 2>/dev/null || echo "")
    if [ -z "$GROUP_ID" ]; then
        az ad group create --display-name "$group_name" --mail-nickname "$group_name" -o json >> "$LOG_FILE"
    else
        log "Group $group_name already exists."
    fi
}

create_ad_group "verdantpay-InternWebDevs"
create_ad_group "verdantpay-InternDBReadOnly"
create_ad_group "verdantpay-WebAdmins"
create_ad_group "verdantpay-DBAdmins"

After creating groups, the script waits 30 seconds for Entra ID replication before attempting role assignments. This upgrade was as a result of a notable failed case that I encountered. Group creation is eventually consistent, and assigning a role to a group that has not replicated yet will fail silently or throw an error depending on your timing.

The role assignment function includes a retry loop:

assign_role() {
    local group_name=$1
    local role=$2
    local scope=$3
    local retries=5
    local wait=10

    for i in $(seq 1 $retries); do
        GROUP_ID=$(az ad group show --group "$group_name" --query id -o tsv 2>/dev/null || echo "")
        if [ -n "$GROUP_ID" ]; then
            break
        fi
        log "Group '$group_name' not found yet, retrying in ${wait}s... (attempt $i/$retries)"
        sleep $wait
    done

    EXISTING=$(az role assignment list --assignee "$GROUP_ID" --role "$role" --scope "$scope" --query '[].id' -o tsv 2>/dev/null || echo "")
    if [ -z "$EXISTING" ]; then
        az role assignment create --assignee "$GROUP_ID" --role "$role" --scope "$scope" -o json >> "$LOG_FILE"
    else
        log "Role assignment already exists for $group_name"
    fi
}

This is the kind of defensive code you write after learning the hard way that Azure AD group replication is not instant. The retry loop gives the system time to catch up without failing the entire pipeline.

2. Onboarding: `onboard.sh`

This script is intentionally simple. One command. One log entry.

#!/bin/bash
set -euo pipefail

USER_EMAIL=$1
GROUP_NAME=$2
TIMESTAMP=$(date -u '+%Y-%m-%dT%H:%M:%SZ')
EXECUTOR=$(az ad signed-in-user show --query userPrincipalName -o tsv 2>/dev/null || echo "service-principal")

USER_OBJECT_ID=$(az ad user show --id "$USER_EMAIL" --query id --output tsv)

az ad group member add --group "$GROUP_NAME" --member-id "$USER_OBJECT_ID"

echo "[$TIMESTAMP] ADDED: User '$USER_EMAIL' to Group '$GROUP_NAME' by '$EXECUTOR'" | tee -a "onboarding-log.txt"

Why it logs the executor: When an intern gets added to verdantpay-InternWebDevs, you need to know who added them. The script captures the signed-in user's principal name. If it is running via a service principal in CI/CD, it logs that instead. This is a basic audit requirement that most onboarding scripts skip.

3. Offboarding: `offboard.sh`

This is the most important script in the entire system. It follows a strict sequence:

Look up the user's Object ID
Capture the before state — every group membership and role assignment
Remove the user from every AD group
Delete every direct role assignment
Disable the Azure AD account
Verify that all access has been revoked
Write VERIFICATION: PASS or VERIFICATION: FAIL

#!/bin/bash
set -euo pipefail

USER_EMAIL=$1
LOG_FILE="offboarding-log.txt"
TIMESTAMP=$(date -u '+%Y-%m-%dT%H:%M:%SZ')

# Step 1: Get Object ID
OBJECT_ID=$(az ad user show --id "$USER_EMAIL" --query id --output tsv)

# Step 2: Capture before-state
echo '--- BEFORE STATE ---' >> "$LOG_FILE"
echo "Timestamp: $TIMESTAMP" >> "$LOG_FILE"
echo "User: $USER_EMAIL" >> "$LOG_FILE"
az ad user get-member-groups --id "$OBJECT_ID" --security-enabled-only true >> "$LOG_FILE"
az role assignment list --assignee "$OBJECT_ID" --all >> "$LOG_FILE"

# Step 3: Remove from all groups
USER_GROUPS=$(az ad user get-member-groups --id "$OBJECT_ID" --security-enabled-only true --query '[].displayName' -o tsv)
for GROUP in $USER_GROUPS; do
    az ad group member remove --group "$GROUP" --member-id "$OBJECT_ID" || true
done

# Step 4: Delete direct role assignments
ROLE_IDS=$(az role assignment list --assignee "$OBJECT_ID" --all --query '[].id' -o tsv)
for ROLE_ID in $ROLE_IDS; do
    az role assignment delete --ids "$ROLE_ID" || true
done

# Step 5: Disable account
az ad user update --id "$OBJECT_ID" --account-enabled false

# Step 6: Verify with retries
VERIFY_RETRIES=5
VERIFY_WAIT=15

for i in $(seq 1 $VERIFY_RETRIES); do
    REMAINING_ROLES=$(az role assignment list --assignee "$OBJECT_ID" --all --query '[]' -o tsv)
    REMAINING_GROUPS=$(az ad user get-member-groups --id "$OBJECT_ID" -o tsv)

    if [ -z "$REMAINING_ROLES" ] && [ -z "$REMAINING_GROUPS" ]; then
        echo 'VERIFICATION: PASS -- all access removed for '"$USER_EMAIL" >> "$LOG_FILE"
        exit 0
    fi

    echo "Residual access detected, retrying in ${VERIFY_WAIT}s... (attempt $i/$VERIFY_RETRIES)"
    sleep $VERIFY_WAIT
done

echo 'VERIFICATION: FAIL -- residual access detected after retries' >> "$LOG_FILE"
exit 1

The script queries Azure AD and Azure RBAC after the revocation to confirm that all groups and roles are actually gone. If they are not because of replication lag or a partial failure the script retries up to 5 times over 75 seconds. If it still fails, it exits with code 1, which causes the CI/CD pipeline to fail and alert the team.

The || true on the removal commands is deliberate. If a user has already been removed from a group (maybe by a previous partial run), the command would fail and set -e would kill the script before it gets to the other groups. The || true lets it continue to the next group while the verification step at the end catches anything that was actually missed.

The CI/CD Pipelines

Provisioning Pipeline

name: VerdantPay IAM Provisioning

on:
  push:
    branches: [ main ]
    paths:
      - 'scripts/provision.sh'
      - 'scripts/onboard.sh'

jobs:
  provision:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Azure Login
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Run provisioning script
        run: bash scripts/provision.sh

      - name: Upload access log
        uses: actions/upload-artifact@v4
        with:
          name: access-log
          path: provision-log.txt

Path filtering is the design decision here. The pipeline only triggers when provision.sh or onboard.sh are modified. Updating the README does not trigger a cloud deployment. This is was done to saves unnecessary runs and keep the audit logs clean.

Offboarding Pipeline

name: VerdantPay Offboarding

on:
  workflow_dispatch:
    inputs:
      user_email:
        description: 'Email address of the user to offboard'
        required: true

jobs:
  offboard:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Azure Login
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Run offboarding script
        run: bash scripts/offboard.sh ${{ github.event.inputs.user_email }}

      - name: Upload offboarding log
        uses: actions/upload-artifact@v4
        with:
          name: offboarding-log
          path: offboarding-log.txt

Why workflow_dispatch instead of an automated trigger? Offboarding is a destructive, irreversible action. Triggering it automatically on a push would be dangerous. workflow_dispatch requires a security administrator to manually type in the user's email and click Run.

The offboarding log is uploaded as a GitHub Actions artifact. Security teams can download it after the run to prove that access was revoked at a specific timestamp.

What the Result Looks Like

After running the full provisioning, I tested the system with real user accounts. The onboarding log captured every addition:

[2026-08-03T07:01:49Z] ADDED: User 'temiloluwa@...' to Group 'verdantpay-WebAdmins' by 'emmanuelajibokunedu...'

And the offboarding log shows the complete before-and-after state:

--- BEFORE STATE ---
Timestamp: 2026-08-03T07:48:08Z
User: temiloluwa@...
Groups before:
[
  { "displayName": "verdantpay-WebAdmins" }
]
VERIFICATION: PASS -- all access removed for temiloluwa@...

The VERIFICATION: PASS line means the script queried Azure after revocation, found zero remaining group memberships and zero remaining role assignments, and confirmed the offboarding was complete.

What I Would Improve in a v2

1. Time-bound access with Azure AD PIM

The role matrix specifies that intern access should be time-bound to 6 weeks, but the current scripts do not enforce expiry automatically. In a v2, I would integrate Azure AD Privileged Identity Management (PIM) to set eligible assignments with an automatic expiry date. That way, even if the offboarding script is never run, the access disappears on its own.

2. Slack or Teams notifications on offboarding

When the offboarding pipeline completes, the result sits in a GitHub Actions log that someone has to go look at. A webhook that posts the PASS/FAIL result to a Slack or Teams channel would close that loop and give security teams instant visibility.

3. A dedicated teardown script

I actually built this already, a teardown.sh that removes everything in reverse order: role assignments first, then AD groups, then the resource group.

Key Takeaways

Assign roles to groups, never to individual users.
Build a role matrix before writing code.
Verify your revocations.
Use set -euo pipefail in every script.
Make your CI/CD pipelines produce evidence.
Write a teardown script for everything you provision.

What Is Next

Follow me for more contents about Cloud engineering and DevOps
Follow along on my Dev.to profile if you want to see how it goes.

You can find the full scripts, pipeline configs, role matrix, and architecture diagram here: github.com/EmmanuelAjibokun/VerdantPay-IAM

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.

DEV Community: manny300

I Built an IAM System That Onboards and Offboards Users in Under 60 Seconds

The Problem

What You Will Need

Understanding the Design

The Principle: Least Privilege, Enforced by Structure

The Role Matrix

The Architecture

The Scripts

1. Provisioning: provision.sh

Creating AD Groups and Role Assignments

2. Onboarding: onboard.sh

3. Offboarding: offboard.sh

The CI/CD Pipelines

Provisioning Pipeline

Offboarding Pipeline

What the Result Looks Like

What I Would Improve in a v2

Key Takeaways

What Is Next

How to Automate Azure Resource Group Creation with a Bash Script

The Problem

What You Will Need

Understanding the Design

The Script

Walking Through the Script

What the Result Looks Like

What I Would Improve in a v2

Key Takeaways

What Is Next

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

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

First Attempt: Azure Cloud Shell

The Goal

Getting West Europe Working

The Wall: East US Quota Limits

The Rabbit Hole: Resource Providers

Upgrading to Pay As You Go

Finding a Different Path

The Unanswered Question

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

Prerequisites

Quickstart

1. Clone the repo

2. Log in to Azure

3. (Optional) Set your active subscription

Option A — Deploy the local Node.js app

EmmanuelAjibokun (Emmanuel Ajibokun ) · GitHub

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

From Geology to Cloud Computing: My First Project 🌍

How I Planned the Work

The Humbling Part

Read the Full Project

1. Provisioning: `provision.sh`

2. Onboarding: `onboard.sh`

3. Offboarding: `offboard.sh`