Forem: Goodness Ojonuba

Agentic DevOps: Letting AI Subagents Audit Terraform Infrastructure

Goodness Ojonuba — Fri, 13 Mar 2026 23:58:46 +0000

Agentic DevOps: Letting AI Subagents Audit Terraform Infrastructure

What if your DevOps workflow included AI workers that could review your infrastructure the same way a teammate would?

As part of my learning journey with Agentic AI, I’ve been exploring how modern AI systems can move beyond simple prompt-response interactions and begin operating more like structured engineering workflows.

Most agent systems operate using a simple loop:

Gather → Act → Verify

But there is another important idea that makes these systems far more powerful:

Delegation.

Instead of one AI trying to do everything, work can be delegated to specialized AI workers that focus on one responsibility.

In Claude Code, these workers are called subagents.

Skills vs Subagents

Earlier in my project I worked with Skills — reusable slash commands such as:

/tf-plan
/tf-apply
/deploy

Skills help standardize repeatable workflows and run inside the same conversation context.

But subagents work differently.

A subagent operates in its own isolated environment, with its own tools and sometimes its own model.

Think of it like assigning work to a specialist engineer instead of asking a general assistant to handle everything.

Feature	Skills	Subagents
How they start	Triggered manually with slash commands	Automatically delegated by the main agent
Context	Shared conversation context	Isolated context
Chat history	Full conversation visible	No chat history
Tools	Uses the main agent’s tools	Own restricted toolset
Model	Uses the session model	Can use a different model

Rule of thumb

If the task needs conversation context → use a Skill

If the task is self-contained → use a Subagent

The Three Subagents I Added

To experiment with this setup, I added three subagents to my DevOps project.

security-auditor

Reviews Terraform files and detects potential security risks.

tf-writer

Generates Terraform infrastructure following best practices.

cost-optimizer

Analyzes infrastructure configuration for potential cost inefficiencies.

Each subagent focuses on a single responsibility, which keeps the analysis precise and avoids context overload.

Running the Audit

To test the setup, I gave Claude Code a simple instruction:

Audit my Terraform files for security issues

The interesting part is what happened next.

The main AI agent did not attempt to perform the audit itself.

Instead, it recognized that the request matched the security-auditor subagent and delegated the task automatically.

From that point forward, the subagent handled the entire audit independently.

Issues I Didn’t Notice

One of the most valuable parts of the audit was how it surfaced issues I had overlooked during deployment.

The security-auditor flagged several things including:

CloudFront access logging disabled
No Web Application Firewall (WAF) protection
Missing security headers
S3 versioning not enabled

Each issue was linked to the specific Terraform resource responsible, along with explanations and suggested fixes.

This level of detail makes infrastructure reviews far easier to understand and act on.

Why Isolation Matters

Another interesting detail is how the subagent executed the task.

The security-auditor ran in read-only mode with a clean context, focused purely on auditing.

This isolation prevents unintended infrastructure changes and keeps the analysis focused on one responsibility.

In practice, it behaved like a dedicated security reviewer examining Terraform configuration.

Architecture of the Agentic DevOps Workflow

What This Means for DevOps

This small experiment showed me how AI can play a larger role in DevOps workflows.

Instead of using AI only to generate infrastructure code, it can also assist with:

Infrastructure auditing
Security validation
Cost optimization
Configuration reviews

When combined with specialized workers like subagents, AI begins to look less like a chatbot and more like a team of automated engineering assistants.

Key Takeaways

Working through this exercise gave me a clearer picture of how agentic workflows can fit into DevOps practices.

A few things stood out:

Delegation matters.

The main agent didn’t attempt to do the security review itself. It delegated the task to a specialized subagent designed for that purpose.
Isolation improves safety.

The security-auditor ran in read-only mode with a clean context, preventing unintended infrastructure changes.
Structured output makes reviews easier.

Instead of vague suggestions, the audit returned categorized findings with severity levels and clear remediation steps.
Specialized agents reduce complexity.

By splitting responsibilities across subagents (security, cost, code generation), the system stays focused and avoids context overload.

This exercise showed me that AI in DevOps doesn’t have to stop at generating Terraform code.

It can also help review, audit, and improve infrastructure configurations in a structured way.

What I found most valuable wasn’t just the speed of the audit, but the structured way the work was delegated.

The agent handled orchestration, while the subagent focused entirely on the security review — a workflow that fits naturally into how DevOps teams already operate.

Deploying a Static Website on Azure Using Blob Storage

Goodness Ojonuba — Fri, 06 Mar 2026 23:33:17 +0000

This guide walks through the full deployment of a static web application using Azure Blob Storage Static Website Hosting.

The goal of this deployment is to demonstrate how Azure Storage can be used to host front-end applications without provisioning servers, virtual machines, or container infrastructure.

In this guide we will deploy the Mini Finance application, a static website composed of HTML, CSS, and image assets, and make it publicly accessible through an Azure-generated endpoint.

The deployment will cover the full process, including resource creation, configuration, file upload, and verification.

Resource Type	Resource Name	Purpose
Resource Group	mini-finance-rg	Logical container for all resources
Storage Account	minifinancedemo01	Stores and serves website files
Blob Container	$web	Hosts static website content
Static Website Endpoint	View Site	Public access URL

Architecture Overview

This deployment follows a simple static hosting architecture.

User requests are sent to the Azure static website endpoint, which retrieves files from the $web container inside the storage account.

This architecture removes the need for:

Virtual machines
Web servers (Apache or Nginx)
Load balancers
Container services

Azure Storage serves the application directly.

Step 1 — Download the Mini Finance Application

Before creating any Azure resources, we first download the application that will be deployed.

The Mini Finance project is hosted on GitHub and contains the static files required to run the application.

Steps

Navigate to the Mini Finance GitHub repository
Click Code
Select Download ZIP
Extract the archive locally

After extraction, the project directory should contain files similar to:

mini-finance/
├── index.html
├── style.css
├── images/
└── assets/

These files will later be uploaded to Azure Blob Storage.

Step 2 — Create the Resource Group

A Resource Group is used to organize and manage all resources related to the deployment.

Configuration

Property	Value
Resource Group Name	`mini-finance-demo-rg`
Region	`Spain Central`

Steps

Open the Azure Portal
Search for Resource Groups
Click Create
Enter the configuration above
Click Review + Create
Click Create

The resource group now acts as the container for all resources used in the deployment

Step 3 — Create the Storage Account

Basics

The Basics tab defines the core properties of the storage account.

Setting	Value	Explanation
Subscription	Your Azure subscription	Billing account that owns the resource
Resource Group	`mini-finance-demo-rg`	Groups related resources together
Storage Account Name	`minifinancedemo01`	Globally unique name used in the endpoint URL
Region	`Spain Central`	Determines where data is stored
Performance	Standard	Suitable for static website hosting
Redundancy	LRS	Keeps three copies of the data in one datacenter

Advanced

The Advanced tab controls compatibility and security features.

Recommended configuration:

Setting	Value	Explanation
Secure transfer required	Enabled	Ensures HTTPS connections
Allow Blob public access	Enabled	Required for static website hosting
Minimum TLS version	TLS 1.2	Ensures secure connections

Leave other settings as default.

Networking

The Networking tab controls how the storage account can be accessed.

For this demo we allow public access so users can reach the website.

Setting	Value	Explanation
Public network access	Enable	Allows internet access
Access scope	Enable from all networks	Makes the site globally accessible

Data Protection

Backup and recovery options are configured here.

For this demo leave defaults.

Setting	Value
Soft delete for blobs	Disabled
Soft delete for containers	Disabled
Versioning	Disabled

Encryption

Azure automatically encrypts stored data.

Setting	Value
Encryption type	Microsoft-managed keys

No changes are required.

Tags (Optional)

Tags help organize resources in larger environments.

Example:

Name	Value
project	mini-finance
environment	demo

Review + Create

Azure validates the configuration.

Click:

Review + Create → Create

Deployment usually completes within 30–60 seconds.

After deployment click Go to Resource.

Step 4 — Enable Static Website Hosting

Open the storage account minifinancedemo01
Navigate to: Data Management → Static website

Enable Static Website and configure:

Setting	Value
Static Website	Enabled
Index Document Name	`index.html`
Error Document Path	`index.html`

Azure automatically creates a container named: $web

Step 5 — Upload the Website Files

Navigate to:

Data Storage → Containers → $web

Upload:

index.html
css/
images/
js/

Step 6 — Verify the Deployment

Open the endpoint: go back to static web site and copy the endpoint

https://minifinancedemo01.z43.web.core.windows.net/ (available temporarily for this demo)

open it in a new browser:

Expected result:

Homepage loads
Styles apply correctly
Images render
Navigation works

Deployment Summary

Resource	Name
Resource Group	`mini-finance-demo-rg`
Storage Account	`minifinancedemo01`
Blob Container	`$web`
Static Website Endpoint	Azure Generated

Infrastructure used:

1 Resource Group
1 Storage Account
1 Blob Container

No compute resources required.

Key Takeaways

Azure Blob Storage can host static websites
No servers or infrastructure management required
$web container stores website assets
Azure automatically provides a public endpoint

Final Thoughts

Static website hosting on Azure is one of the simplest ways to deploy front-end applications.

Instead of managing servers and web servers, you can deploy an entire site using only storage.

With a few configuration steps and a folder of files, your application becomes publicly accessible across the internet.

The Complete Guide: Deploying a Static Site on AWS using Nginx and User Data: Completely Automated

Goodness Ojonuba — Fri, 20 Feb 2026 18:35:41 +0000

Introduction

In this guide, you’ll learn how to deploy a static website on an AWS Ubuntu server using Nginx. Instead of manually installing Nginx and copying files each time, we’ll use EC2 user data to automate everything when the instance launches.

We’ll use the Graphite Creative template from Tooplate:
Template

📌 Project Prerequisites
Before starting, make sure you have:

An active AWS account
Basic understanding of EC2
A created EC2 key pair (for SSH access)
Security group allowing:
SSH (Port 22)
HTTP (Port 80)
Internet access enabled on your EC2 instance (public subnet + internet gateway)

🧠 What We’re Automating
When the EC2 instance launches, it will:

Update packages
Install Nginx
Install wget & unzip
Download the website template
Extract it
Move files into /var/www/html
Start and enable Nginx

All automatically via User Data.

Step 1: Launch an Ubuntu EC2 Instance

Go to AWS Console → EC2
Click Launch Instance
Choose: Ubuntu Server 24.04 LTS
Select instance type: t2.micro (Free Tier eligible)
Select your key pair
Configure Security Group:
Allow HTTP (80)
Allow SSH (22)

Step 2: Add This User Data Script
Scroll to Advanced Details → User Data and paste this script:

#!/bin/bash 
apt update -y 
apt install nginx -y 
apt install wget unzip -y
cd /tmp wget https://www.tooplate.com/zip-templates/2156_graphite_creative.zip 
unzip 2156_graphite_creative.zip
rm -rf /var/www/html/*
cp -r 2156_graphite_creative/* /var/www/html/
chown -R www-data:www-data /var/www/html
systemctl enable nginx 
systemctl start nginx

Then click Launch Instance.

Step 3: Wait for EC2 to Initialize
Give it about 3–5 minutes. wait for 2/2 or 3/3 checks
User Data runs automatically on first boot.

Step 4: Access Your Website
Go to EC2 Dashboard
Copy the Public IPv4 address

Open your browser:
http://YOUR_PUBLIC_IP
check to ensure it's http and not https in your URL.

If everything worked, your Graphite Creative site should load immediately.

🎯 What Just Happened?

When the instance booted:
Ubuntu updated
Nginx installed
Website downloaded automatically using wget
Files extracted with unzip
Nginx configured and started
Site deployed without manual intervention That’s the power of User Data automation.

🚀 Why This Matters
This approach gives you:

Reproducible deployments
Faster provisioning
Zero manual configuration

This is a simple setup, but the idea behind it is powerful. Instead of treating servers like pets that need manual care, you’re starting to treat them like disposable infrastructure. If something breaks, you don’t fix it manually. You relaunch it and the automation handles the rest.

From here, you could:

Store your website in an S3 bucket instead of downloading it directly
Use Terraform to provision the EC2 instance automatically
Add a domain name and SSL certificate
Put CloudFront in front of it for better performance

But the real win here is understanding how User Data works. Once you’re comfortable with that, you can automate almost any server setup.

If you're learning cloud keep building, keep breaking things, keep pushing. Mastery comes from daily practice.

More Than Just a Board: Why My First Jira Sprint Was a Lesson in DevOps

Goodness Ojonuba — Fri, 06 Feb 2026 01:31:28 +0000

Introduction
Before this sprint, Jira felt like a task board where you move tasks/stories around. After running a full sprint myself, I realized Jira is really about visibility, rhythm, and learning, not just tracking work.

In this sprint, I planned work, ran daily updates, shipped a small UI improvement, tracked progress using the burndown chart, and closed the sprint with a retrospective.
That process changed how I think about delivery.

The Daily Scrum: Small Updates, Big Clarity
The Daily Scrum looked simple at first. Just three questions:

What did I do yesterday?
What will I do today?
What is blocking me?

But writing these updates every day forced me to think about progress in small increments, not big unfinished work.

Even working solo, the daily update created accountability. Each day needed a visible outcome, not just effort.

This naturally led to shipping smaller improvements more consistently.

Backlog Refinement Made Sprint Planning Easier
Before the sprint started, I created stories, added acceptance criteria, estimated them, and ranked them by value.

This step made sprint planning much easier because:

The work was already clear
Stories were small and understandable
Scope decisions were simpler Without backlog refinement, sprint planning would have felt like guessing.

Sprint Planning: Turning Ideas into Commitment
Sprint planning was where the work became real.

Instead of selecting everything, I chose just a few stories that could realistically be completed within the sprint.

That decision matters. A sprint is not a to-do list. It is a commitment to deliver a usable increment.

Once Sprint 1 started, the goal was simple: Ship 2–3 visible UI improvements to Gotto Job and show them live.

The Burndown Chart: Seeing Progress Visually
The burndown chart showed sprint progress over time. Even with a small sprint, it made progress visible in a way the board alone could not.

It answered an important question: Are we moving toward finishing the sprint goal?

Instead of relying on memory or assumptions, the chart provided objective feedback about delivery progress.

That transparency is what makes Scrum effective.

Shipping One Increment (The DevOps Moment)
During the sprint, I implemented one UI improvement, committed the change, deployed it, and verified it on the live site.

That single cycle represented the DevOps lifecycle in practice: Plan → Build → Deploy → Verify

For this project I ship one small change at a time and the first was the Tagline changed to meet the Acceptance Criteria

Tagline Before Update:
Tagline After Update:

Shipping one small improvement felt more valuable than working on many unfinished changes.

Why the Retro Is the Most Valuable Part
The retrospective is where the sprint turns into learning.

Instead of asking “Did we finish tasks?”, the retrospective asks:

What went well?
What should improve?
What should we try next sprint?

This is where continuous improvement happens.

For example, in my sprint, the retrospective captured these reflections:

What went well: The Git-to-deployment workflow was smooth, and the hero tagline update was successfully delivered and verified on the live site. Working in solo mode helped me stay organized and maintain clear ownership of the sprint tasks.
What to improve: Automate EC2 deployment using user-data or scripts to reduce manual deployment time and improve consistency.
Scrum Pillar – Inspection: I practiced inspection by verifying changes locally and on the live URL to ensure the UI updates met the acceptance criteria before closing the story.
Scrum Value – Commitment: I stayed committed to completing one story at a time and delivering a working increment during the sprint.

Final Reflection

Running a sprint showed me that Jira is not the important part. The important part is the workflow around it.

Daily Scrum builds consistency. Burndown charts create transparency. Retrospectives create improvement.

Together, they turn work into a repeatable delivery system.

That was my biggest takeaway from running my first Jira sprint.

P.S. If you're starting your DevOps journey, you can join the DevOps Micro Internship (DMI) community led by Pravin Mishra on Discord.It’s a great place to gain hands-on experience and learn with from a global community

Git Branching and the Multiverse: Protecting the Sacred Timeline🌠

Goodness Ojonuba — Fri, 30 Jan 2026 10:51:37 +0000

If you are a fan of the MCU, you have probably watched Doctor Strange in the Multiverse of Madness. One moment everything is stable, the next moment there are multiple realities, and one small mistake can trigger a multiversal disaster.

That is why Doctor Strange protects the Sacred Timeline.

For me, Git branching felt the same way at the beginning. I see a lot of people create and use branches but it took sometime to truly understand why it was important.Too many commands, too many possibilities, and the fear that one wrong move could break the entire project.

What finally made it click was understanding isolation.

Branching is controlled isolation (The Mirror Verse)

In Git, your main branch is the Sacred Timeline. It must remain stable and predictable

When you create a branch, Git places your work in isolation. You are still connected to the main timeline, but your changes live in their own safe space. Nothing you do in that branch can break the main branch unless you intentionally merge it.

This isolation is the real superpower.
You can:

Build features without risking production code
Break things while learning without fear
Experiment freely and roll back easily
Work in teams without interfering with each other

Just like the multiverse, each branch exists independently.

You are Doctor Strange, managing isolated realities

As an devOps Engineer, you are not avoiding chaos by refusing to branch. You are avoiding chaos by isolating it (going into the mirror verse).

Every time you create a branch, you are saying, “Let me explore this idea in a separate universe where no damage can leak into the Sacred Timeline.”

If the idea works, great.
If it fails, you close that universe and move on.

No harm done.

Creating an isolated universe

When you run:

git checkout -b feature-scoreboard

Git creates a new timeline that looks exactly like main, but it is completely isolated. Any commits you make here stay here.
You can switch between realities anytime:

git checkout main
git checkout feature-scoreboard

Each switch rewrites your working directory to reflect that universe. Main stays clean. Your experiments stay contained.

That isolation is what keeps projects sane.

Merging without breaking reality

Once your work is tested and ready, you bring it back carefully.

git checkout main
git merge feature-scoreboard

This is where Git checks if merging will disrupt the Sacred Timeline. If everything aligns, the merge is smooth.

If not, Git stops and asks you to resolve conflicts before anything breaks.

Isolation ensures that problems are discovered early, not in production.

Close unstable universes

Branches are not meant to live forever.

Once a branch has done its job, delete it:

git branch -d feature-scoreboard

Fewer timelines, fewer problems.

Final thoughts

Git branching is not about complexity. It is about safety through isolation. It allows you to learn, experiment, and collaborate without constantly worrying about breaking things.

If you are early in your career, you can start your DevOps journey with Pravin Mishra by joining the DevOps Micro Internship (DMI) Discord community:
https://discord.pravinmishra.com/

It is a great program where you get hands-on training and experience, supported by a global community.

Explore freely, isolate your changes, and always protect the Sacred Timeline 🌌

3 Questions That Will Change How You See Linux

Goodness Ojonuba — Thu, 22 Jan 2026 10:30:39 +0000

I had worked with Linux before. I had used cloud services, deployed applications, and followed DevOps workflows. Still, three simple questions asked by my instructor, Sir Pravin Mishra, made me pause and rethink how deeply Linux sits at the center of everything we do in DevOps.

He didn’t start with commands or configuration files. He started with questions that sounded simple, but stayed with me long after the class.

The Three Questions

Which operating system is used the most by cloud servers?
Which operating system is used to run containers?
Which operating system do automation tools like Ansible and Terraform depend on?

As we reflected on them, a pattern became obvious. Different tools, different platforms, same foundation. Linux.

Why These Questions Matter

DevOps often looks like a collection of tools: cloud platforms, CI/CD pipelines, containers, automation scripts. But underneath all of that is an operating system that quietly holds everything together.

Most cloud servers run on Linux because it is stable, flexible, and designed for server environments. Containers rely on Linux kernel features. Automation tools are built with Linux environments in mind. Even when you interact mostly through dashboards or managed services, Linux is still doing the real work underneath.

These questions helped me see DevOps less as a toolset and more as an ecosystem built on a common base.

How This Showed Up in Practice

I recently deployed a React application and a ready-made portfolio site. After deployment, I carried out post-production DevOps checks to make sure everything was running as expected.

During this process, I worked directly with the terminal on an Ubuntu-based AWS instance. Managing processes, configuring the environment, and verifying that everything was running correctly all happened through Linux.

The servers hosting my applications were Linux-based. The build processes, web servers, and runtime environments all depended on Linux. This time, it wasn’t just something happening in the background. I was interacting with it directly.

It wasn’t a new concept, but it became a much clearer and more practical realization.

A Subtle Shift in Perspective

I don’t see Linux as just another skill on a checklist anymore. I see it as the common language spoken by cloud infrastructure, containers, and automation tools.

Every deployment reinforces this idea. You can use different platforms and services, but understanding Linux helps you reason better about what’s happening when things work, and when they don’t.

Looking Ahead

I’ll keep exploring Linux, not just to run commands, but to see the bigger picture. Every deployment reinforces the lesson from those three questions: understanding the foundation can change the way you see Linux, DevOps, and the tools we rely on.

A Page from the Future

Goodness Ojonuba — Sun, 11 Jan 2026 17:20:36 +0000

By 2030, Goodness had established himself as a prominent figure in cloud computing, earning multiple certifications across multi cloud; AWS, Azure, Google Cloud. Over the past 3–5 years, he progressed from foundational cloud projects to a senior cloud architect role, leading multi-cloud migration initiatives that improved operational efficiency and reduced costs for large organizations. His portfolio included hands-on deployments using Infrastructure-as-Code, automated CI/CD pipelines, and scalable serverless architectures. His GitHub repositories, which included full cloud infrastructure projects and multi-cloud integration scripts, became a reference for aspiring cloud engineers worldwide.

In addition to his professional achievements, Goodness remained deeply committed to his personal mission, “To Thrive and Serve.” He designed community-focused programs that trained hundreds of students and early-career professionals in cloud technologies. These initiatives combined workshops, online tutorials, and mentorship, providing practical skills that bridged the gap between classroom learning and real-world application. Through his guidance, dozens of participants secured their first roles in the tech industry, demonstrating the tangible impact of his work.

Goodness also became recognized as a thought leader in cloud computing. He published articles on multi-cloud strategy, infrastructure optimization, and emerging technologies, contributing regularly to industry blogs and journals. He spoke at conferences and participated in panels discussing cloud architecture, automation, and sustainable IT practices. His work emphasized efficiency, collaboration, and innovation, showcasing his ability to translate technical expertise into strategic value.

Despite his technical accomplishments, Goodness never lost sight of the lessons that shaped his journey. He consistently emphasized disciplined learning over fleeting motivation, shared knowledge openly, and embraced the philosophy that the right time to act is always now. This mindset not only helped him achieve his long-standing goal of joining AWS but also enabled him to leave a lasting mark on the global cloud community. By 2032, Goodness had not only built a successful career but also created pathways for others to thrive, demonstrating that technical excellence paired with a commitment to service can transform both individuals and the broader technology ecosystem.

NB This is part of DevOps Micro-Internship (DMI) by Pravin Mishra