DEV Community: manny300

I Built a Secure, Decoupled E-Commerce Architecture on AWS Using Only Free-Tier Resources

manny300 — Tue, 01 Sep 2026 17:54:32 +0000

Monolithic application deployments mix public web traffic with internal database storage, creating a single point of failure and unnecessarily expanding the attack surface. To solve this, I designed and deployed a multi-tier PrestaShop e-commerce architecture on AWS. It decouples the application layer from the database layer, restricts network traffic using the Principle of Least Privilege, and remains entirely within AWS Free-Tier constraints.

What You Will Need

An AWS Account (Free-Tier eligible)
Basic understanding of Linux terminal commands
An SSH key pair for secure access

1. Database Provisioning (Amazon RDS)

I prioritized the creation of a managed relational database to establish a secure and isolated data backend before configuring the application frontend.

I accessed the RDS Console to initialize a new MySQL 8.0 instance. I selected the db.t3.micro instance class under the Free-tier template to maintain cost compliance. Most importantly, I disabled public accessibility. The database must remain internal to the VPC. A public-facing database is an unnecessary risk.

2. Application Server Provisioning (Amazon EC2)

For the web host, I launched a new Ubuntu 26.04 LTS instance via the EC2 Dashboard. I selected the t3.micro instance type to ensure Free-Tier eligibility. I also generated a new RSA Key Pair to authenticate via secure shell.

3. Security Group Configuration

This is where the architecture becomes secure. Simply putting resources in a VPC is not enough; you must define explicit traffic rules.

For the EC2 Security Group, I defined inbound rules to permit SSH (Port 22) access only from my personal IP address. I allowed global HTTP (Port 80) access so the storefront is accessible to the public.

For the RDS Security Group, I encapsulated the database by allowing traffic on Port 3306 only if it originates from the EC2 instance's specific Security Group ID. This establishes a secure, private link between the tiers. The database will drop any traffic that does not come directly from the web server.

4. Troubleshooting SSH Key Permissions

When I first attempted to connect to the EC2 instance, macOS blocked the connection with a WARNING: UNPROTECTED PRIVATE KEY FILE! error because the downloaded key had 0644 permissions (readable by anyone). SSH requires private keys to be strictly secured.

I fixed this by restricting the file permissions so only my user account could read it:

chmod 400 ~/.ssh/prestashop-key.pem
ssh -i ~/.ssh/prestashop-key.pem ubuntu@100.62.104.71

5. Server Configuration & Dependency Installation

Once connected, I updated the package manager and prepared to install Apache and PHP 8.1. Because I used a newer Ubuntu release (26.04), the standard ppa:ondrej/php repository was obsolete and returned a 404 error.

I resolved this by removing the broken repository and securely adding the canonical SURY repository via its GPG key:

# 1. Update the system
sudo apt update && sudo apt upgrade -y

# 2. Install prerequisites and add the new PHP GPG key and repository
sudo apt install -y apt-transport-https lsb-release ca-certificates curl apache2
sudo curl -sSLo /usr/share/keyrings/deb.sury.org-php.gpg https://packages.sury.org/php/apt.gpg
sudo sh -c 'echo "deb [signed-by=/usr/share/keyrings/deb.sury.org-php.gpg] https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list'

# 3. Update the package list and install PHP 8.1 with required extensions
sudo apt update
sudo apt install php8.1 libapache2-mod-php8.1 php8.1-mysql php8.1-curl php8.1-xml php8.1-gd php8.1-mbstring php8.1-intl php8.1-zip -y

# 4. Enable Apache rewrite module and restart
sudo a2enmod rewrite
sudo systemctl restart apache2

I activated the Apache rewrite module (a2enmod rewrite) to facilitate search engine friendly URL structures for the e-commerce platform.

6. PrestaShop Installation & Database Connection

With the environment ready, I pulled the latest PrestaShop release directly onto the server using wget and deployed the installation files to the /var/www/html/ web root.

sudo chown -R www-data:www-data /var/www/html/
sudo chmod -R 755 /var/www/html/

I modified the folder ownership to the www-data user and applied 755 permissions. This ensures the application has the proper write access to function, without exposing the files to broader system access.

I then initiated the web-based installation wizard via the public DNS. During the initial setup, I encountered a "Database Server is not found" error. I quickly realized two things:

I could not use 127.0.0.1 (localhost) because this violates the decoupled architecture; the database is not on the same server.
I had to use the exact RDS Endpoint URL and ensure the RDS Security Group accurately referenced the EC2 Security Group ID.

After providing the correct remote RDS endpoint and credentials, the connection succeeded.

Once the installation completed, I removed the /install directory to harden security and prevent malicious re-installation.

The PrestaShop environment successfully transitioned to a live state:

Publicly Accessible Storefront: http://ec2-100-62-104-71.compute-1.amazonaws.com
Admin Portal: http://ec2-100-62-104-71.compute-1.amazonaws.com/admin588uov6hcpqq1sxjj8s/index.php

What I Would Improve in a v2

Automate the provisioning process using declarative Infrastructure as Code (Terraform) instead of relying on manual AWS Console configuration.
Place the RDS instance into a dedicated private subnet with no internet gateway route to provide an even stronger network boundary.
Implement an Application Load Balancer (ALB) in front of the EC2 instance to allow for HTTPS termination and future horizontal scaling.

Key Takeaways

Decoupling stateful data from stateless compute is the foundation of a resilient architecture.
The Principle of Least Privilege applies directly to network traffic. Restricting database access to a specific application security group is a baseline requirement.
When working with modern Linux distributions, legacy package repositories often break. Knowing how to manually manage GPG keys and sources lists is a critical debugging skill.

What Is Next

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

I Built an Automated Deployment Pipeline for a 3-Tier Application to Eliminate Configuration Drift

manny300 — Sun, 16 Aug 2026 20:34:25 +0000

If you are just getting started with cloud deployments and CI/CD, this post is for you. I will walk you through how my team and I built a Dockerized 3-tier web application (React, Node.js, PostgreSQL), and how I specifically designed and automated the deployment infrastructure for it; covering Azure VM provisioning, manual deployment simulation, and a full GitHub Actions CI/CD pipeline with automated rollbacks.

This is the kind of project that bridges the gap between writing code locally and keeping it running reliably in the cloud. It is not glamorous, but it is one of those solutions that prevent "it works on my machine" from becoming a production outage.

This is a collaborative group Capstone project from my TechCrush Cloud Engineering bootcamp series. If you want to see where this journey started—including the write-up for my own personal Capstone project—you can read my previous posts on my Dev.to profile.

The Problem

My team (TechCrush Group 4) built FormFlow, a Dockerized 3-tier application. The application works flawlessly on our local machines via Docker Compose. The challenge is getting it to a production Azure Linux VM reliably. We needed three things to happen:

When infrastructure is provisioned, the VM, network security groups, and Docker runtime should all be installed automatically without anyone SSHing into the machine to run apt-get.
When code is pushed, we need absolute certainty about exactly what version is running in production. No pushing the latest tag and hoping for the best.
When a deployment breaks, the system must detect the failure and roll back to the previous version immediately. Not when a user complains. Automatically.

The hardest part of building CI/CD pipelines is that if you try to automate everything at once, a failed deployment leaves you guessing. Is the pipeline YAML wrong? Is the Dockerfile bad? Is the server misconfigured? To solve and simplify this, I designed an intermediate step: a script that simulates the CI/CD pipeline locally to isolate variables before getting to GitHub Actions.

What You Will Need

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

Azure CLI installed on your local machine.
An active Azure account to provision the Virtual Machine.
Docker Hub credentials configured as repository secrets (DOCKERHUB_USERNAME, DOCKERHUB_TOKEN) for the CI/CD pipelines.
Deployment Secrets configured in GitHub (DEPLOY_HOST, DEPLOY_USER, DEPLOY_SSH_KEY) once the VM is provisioned.
A terminal that runs Bash.

Understanding the Design

The Principle: Isolate Variables Before Automating

The core design decision behind this entire system is that the deployment logic must be proven manually before it is automated in CI/CD.

When you write a Bash script that successfully copies files, pulls images, and orchestrates containers on a remote server, you prove the infrastructure works. When you then transition that exact script into a GitHub Actions YAML file, any subsequent errors are strictly pipeline issues.

The Architecture

The system has three layers: infrastructure provisioning, the deployment simulation script, and the GitHub Actions pipeline.

The provisioning script (provision-vm.sh) creates the Azure VM and injects a cloud-init config to install Docker. The deployment script (deploy.sh) simulates the pipeline to catch race conditions. Finally, GitHub Actions orchestrates the linting, testing, security scanning, and deployment with health checks.

The Scripts

1. Provisioning: `provision-vm.sh`

This script builds the underlying Azure infrastructure and prepares the server to host Docker containers.

#!/bin/bash
set -e

RG_NAME="FormFlow-RG"
LOCATION="eastus"
VM_NAME="formflow-prod-vm"
ADMIN_USER="azureuser"
IMAGE="Canonical:0001-com-ubuntu-server-jammy:22_04-lts-gen2:latest"
SIZE="Standard_D2s_v3"

# 1. Create Resource Group
az group create --name "$RG_NAME" --location "$LOCATION" -o table

# 2. Create the Virtual Machine
az vm create \
  --resource-group "$RG_NAME" \
  --name "$VM_NAME" \
  --image "$IMAGE" \
  --size "$SIZE" \
  --zone 3 \
  --admin-username "$ADMIN_USER" \
  --generate-ssh-keys \
  --custom-data cloud-init.yaml \
  --public-ip-sku Standard \
  -o table

What matters here:

The --custom-data cloud-init.yaml flag is the most important part of this script. Instead of provisioning a blank Ubuntu VM and manually SSHing in to install Docker, the cloud-init file runs on the very first boot. By the time the Azure API says the VM is ready, Docker, Docker Compose, and the Buildx plugins are already installing in the background.

2. The Simulation: `deploy.sh`

This script is what a developer runs from their local machine to test the deployment process before we trust GitHub Actions to do it.

# Step 2: Copy the entire project to the VM (excluding unnecessary files)
echo "[2/4] Copying project files to VM..."
rsync -avz --progress \
  --exclude 'node_modules' \
  --exclude '.git' \
  --exclude 'infra' \
  --exclude '*.md' \
  -e "ssh -i $SSH_KEY_PATH -o StrictHostKeyChecking=no" \
  "$(dirname "$(dirname "$(realpath "$0")")")/" "$SSH_USER@$PUBLIC_IP:$APP_DIR/"

Why rsync? In a 3-tier application, moving files over SSH can be slow. By explicitly excluding node_modules and .git, we keep the payload incredibly lightweight. This mirrors how a CI/CD runner checks out code—it does not bring local development baggage with it.

Next, the script handles the most critical bug I encountered: the cloud-init race condition.

# Step 4: Wait for Docker to be installed by cloud-init, then run compose
$SSH_CMD "
  retries=12
  while [ \$retries -gt 0 ]; do
    if command -v docker >/dev/null 2>&1; then
      echo 'Docker is ready!'
      break
    fi
    echo 'Docker not yet installed (cloud-init still running). Retrying in 10s...'
    sleep 10
    retries=\$((retries - 1))
  done

  if ! command -v docker >/dev/null 2>&1; then
    echo 'ERROR: Docker was not installed after 2 minutes.'
    exit 1
  fi

  cd $APP_DIR && sudo docker compose up -d --build
"

When you provision an Azure VM, cloud-init runs in the background. If you run deploy.sh immediately after provision-vm.sh, it will fail because Docker is not fully installed yet. Rather than using a static, fragile sleep 120 command, I wrote a polling loop. It checks for the docker binary every 10 seconds. If Docker is ready in 20 seconds, the deployment continues immediately. This defensive code prevents race conditions while keeping deployments fast.

The CI/CD Pipeline

Once deploy.sh proved the architecture was sound, I translated that logic into .github/workflows/pipeline.yml.

Versioning with Git SHAs

tag:
  name: Generate Git SHA Tag
  runs-on: ubuntu-latest
  outputs:
    sha_tag: ${{ steps.sha.outputs.tag }}
  steps:
    - uses: actions/checkout@v4
    - name: Set short SHA
      id: sha
      run: echo "tag=$(git rev-parse --short HEAD)" >> "$GITHUB_OUTPUT"

We never push the latest tag to Docker Hub. That is a recipe for untrackable production states. Instead, the pipeline generates the Git short SHA and tags the frontend, backend, and database images with it. Pulling image a1b2c3d always corresponds to a known, inspectable commit in GitHub.

Security and Integration

Before touching the production VM, the pipeline runs a full suite. It builds the containers, stands them up via Docker Compose on the GitHub runner, and runs an integration test.

- name: Smoke test – POST /todos via Nginx
  run: |
    curl -sf -X POST http://localhost/todos \
      -H "Content-Type: application/json" \
      -d '{"description":"CI smoke test todo"}'

In parallel, it runs Trivy security scans on all three images. If a high-severity vulnerability is found, or if the API fails to respond to the curl request, the pipeline fails. Bad code never reaches production.

Deployment and Automatic Rollback

If tests pass, the deploy job runs. It SSHes into the Azure VM, pulls the SHA-tagged images, and orchestrates them. But what if the new images crash on startup?

# Keep a backup of the old .env file just in case for rollback
if [ -f .env ]; then
  cp .env .env.backup
  OLD_TAG=$(grep IMAGE_TAG .env | cut -d '=' -f2)
fi

# ... Docker pull and compose up logic ...

# Health Check and Automatic Rollback
echo "Waiting for services to start..."
sleep 10

if ! curl -sf http://localhost/todos; then
  echo "Health check failed! Initiating automatic rollback..."
  if [ -n "$OLD_TAG" ]; then
    echo "Rolling back to IMAGE_TAG=$OLD_TAG"
    mv .env.backup .env
    docker compose up -d --remove-orphans
  fi
  exit 1
fi

This is the safety net. Before updating the containers, the pipeline backs up the current .env file (which holds the currently running Git SHA tag). After deploying the new containers, it fires an HTTP request at the live endpoint. If the app does not respond, the script restores the .env.backup file and immediately redeploys the old containers. The pipeline then exits with code 1, alerting the team of the failure, but production remains online.

What the Result Looks Like

When another developer clones this repository, they do not need to understand the underlying infrastructure to deploy. They simply run:

$ ./infra/provision-vm.sh
...
✅ Provisioning Complete!
VM Name:    formflow-prod-vm
Public IP:  20.55.38.90

They take that IP, drop it into their GitHub Secrets along with their Docker Hub credentials, and push their code. The GitHub Actions dashboard shows a clean, parallel execution:

Checkout → Generate Git SHA → Build/Lint → Integration Test & Security Scan → Deploy & Health Check.

If they introduce a breaking change, the logs show the exact moment the system protected itself:

Waiting for services to start...
Health check failed! Initiating automatic rollback...
Rolling back to IMAGE_TAG=888e10d
Rollback complete.
Process exited with status 1

What I Would Improve in a v2

1. Declarative Infrastructure as Code
Bash scripts are great for provisioning, but they do not manage state. In a v2, I would replace provision-vm.sh entirely with Terraform or Azure Bicep to handle configuration drift automatically.

2. Azure Key Vault Integration
Currently, secrets like PG_PASSWORD are injected via GitHub Actions into a .env file on the server. A more secure approach would be having the Node.js backend authenticate directly with Azure Key Vault at runtime to fetch the database credentials.

Key Takeaways

Never rely on static sleep commands. Use polling loops to gracefully handle background tasks like cloud-init.
Tag images with Git SHAs, never latest. Version traceability makes rollbacks trivial.

What Is Next

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

You can find the full scripts, Dockerfiles, pipeline configs, and architecture documentation here: github.com/techcrush-group4-capstone/3-tier-dockerized-application

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 a Secure, Decoupled E-Commerce Architecture on AWS Using Only Free-Tier Resources

What You Will Need

1. Database Provisioning (Amazon RDS)

2. Application Server Provisioning (Amazon EC2)

3. Security Group Configuration

4. Troubleshooting SSH Key Permissions

5. Server Configuration & Dependency Installation

6. PrestaShop Installation & Database Connection

What I Would Improve in a v2

Key Takeaways

What Is Next

I Built an Automated Deployment Pipeline for a 3-Tier Application to Eliminate Configuration Drift

The Problem

What You Will Need

Understanding the Design

The Principle: Isolate Variables Before Automating

The Architecture

The Scripts

1. Provisioning: provision-vm.sh

2. The Simulation: deploy.sh

The CI/CD Pipeline

Versioning with Git SHAs

Security and Integration

Deployment and Automatic Rollback

What the Result Looks Like

What I Would Improve in a v2

Key Takeaways

What Is Next

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 🌍

1. Provisioning: `provision-vm.sh`

2. The Simulation: `deploy.sh`

1. Provisioning: `provision.sh`

2. Onboarding: `onboard.sh`

3. Offboarding: `offboard.sh`