DEV Community: Rahimah Sulayman

From Code to Clouds: Hosting a Professional Resume on GitHub Pages(2)

Rahimah Sulayman — Sat, 02 May 2026 22:55:35 +0000

Introduction

In Part 1, we successfully moved the resume from a local editor to a live URL. But an empty repository is like a house without a front door, functional, yet inaccessible to those looking in. In this second installment, we’re going back into the terminal to master the art of the README.

I’ll show you how to turn a folder of code into a polished, technical portfolio that speaks for itself. Whether you’re a Cloud aspirant or a DevOps enthusiast, your documentation is your handshake. Let’s make it count.

Step 1: Navigating and Initializing the README
In the previous guide, we set up the environment. Now, we return to the terminal to add the "front door" of our project, that is the the README.md file.

Changing Directory: We start by using cd ~/Desktop/website to ensure we are working inside the correct project folder.

Creating the File: The touch README.md command is used to generate a blank Markdown file. Using the .md extension is crucial as it tells GitHub to render this as a formatted document rather than just plain text.

Opening the Editor: To add content, we use the vi README.md command. This opens the Vi text editor directly in the terminal, it's a lightweight, powerful tool that every Cloud and DevOps professional should be comfortable using.

Step 2: Inspecting and Verifying Content
Once I’ve finished editing in Vi, it’s best practice to verify that your data was saved exactly how you intended.

We use cat README.md to display the entire contents of the file directly in the terminal. This check ensures there are no typos or formatting errors in our Markdown syntax before we push.

The output shows a structured, professional layout:

Project Title: Using # for a clear H1 heading.

Live Links: Providing immediate access to the hosted resume.

Visual Elements: Using emojis (🚀, 🛠️, 📖) to make the documentation modern and readable.

Technical Milestones: A numbered list summarizing the core achievements of the project.

Command Reference: Using backticks (`) for code blocks, creating a "cheat sheet" for anyone who forks the repository.

Step 3: The Version Control Lifecycle (Stage & Commit)
In this step, we move our new documentation through the Git lifecycle. It’s not enough to just create the file, we have to tell Git to track it.

git status (The Pulse Check): Before doing anything, I ran git status. You can see README.md highlighted in red under Untracked files. This confirms that Git sees a new file but isn't yet managing it.

git add README.md (Staging): This command moves the file into the staging area. The terminal warning about LF will be replaced by CRLF is a common occurrence in Git Bash on Windows, it’s just Git managing how line endings are handled between different operating systems.

git commit (The Snapshot): By running git commit -m "add README with project overview and commands", we officially record the change. The output "1 file changed, 30 insertions" serves as a receipt, confirming that our 30 lines of professional documentation are now part of the project's history.

Step 4: The Final Push (Syncing to the Cloud)
This is the bridge between our local work and our public profile.

git push origin master: This command tells Git to take the committed changes (the new README) and upload them to the origin (GitHub) on the master branch.

"Enumerating objects: 4, done": Git is gathering the files you changed.

"Writing objects... 1.19 KiB": This confirms the actual data transfer.

The Confirmation: The line bb98894..e6d1410 master -> master is the technical "all clear." It shows your local branch is now perfectly synced with GitHub.

Step 5: Configuring the Global Gateway (GitHub Pages)
Once the code is safely in the cloud, you have to tell GitHub how to serve it to the public.

Navigating to the Settings > Pages tab is where the hosting magic happens.

I set the source to Deploy from a branch and selected the master branch and / (root) folder. This tells the GitHub server to look for our index.html file exactly where we saved it.

Once saved, GitHub generates a custom URL (e.g., https://rahimahisah17.github.io/Git-Basics101/).
Seeing that "Your site is live" message is the ultimate green light for a developer!

Conclusion

Documentation is the bridge between writing code and building a career. A project without a README is just a folder, a project with a README is a story of your technical journey.

Kubernetes Building Blocks(1)

Rahimah Sulayman — Fri, 24 Apr 2026 16:01:47 +0000

Introduction

If you liken Kubernetes to an ocean, those individual drops that make up the ocean are the core building blocks: Namespaces, Pods, ReplicaSets, Deployments, Labels, etc.
Our focus here will be on the first two mentioned.
As a professional working across Data Analytics and Cloud Engineering, I’ve found that the best way to master these concepts isn't just by reading documentation, but by using the Build, See, Destroy methodology. This approach allows you to experiment fearlessly, visualize the cluster's internal logic, and clean up after yourself.

In this post, we are going to move from a blank slate Minikube cluster to an orchestrated environment, exploring both the fast-paced command line and the birds-eye view of the Kubernetes Dashboard.

The Scenario: The Isolated Web Fleet
Imagine you are a DevOps Engineer tasked with deploying a fleet of Nginx web servers for a new project. However, the cluster is shared with other teams, so you can't just dump your resources into the default space.
Tasks

Carve out a Virtual Sandbox: Create a dedicated Namespace to keep our project isolated.
Deploy the Fleet: Use both Imperative (quick CLI) and Declarative (YAML/JSON) methods to launch five Nginx pods.
Inspect & Troubleshoot: Go under the hood to check IP addresses, node placements, and handle the inevitable errors that come with cluster management.
Visualize the Result: Launch the Minikube Dashboard to confirm 100% health of our fleet.

Namespaces

If multiple users and teams use the same Kubernetes cluster we can partition the cluster into virtual sub-clusters using Namespaces. The names of the resources/objects created inside a Namespace are unique, but not across Namespaces in the cluster.

Step 1: Checking if the Cluster is Ready
Before we can start building with Namespaces and Pods, we need to ensure our local environment is up and running. Using Minikube, we can quickly verify the health of our cluster, run minikube status.

To list all the Namespaces, we can run the following command:
$ kubectl get namespaces

A Namespace is to a Kubernetes cluster as a ResourceGroup is to an Azure Subscription.
Generally, Kubernetes creates four Namespaces out of the box: kube-system, kube-public, kube-node-lease, and default. The kube-system Namespace contains the objects created by the Kubernetes system, mostly the control plane agents. The default Namespace contains the objects and resources created by administrators and developers, and objects are assigned to it by default unless another Namespace name is provided by the user. kube-public is a special Namespace, which is unsecured and readable by anyone, used for special purposes such as exposing public (non-sensitive) information about the cluster.
The newest Namespace is kube-node-lease which holds node lease objects used for node heartbeat data.
Good practice, however, is to create additional Namespaces, as desired, to virtualize the cluster and isolate users, developer teams, applications, or tiers

Step 2. Organizing your cluster by Creating Your Own Namespace
Think of Namespaces as virtual folders within your cluster. While Kubernetes provides a default namespace, it’s best practice to create your own to keep your projects isolated and organized.

In this step, I move from viewing the cluster to actively managing it by running the command:
$ kubectl create namespace new-namespace-name

$ kubectl create namespace rahimah
This is an imperative command. I'm telling the Kubernetes API directly to make this right now. The confirmation namespace/rahimah created is the cluster acknowledging the new logical boundary.

Namespaces are one of the most desired features of Kubernetes, securing its lead against competitors, as it provides a solution to the multi-tenancy requirement of today's enterprise development teams.

Run $ kubectl get namespaces to Verifying our work is key. You can see the new namespace rahimah is now Active alongside the system-generated ones. It’s now a ready-to-use sandbox where we can deploy our pods without cluttering the rest of the cluster.

Namespaces are great for multi-tenancy. If you are working in a team, giving each developer or project their own namespace prevents naming collisions, meaning you can have a pod named web-server in Namespace A and another web-server in Namespace B without any conflict!

Pods

A Pod is the smallest Kubernetes workload object. It is the unit of deployment in Kubernetes, which represents a single instance of the application. A Pod is a logical collection of one or more containers, enclosing and isolating them to ensure that they:

Are scheduled together on the same host with the Pod.
Share the same network namespace, meaning that they share a single IP address originally assigned to the Pod.
Have access to mount the same external storage (volumes) and other common dependencies.

Below is an example of a stand-alone Pod object's definition manifest in YAML format, without an operator. This represents the declarative method to define an object, and can serve as a template for a much more complex Pod definition manifest if desired:

Step 1: Moving to Declarative by Defining Your First Pod
While kubectl run is great for quick tests, real-world Kubernetes relies on Manifests. These YAML files act as the source of truth for your infrastructure, allowing you to version control and share your configurations easily.

The Screenshot: Preparing the Manifest
In this sequence, I’m setting up the workspace and defining the blueprint for our application.

Step 2: Setting the Scene
I created a dedicated directory cluster and a new file rahimah.yaml to keep the project organized.

What the manifest contains:
apiVersion & kind: Tells Kubernetes we are creating a version 1 Pod.

metadata: This is where we name our resource (nginx-pod).

spec: This is the most critical part. It defines the desired state, specifically, that we want one container running the nginx:1.22.1 image on port 80.
KAMS stands for the parts of a manifest.

Tip: YAML is extremely sensitive to indentation! If you're off by even one space, the Kubernetes API will reject your file. I always recommend using a code editor with a YAML linting extension to catch these invisible errors before you hit the terminal, hence I used the vi editor.

The apiVersion field must specify v1 for the Pod object definition. The second required field is kind specifying the Pod object type. The third required field metadata, holds the object's name and optional labels and annotations. The fourth required field spec marks the beginning of the block defining the desired state of the Pod object (also named the PodSpec). Our Pod creates a single container running the nginx:1.22.1 image pulled from a container image registry, in this case from Docker Hub.

The above definition manifest, if stored by a rahimah.yaml file, is loaded into the cluster to run the desired Pod and its associated container image.

Before creating the pod, I'll save the YAML file in a directory, for organization. Then vi into it for verification.

Step 3: Reviewing the Manifest
Before we send our instructions to the Kubernetes API, it’s always a good habit to peek inside the file one last time. This ensures that our indentation is correct and that we are deploying the exact version of the image we intended.

Am inspecting the File with cat command

This is important because in a real-world DevOps environment, you might be managing dozens of YAML files. Running cat allows you to verify the metadata and spec fields without opening a full text editor.

NOTE: If you're following along, notice the containerPort: 80. This doesn't actually open the port to the outside world yet (you'll need a Service for that later) but it tells Kubernetes which port the application inside the container is listening on.

$ kubectl create -f rahimah.yaml

$ kubectl run nginx-pod --image=nginx:1.22.1 --port=80$ kubectl run nginx-pod --image=nginx:1.22.1 --port=80

Step 4: From Blueprint to Reality
This is where we move from local files to actual running resources. In this step, I demonstrate both the Declarative and Imperative methods of pod creation.

The screenshot shows deployment the Nginx pods.
In this image, I am populating the cluster with three distinct pods using two different techniques.

$ kubectl create -f rahimah.yaml: This is the Declarative approach. We are telling Kubernetes to create whatever is defined in this file. It’s the professional standard for production environments.
$ kubectl run nginx-pod --image=nginx:1.22.1 --port=80$ kubectl run nginx-pod --image=nginx:1.22.1 --port=80

kubectl run nginx-pod2 & nginx-pod3: These are Imperative commands. They are fast, one-liners that are perfect for Build, See, Destroy learning or quick debugging.

Notice the consistent feedback from the cluster: pod/nginx-pod created.
Whether you use a complex JSON/YAML file or a simple CLI command, the Kubernetes API processes the request and schedules the workload onto a node.

Step 5: Verifying the Workload
The most satisfying part of any Kubernetes project is seeing that Running status. This is where we confirm that the cluster has successfully pulled the images, allocated resources, and started our containers.

The Screenshot shows Healthy Pod Fleet
In this final view, we run the ultimate "truth" command: kubectl get pods.

READY 1/1: This indicates that the container inside the pod has passed its readiness check and is prepared to handle traffic.

STATUS Running: This confirms the pod is active on a node. If you see ContainerCreating or ErrImagePull here, you know something went wrong during the startup process.

RESTARTS 0: A zero here is a sign of stability. It means your application hasn't crashed or entered a CrashLoopBackOff.

However, when in need of a starter definition manifest, knowing how to generate one can be a life-saver. The imperative command with additional key flags such as dry-run and the yaml output, can generate the definition template instead of running the Pod, while the template is then stored in the rahimah.yaml file. The following is a multi-line command that should be selected in its entirety for copy/paste (including the backslash character "\")
$ kubectl run nginx-pod --image=nginx:1.22.1 --port=80 \
--dry-run=client -o yaml > nginx-pod.yaml

I ran the ls command to confirm the file presence in that location,
then I created a pod from the YAML file and get pods to list the pods present in the cluster.

The command above generates a definition manifest in YAML, but we can generate a JSON definition file just as easily with:

$ kubectl run nginx-pod --image=nginx:1.22.1 --port=80 \
--dry-run=client -o json > nginx-pod.json

Then vi into the json file that created pod4 to edit it for pod5. Then cat again it to verify the changes were effected.

I created a new pod using the apply verb, then ran get pods, get pods -o wide commands.

NOTE: The difference get pods and get pods -o wide

$ kubectl create -f nginx-pod.yaml
$ kubectl create -f nginx-pod.json

Both the YAML and JSON definition files can serve as templates or can be loaded into the cluster respectively as such:

Step 6: Deep Dive
Sometimes, a simple kubectl get pods isn't enough. When you need to know exactly what is happening inside a Pod, like which node it's running on, its IP address, or its lifecycle events, you need to use the describe command.

The Screenshot shows the anatomy of a Running Pod
In this image, I’m running kubectl describe pods and the output is a goldmine of information.

Node Information: You can see this pod is scheduled on the minikube node at IP 192.168.49.2.

Container Details: It confirms we are using the nginx:1.22.1 image and that the container is officially in the Running state.

Conditions: Notice the True values for Initialized, Ready, and PodScheduled. This is the _checklist _Kubernetes uses to ensure the pod is healthy.

IP Address: Each pod gets its own unique internal IP (in this case, 10.244.0.3).

NOTE: If your pod is stuck in Pending or CrashLoopBackOff, always scroll to the very bottom of the describe output. The Events section will tell you the exact reason, whether it’s a failed pull, a lack of memory, or a configuration error.

Step 7: The Apply Warning
As you saw earlier, switching between kubectl run and kubectl apply can trigger a warning message.

Recall the Screenshot Missing Annotation Warning
In this image, I used kubectl apply on a pod that was originally created with a simple run command.

What the Warning Means: Kubernetes is saying: "I don't see the 'last-applied-configuration' note on this pod." You don't actually have to do anything, Kubernetes automatically patches the pod by adding that annotation so it can track future declarative changes.

Hence, once you move to a file-based workflow (using YAML or JSON), stick with kubectl apply. It makes your deployments much more predictable and stable.

Step 8: Using the describe Command for Advanced Inspection
When a simple list isn't enough, we need to look closer. The kubectl describe command is your magnifying glass for everything happening inside a resource.

The Screenshots below show an anatomy of a Running Pod, am inspecting all the pods. The output provides critical data that isn't visible in a standard list:

Placement: You can see exactly which Node (in this case, our minikube VM) is hosting the pod.

Networking: Each pod is assigned its own internal IP address (like 10.244.0.3).

Lifecycle Conditions: Notice the "True" status for Initialized, Ready, and ContainersReady. This is the checklist Kubernetes uses to confirm the pod is healthy and capable of serving traffic.

Events: While not visible in every crop, the bottom of this output logs every action the cluster took, from pulling the image to starting the container.

Tip: If your pod status is Pending, use describe. It will often tell you if the cluster is out of memory or if it can't find a node that fits your requirements.

Always verify cluster health before deployment to minimize downtime.
Step 11: The GUI Perspective (Launching the Minikube Dashboard)
Sometimes a visual overview is exactly what you need to see the *big picture * of your cluster.

In the screenshot below an accessing the Dashboard by running the command minikube dashboard. This automates several complex steps for you;

Enabling the Addon: It ensures the dashboard components are active.
Launching the Proxy: It creates a secure tunnel between your local machine and the cluster.

Opening the UI: It provides a local URL that opens directly in your browser.
The dashboard isn't just for looking, you can use it to edit YAML files, scale your deployments, and view real-time logs without typing a single kubectl command.

Step 9: Exploring the Kubernetes Dashboard
After spending so much time in the terminal, there is nothing quite like seeing your cluster come to life in a web browser. The Minikube Dashboard provides a real-time, graphical view of your workloads, and it’s an incredible tool for both beginners and advanced users.

The solid green circle shows that 100% of our desired pods are healthy and running.

The Pod List shows all five of our Nginx pods (nginx-pod through nginx-pod5) lined up perfectly.

The Metadata at a Glance: Without typing a single command, we can see the internal IP addresses, the image versions (nginx:1.22.1), and even how long each pod has been alive.

The Sidebar: Notice the menu on the left. This is where you can explore more advanced building blocks like ConfigMaps, Secrets, and Storage Classes as you progress in your journey.

Step 10: Powering Down
Once you’ve finished your lab session, it’s best practice to stop your local cluster to save your machine's battery and CPU.

The screenshot shows the transition from an active environment to a clean stop.

$ minikube stop: This gracefully powers down the Minikube virtual machine.

$ minikube status: Confirming the shutdown. You can see the host, kubelet, and apiserver are all now in a Stopped state.

Your work isn't lost. The next time you run minikube start, your namespaces and manifests will be right where you left them.

Before advancing to more complex application deployment and management methods, become familiar with Pod operations with additional commands such as:

$ kubectl apply -f nginx-pod.yaml
$ kubectl get pods
$ kubectl get pod nginx-pod -o yaml
$ kubectl get pod nginx-pod -o json
$ kubectl describe pod nginx-pod
$ kubectl delete pod nginx-pod

Conclusion

Bridging the Gap Between Code and Infrastructure
Building this fleet of Nginx pods was more than just a technical exercise, it was a demonstration of how a structured "Build, See, Destroy" approach ensures infrastructure reliability. By moving from imperative CLI commands to declarative YAML and JSON manifests, we create a system that is version-controlled, repeatable, and scalable—the core pillars of a modern DevOps culture.

For me, the real power of Kubernetes lies in its self-healing nature and resource isolation. Whether it’s troubleshooting a missing client certificate or using the Dashboard to verify cluster health, the goal remains the same: ensuring high availability and operational excellence for the end user.

As the tech landscape continues to evolve, mastering these foundational building blocks is what allows us to build the resilient, sovereign digital infrastructures of tomorrow.

From Code to Clouds: Hosting a Professional Resume on GitHub Pages

Rahimah Sulayman — Thu, 23 Apr 2026 00:38:47 +0000

Introduction

Imagine an employer or recruiter landing on your profile. Instead of a standard, static PDF, they are greeted with a fast, responsive, and live-hosted website that showcases your professional journey with precision. It doesn’t just show them your experience, it proves you have the technical initiative to build, manage, and deploy your own digital footprint.

In this article, I’ll walk you through how I took a professional Pilot’s resume from a local code editor to a live URL using HTML, CSS, and GitHub Pages, including specific terminal hurdles I encountered along the way.
Learning Objectives:

Configure my global Git identity.
Initialize and manage a clean local workspace.
Troubleshoot common terminal errors like fatal: not a git repository.
Deploy a live project using GitHub Pages.

** Prerequisites**
To follow along with this tutorial, you will need to have Git Bash installed on your Windows machine. You can download the official installer directly from the Git website:

Download Git for Windows

Step 1: Setting the Foundation
Every successful deployment starts with identity. Before Git can track your progress, it needs to know who is behind the code. I started by configuring my global credentials in the terminal to ensure every commit was correctly attributed to my profile.

Using git config --list is a quick way to verify your setup and avoid Permission Denied errors later in the workflow.

NOTE: Only two lines of output appeared because I have configured my environment before this exercise.

Step 2: Building the Workspace
Organization is key to a smooth deployment. Instead of working out of a cluttered root directory, I used the terminal to create a dedicated space for my project. By navigating to the Desktop and using mkdir and touch, I established a clean environment for my source files.

The Workflow:

cd: Navigating to the right environment.

mkdir website: Creating a isolated container for the project.

touch index.html: Generating the entry point for my live site.

Step 3: Bridging Local to Remote
With the local code ready, the next step was creating a remote repository on GitHub. This is where the magic of Hosting begins. By clicking that New button, I created a central hub (Git-Basics101) that would eventually serve my resume to the world.

NOTE: Creating a remote repository is like setting up a destination for a flight, you need a clear target before you can push your data into the clouds.

Then I copied the HTTPS url, to use in the terminal.

Step 4: Troubleshooting the Workflow
The Git Discovery Error occurred when trying to link my remote. I hit the fatal: not a git repository error. This was a great reminder that git init must be the very first step before any remote connections can be made.

Step 5: Mastering the Editor
To ensure the final product was polished and free of errors, I utilized the Vim (vi) editor directly within the terminal. This allowed me to inspect the index.html file in a raw environment.
I used the cat command to verify my code before it goes live.
NOTE: This resume is not real, but for demo purpose only.

Step 7: Staging for Deployment
Here am moving files from untracked zone to the staged zone. By using git status, I could see exactly what Git was watching. But before that, I used the ls to verify that the file is in that particular location in my local environment. Initially, my index.html was in red (untracked), but with a quick git add ., it turned green, ready and waiting to be committed.

This visual confirmation in the terminal is the developer's safety check to ensure only the right files are being sent to the server.

Step 8: Sealing the Version
With the files staged, it was time to create a permanent snapshot of my work. Running git commit -m "create index.html" acted as the official seal for this version of the project.

The terminal output showing 1 file changed" and "130 insertions is more than just text, it’s a receipt of my progress. By providing a clear, descriptive message, I’ve ensured that any future collaborator (or even my future self) understands exactly what this change was for.

Step 9: Overcoming the "Origin" Obstacle by authentication
One of the most common hurdles for any developer is connecting a local project to a remote server. As seen in my terminal, I initially hit a fatal: origin does not appear to be a git repository error. This happened because my local folder hadn't been introduced to GitHub yet.

Note: I resolved this by explicitly adding the remote origin URL and password. It was a another reminder that Git needs a clear map of where your code is supposed to go before it can start the journey.

In the modern Git workflow, security is paramount. GitHub requires a Personal Access Token (PAT) instead of a regular password. So I navigated to my Developer Settings to generate a Classic token. This token acts as a secure key, allowing my terminal to communicate safely with my GitHub account.

Step 10: The Successful Push
With the connection established, I ran the final command: git push -u origin master. Seeing those lines of code: Enumerating objects, Counting objects, and finally the URL to the remote repository—is the ultimate mission accomplished moment for a developer.

The code was no longer just on my laptop, it was officially live in the cloud.

Step 11: Activating GitHub Pages
With the code successfully pushed to the Git-Basics101 repository, the final piece of the puzzle was turning on the hosting.

I navigated to the Settings tab of my repository, selected the Pages menu on the left, and set the build source to the master branch and saved the change. Within seconds, GitHub provided a live link. This transition from a local index.html file to a globally accessible URL is the ultimate goal of any web deployment project.

Conclusion:

Building this resume was more than just a coding exercise, it was a lesson in the modern developer's workflow. Errors aren't failures, they are the terminal's way of teaching you the correct sequence of operations.

The result? A professional, responsive resume that is ready for the world to see.

Installing Local Kubernetes Clusters

Rahimah Sulayman — Fri, 17 Apr 2026 21:37:51 +0000

Now that we have familiarized ourselves with the default minikube start command, let's dive deeper into Minikube to understand some of its more advanced features.

The minikube start by default selects a driver isolation software, such as a hypervisor or a container runtime, if one (VitualBox) or multiple are installed on the host workstation. In addition it downloads the latest Kubernetes version components. With the selected driver software it provisions a single VM named minikube (with hardware profile of CPUs=2, Memory=6GB, Disk=20GB) or container (Docker) to host the default single-node all-in-one Kubernetes cluster. Once the node is provisioned, it bootstraps the Kubernetes control plane (with the default kubeadm tool), and it installs the latest version of the default container runtime, Docker, that will serve as a running environment for the containerized applications we will deploy to the Kubernetes cluster.
The minikube start command generates a default minikube cluster with the specifications described above and it will store these specs so that we can restart the default cluster whenever desired. The object that stores the specifications of our cluster is called a profile.

As Minikube matures, so do its features and capabilities. With the introduction of profiles, Minikube allows users to create custom reusable clusters that can all be managed from a single command line client.

The minikube profile command allows us to view the status of all our clusters in a table formatted output.
Now, we'll start the minikube indicating the driver, which is Docker in this case.
Wait for it to finish! You'll see a message like "Done! kubectl is now configured." Once you see that, then you can try another Kubernetes command.

Now, we'll run the minikube status. Once Minikube is "Running," you have a tiny one-node Kubernetes cluster alive on your machine.

If you see a node named minikube with a status of Ready, you officially have a Kubernetes cluster running on your laptop! We'll check by running the kubectl get nodes command:

minikube stop: With the this command, we can stop Minikube. This command stops all applications running in Minikube, safely stops the cluster and the VM, preserving our work until we decide to start the Minikube cluster once again, while preserving the Minikube VM.

minikube status

Assuming we have created only the default minikube cluster, we could list the properties that define the default profile with:

This table presents the columns associated with the default properties such as the profile name: minikube, the isolation driver: VirtualBox, the container runtime: Docker, the Kubernetes version: v1.28.3, the status of the cluster - running or stopped. The table also displays the number of nodes: 1 by default, the private IP address of the minikube cluster's control plane VirtualBox VM, and the secure port that exposes the API Server to cluster control plane components, agents and clients: 8443.

To create a brand-new cluster with 2 nodes named lab-cluster, you use the --nodes flag. However, since you already have a single-node cluster stopped (as seen in your screenshot), we need to start it back up with the multi-node configuration. We'll run the multi-node command.

Once the cluster starts, we'll use the next three commands to see the difference: kubectlgetnodes

minikube profile list: Using this command, you can check the Minikube Profiles and see both the original cluster and the new 2-node cluster side-by-side.
The minikube profile list command shows the two separate slots you have created on your machine:

lab-cluster: This is the active cluster. It is running on the docker driver with 2 nodes and currently has a status of OK. The asterisk (*) in the ACTIVE_PROFILE column indicates that any kubectl commands ran right now will target this cluster.

minikube: This is the original single-node cluster. It is currently Stopped, meaning it isn't consuming any RAM or CPU, but its configuration and any data it had is are safely saved.

kubectl get nodes -o wide: This gives a detailed View: you can see which node is the Control Plane (the brain) and which is the Worker (the muscle).
This command shows the details of the nodes inside your active lab-cluster profile:

lab-cluster(control-plane): This is the brain of your cluster. It manages the state, schedules applications, and handles the API.

lab-cluster-m02: This is your second node. In a multi-node setup, this acts as a Worker node where your actual application containers (Pods) will run.

Ready Status: Both nodes are Ready, meaning they are healthy and communicating with each other.
And the -o wide flag gives you deeper technical insights:

Internal-IP: Your nodes have unique internal addresses (192.168.58.2 and 192.168.58.3) to talk to each other.
OS-Image: They are running Debian GNU/Linux 12 inside their Docker containers.
Container-Runtime: They are using Docker v1.35.1 to actually spin up the containers.

The role of the second cluster is labeled as none because it wasn't specified during creation.
Now we'll stop the lab-cluster and start the minikube.
This is known as Switching Contexts and should be mastered.
If you want to go back to your first cluster, you don't need to delete anything. You just switch the Active pointer:

Stop current: minikube stop -p lab-cluster

Switch & Start: minikube start -p minikube

Advanced Minikube features

minikube profile list

In order to set the profile to lab-cluster, we' ll use the command: profile lab-cluster

Then start the minikube again using minikube start
When it is time to run the cluster again, simply run the minikube start command (driver option is not required), and it will restart the earlier bootstrapped Minikube cluster.

Now I want the terminal to look organized and show worker, I can manually assign the role using the label command. Run this in your VS Code terminal:

then change context to lab-cluster(to make the target cluster lab-cluster) and then run get nodes command.
is now worker!

Run minikube profile list command, the profile will now be set to the lab-cluster.

Run kubectl config view, it gives a detailed information about the cluster and its nodes.
The kubeconfig includes the API Server's endpoint server: ht‌t‌ps://127.0.0.1:49687 and the minikube user's client authentication key and certificate data.

With the kubectl is installed, we can display information about the Minikube Kubernetes cluster with the kubectl cluster-info command:

Run the cluster info command, this gives information about the IP address the cluster is running at.

Kubernetes master is running at htt‌‌ps://127.0.0.1:49687
KubeDNS is running at htt‌‌ps://127.0.0.1:49687/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

The Kubernetes Dashboard

The Kubernetes Dashboard provides a web-based user interface for Kubernetes cluster management. Minikube installs the Dashboard as an addon, but it is disabled by default. Prior to using the Dashboard we are required to enable the Dashboard addon, together with the metrics-server addon, a helper addon designed to collect usage metrics from the Kubernetes cluster. To access the dashboard from Minikube, we can use the minikube dashboard command, which opens a new tab in our web browser displaying the Kubernetes Dashboard, but only after we list, enable required addons, and verify their state:

$ minikube addons list

$ minikube addons enable metrics-server

$ minikube addons enable dashboard

$ minikube addons list

$ minikube dashboard

Run minikube addons list

In order to enable metrics-server addon, run minikube addons enable metrics-server

Verify that the metrics-server is now enabled.

Run minikube addons enable dashboard

Verify that dashboard enabled.

Run the minikube dashboard command, and a url is displayed which opens a new window when clicked.
Or you can simply run minikube dashboard --url

The dashboard is empty as expected.

So we'll create one pod using this command: kubectl run my-first-pod --image=nginx

Verify it's now displayed on the dashboard

Run the logs command for my-first-pod

log can also be performed on the dashboard.

APIs with kubectl proxy

Issuing the kubectl proxy command, kubectl authenticates with the API server on the control plane node and makes services available on the default proxy port 8001.

First, we issue the kubectl proxy command:

$ kubectl proxy

Starting to serve on 127.0.0.1:8001

It locks the terminal for as long as the proxy is running, unless we run it in the background (with kubectl proxy &).

When kubectl proxy is running, we can send requests to the API over the localhost on the default proxy port 8001 (from another terminal, since the proxy locks the first terminal when running in foreground):

$ curl http://localhost:8001/

But it worked on the browser:

So we'll use another terminal because the proxy is now locked in the first terminal.

This works!

I stopped the clusters from dashboard and verified using the command:

Conclusion

Mastering Minikube is about more than just starting a cluster, it’s about creating a reliable, reproducible environment that mirrors the complexities of the cloud. By moving beyond default settings and embracing multi-node profiles, you transition from a student of Kubernetes to an engineer capable of architecting resilient systems.

As you continue building, remember that a well-organized local environment is the foundation of a successful deployment pipeline. Whether you are assigning worker roles in the CLI or monitoring pod health on the dashboard, these skills ensure that your infrastructure is as robust as the code running on it.

Happy Kube-ing! Post by rahimah_dev

Mastering Azure Monitor: Deployment and Configuration

Rahimah Sulayman — Thu, 16 Apr 2026 19:36:28 +0000

Introduction

While working on a comprehensive deployment of Azure Monitor, I hit a common but frustrating wall: the dreaded SubscriptionIsOverQuotaForSku error. Instead of stopping, I pivoted, re-engineering my deployment across Korea Central and East US to maintain uptime and visibility(since we're in a learning environment).

In this post, I’ll walk you through how I deployed a hybrid environment featuring Windows Server (IIS), Linux (Ubuntu), and a SQL-backed Web App, all while configuring the observability layers needed to keep a modern enterprise running.

Here is one of the scenarios that would urgently require one of the tasks below: An insurance firm just suffered a minor brute-force attack because a junior dev left a virtual machine open to the entire internet. The CTO orders an immediate lockdown of all infrastructure.

My Task: I changed the RDP Source to My IP and manually configured Inbound Security Rules for HTTP (Port 80).

The necessity: This is a critical security task. By restricting RDP access to only my specific IP address, I effectively closed the front door to hackers.

This exercise should take approximately 30 minutes to complete.

Prepare your bring-your-own-subscription (BYOS)

This set of lab exercises assumes that you have global administrator permissions to an Azure subscription.

1.In the Azure Portal Search Bar, enter Resource Groups and select Resource groups from the list of results.

2.On the Resource Groups page, select Create.

3.On the Create a Resource Group page, select your subscription and enter the name rg-alpha. Set the region to East US, choose Review + Create, and then choose Create.

NOTE: This set of exercises assumes that you choose to deploy in the East US Region, but you can change this to another region if you choose. Just remember that each time you see East US mentioned in these instructions you will need to substitute the region you have chosen.

Create App Log Examiners security group

In this exercise, you create an Entra ID security group.

1.In the Azure Portal Search Bar, enter Azure Active Directory (or Entra ID) from the list of results.

2.On the Default Directory page, select, + Add, then Groups.

3.On the New Group page, provide the values in the following table and choose Create.

Property	Value
Group type	Security
Group name	App Log Examiners
Group description	App Log Examiners

Deploy and configure WS-VM1

In this exercise, you deploy and configure a Windows Server virtual machine.

1.In the Azure Portal Search Bar, enter Virtual Machines and select Virtual Machines from the list of results.

2.On the Virtual Machines page, choose Create and select Azure Virtual Machine.

3.On the Basics page of the Create A Virtual Machine wizard, select the following settings and then choose Review + Create.

Property	Value
Subscription	Your subscription
Resource Group	rg-alpha
Virtual machine name	WS-VM1
Region	East US
Availability options	No infrastructure redundancy required
Security type	Standard
Image	Windows Server 2022 Datacenter: Azure Edition – x64 Gen2
VM architecture	x64
Size	Standard_D4s_v3 – 4 vcpus, 16 GiB memory
Administrator account	prime
Password	[Select a unique secure password] P@ssw0rdP@ssw0rd
Inbound ports	RDP 3389

4.Review the settings and select Create.

5.Wait for the deployment to complete. Once deployment completes choose Go to resource.

6.On the WS-VM1 properties page, choose Networking.

7.On the Networking page, select the RDP rule.

8.On the RDP rule space, change the Source to My IP address and choose Save.

This restricts incoming RDP connections to the IP address you’re currently using.
9.On the Networking page, choose Add inbound port rule.

10.On the Add inbound security rule page, configure the following settings and choose Add.

Property	Value
Source	Any
Source port ranges	*
Destination	Any
Service	HTTP
Action	Allow
Priority	310
Name	AllowAnyHTTPInbound

11.On the WS-VM1 page, choose Connect.

12.Under Native RDP, choose Select.
13.On the Native RDP page, choose Download RDP file and then open the file. Opening the RDP file opens the Remote Desktop Connection dialog box.

14.On the Windows Security dialog box, choose More Choices and then choose Use a different account.

15.Enter the username as .\prime and the password as the secure password you chose in Step 3, and choose OK.

16.When signed into the Windows Server virtual machine, right-click on the Start hint and then choose Windows PowerShell (Admin).

17.At the elevated command prompt, type the following command and press Enter. Install-WindowsFeature Web-Server -IncludeAllSubFeature -IncludeManagementTools

18.When the installation completes run the following command to change to the web server root directory. cd c:\inetpub\wwwroot\
19.Run the following command. Wget https://raw.githubusercontent.com/Azure-Samples/html-docs-hello-world/master/index.html -OutFile index.html

Deploy and configure LX-VM2

In this exercise you deploy and configure a Linux virtual machine.

1.In the Azure Portal Search Bar, enter Virtual Machines and select Virtual Machines from the list of results.

2.On the Virtual Machines page, choose Create and select Azure Virtual Machine.

3.On the Basics page of the Create A Virtual Machine wizard, select the following settings and then choose Review + Create.

Property	Value
Subscription	Your subscription
Resource Group	rg-alpha
Virtual machine name	Linux-VM2
Region	East US
Availability options	No infrastructure redundancy required
Security type	Standard
Image	Ubuntu Server 20.04 LTS – x64 Gen2
VM architecture	x64
Size	Standard_D2s_v3 – 2 vcpus, 8 GiB memory
Authentication type	Password
Username	Prime
Password	[Select a unique secure password] P@ssw0rdP@ssw0rd
Public inbound ports	None

4.Review the information and choose Create.

5.After the VM deploys, open the VM properties page and choose Extensions + Applications **under **Settings.

6.Choose Add and select the Network Watcher Agent for Linux. Choose Next and then choose Review and Create. Choose Create.

NOTE: The installation and configuration of the OmsAgentForLinux extension will be performed in Exercise 2 after the Log Analytics workspace is created.

Deploy a web app with an SQL Database

1.Ensure that you’re signed into the Azure Portal.
2.In your browser, open a new browser tab and navigate to https://github.com/Azure/azure-quickstart-templates/tree/master/quickstarts/microsoft.web/web-app-sql-database

3.On the GitHub page, choose Deploy to Azure.

4.A new tab opens. If necessary, re-sign into Azure with the account that has Global Administrator privileges.
5.On the Basics page, select Edit template.

6.In the template editor, delete the contents of lines 158 to 174 inclusive and delete the “,” on line 157. Choose Save.

7.On the Basics page, provide the following information and choose Next.

Property	Value
Subscription	Your subscription
Resource Group	rg-alpha
Region	East US
Sku Name	F1
Sku Capacity	1
Sql Administrator Login	prime
Sql Administrator Login Password	[Select a unique secure password] P@ssw0rdP@ssw0rd

Quota limits are often region-specific. If you are hitting a zero-limit in one location, another might have availability.
Go back to the Basics tab and try switching the Region to a major hub like East US, West US 2, or North Europe.

In my specific case, Korea Central is often a good alternative when am faced subscription roadblocks in other regions recently.
Hence, I changed the resource group to rg-alpha2 and Region to Korea Central.

NOTE: If you absolutely need that specific region and size, you have to ask Microsoft to "unlock" it for you.

8.Review the information presented and select Create.

9.After the deployment completes, choose Go to resource group.

Deploy a Linux web app

1.Ensure that you’re signed into the Azure Portal.
2.In your browser, open a new browser tab and navigate to https://learn.microsoft.com/en-us/samples/azure/azure-quickstart-templates/webapp-basic-linux/
3.On the GitHub page, choose Deploy to Azure.

4.On the Basics page, provide the following information and choose Next.

Property	Value
Subscription	Your subscription
Resource Group	rg-alpha
Region	East US
Web app Name	AzureLinuxAppWXYZ (assign a random number to the final four characters of the name)
Sku	S1
Linux Fx version	php 7.4

5.Review the information and choose Create.

So I changed the resource group and Region again.

Deployment failed because the webApp name already exists, click on Redeploy and edit the name.

6.Now that Deployment is complete, Go To Resource.

Conclusion

The "Invisible Skill of Cloud Engineering
Setting up a multi-tier environment on Azure is more than a checklist of installations, it is a lesson in resiliency. This project challenged me to manage a hybrid ecosystem—bridging Windows Server management, Linux observability, and SQL-backed web applications, all while navigating real-world infrastructure constraints like subscription quotas and regional limitations.

KUBERNETES - Deploying a Standalone Application 1

Rahimah Sulayman — Sun, 05 Apr 2026 16:38:43 +0000

Introduction

Kubernetes has a reputation for being a wall of YAML, but it doesn't have to start that way. If you’re looking for a visual, hands-on way to understand how Pods, Deployments, and Services actually interact, you’re in the right place. Today, we’re firing up the Minikube Dashboard to deploy a standalone web server with just a few clicks. By the end of this post, you won't just have an Nginx server running, you'll understand the labels and selectors that hold the entire K8s ecosystem together.

Learning Objectives

By the end of this series, you should be able to:

Deploy an application from the dashboard.
Deploy an application from a YAML file using kubectl.
Expose a service using NodePort.
Access the application from outside the Minikube cluster.

Deploying an Application Using the Dashboard (1)

Let's learn how to deploy an nginx webserver using the nginx container image from Docker Hub.

Start Minikube and verify that it is running. Run this command first:

$ minikube start

Then verify Minikube status:

$ minikube status

Start the Minikube Dashboard. To access the Kubernetes Web IU, we need to run the following command:

$ minikube dashboard

Running this command will open up a browser with the Kubernetes Web UI, which we can use to manage containerized applications. By default, the dashboard is connected to the default Namespace. Therefore, all the operations will be performed inside the default Namespace.

Deploying an Application - Accessing the Dashboard

NOTE: In case the browser is not opening another tab and does not display the Dashboard as expected, verify the output in your terminal as it may display a link for the Dashboard (together with some Error messages). Copy and paste that link in a new tab of your browser. Depending on your terminal's features you may be able to just click or right-click the link to open directly in the browser.

The link may look similar to:

http://127.0.0.1:40235/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

Chances are that the only difference is the PORT number, which above is 40235. Your port number may be different.
After a logout/login or a reboot of your workstation the expected behavior may be observed (where the minikube dashboard command directly opens a new tab in your browser displaying the Dashboard).

Deploying an Application Using the Dashboard (2)

Deploy a webserver using the nginx image. From the dashboard, click on the + symbol at the top right corner of the Dashboard. That will open the create interface as seen below:

Create a New Application - Interface

From there, we can create an application using valid YAML/JSON configuration data, from a definition manifest file, or manually from the Create from form tab. Click on the Create from form tab and provide the following application details:

The application name is web-dash.
The container image to use is nginx.
The replica count, or the number of Pods, is 1.
Service is External, Port 8080, Target port 80, Protocol TCP. Namespace is default

Deploy a Containerized Application - Interface

If we click on Show Advanced Options, we can specify options such as Labels, Namespace, Resource Requests, etc. By default, the Label is set to the application name. In our example k8s-app: web-dash Label is set to all objects created by this Deployment: Pods and Services (when exposed).

By clicking on the Deploy button, we trigger the deployment. As expected, the Deployment web-dash will create a ReplicaSet (web-dash-74d8bd488f), which will eventually create 1 Pod replica (web-dash-74d8bd488f-dwbzz).

NOTE: Add the full URL in the Container Image field docker.io/library/nginx if any issues are encountered with the simple nginx image name (or use the k8s.gcr.io/nginx URL if it works instead).

NOTE: The resource names are unique and are provided for illustrative purposes only. The resources in your clusters and dashboards will display different names, but the naming structure follows the same convention.

Deploying an Application Using the Dashboard (3)

Once we create the web-dash Deployment, we can use the resource navigation panel from the left side of the Dashboard to display details of Deployments, ReplicaSets, and Pods in the default Namespace.

From the Dashboard we can display individual objects’ properties by simply clicking the object’s name. From the commands menu symbol (the vertical three-dots) at the far-right we can easily manage their state. Easily scale up the Deployment to a higher number of replicas, and observe the additional Pods spin up, or scale it down to fewer replicas. Attempt to delete one of the individual Pods of the Deployment. What do you notice after a few seconds? We can even delete the Deployment, an action that results in all its Pod replicas being terminated. But for now, let’s keep the Deployment so we can analyze it further.

Dashboard displaying Deployments, Pods, and ReplicaSets

The resources displayed by the Dashboard match one-to-one resources displayed from the CLI via kubectl. List the Deployments. We can list all the Deployments in the default Namespace using the kubectl get deployments command:

$ kubectl get deployments

List the ReplicaSets. We can list all the ReplicaSets in the default Namespace using the kubectl get replicasets command:

$ kubectl get replicasets

List the Pods. We can list all the Pods in the default namespace using the kubectl get pods command:

$ kubectl get pods

List Deployment, ReplicaSet and Pod with a single command:

$ kubectl get deploy,rs,po

Exploring Labels and Selectors (1)

Earlier, we have seen that labels and selectors play an important role in logically grouping a subset of objects to perform operations. Let's take a closer look at them.

Display the Pod's details. We can look at an object's details using the kubectl describe command. In the following example, you can see a Pod's description:

$ kubectl describe pod web-dash-6bf994f6

Exploring Labels and Selectors (2)

List the Pods, along with their attached Labels. With the -L option to the kubectl get pods command, we add extra columns in the output to list Pods with their attached Label keys and their values. In the following example, we are listing Pods with the Label keys k8s-app and label2:

$ kubectl get pods -L k8s-app,label2

All of the Pods are listed, as each Pod has the Label key k8s-app with value set to web-dash. We can see that in the K8S-APP column. As none of the Pods have the label2 Label key, no values are listed under the LABEL2 column.

Select the Pods with a given Label. To use a selector with the kubectl get pods command, we can use the -l option. In the following example, we are selecting all the Pods that have the k8s-app Label key set to value web-dash:

$ kubectl get pods -l k8s-app=web-dash

In the example above, we listed all the Pods we created, as all of them have the k8s-app Label key set to value web-dash.

Try using k8s-app=webserver as the Selector:

$ kubectl get pods -l k8s-app=webserver

No resources found.
As expected, no Pods are listed.

Deploying an Application Using the CLI (1)

To deploy an application using the CLI, let's first delete the Deployment we created earlier.

One method to delete the Deployment we created earlier is from the Dashboard, from the Deployment’s commands menu. Another method is using the kubectl delete command. Next, we are deleting the web-dash Deployment we created earlier:

$ kubectl delete deployments web-dash

Deleting a Deployment also deletes the ReplicaSet and the Pods it created:

$ kubectl get replicasets

$ kubectl get pods

Summary

In this first installment, we were able to cover the Visual Orchestration & Lifecycle Basics. We established a rock-solid foundation for managing containerized applications. We moved beyond simple container execution and began exploring the automated world of Kubernetes orchestration.

Core Competencies Achieved
Cluster Lifecycle Management:
Initiated and verified the local Kubernetes environment using minikube start and status. This confirmed the control plane, Kubelet, and API server were operational.

GUI-Driven Deployment: Leveraged the Kubernetes Dashboard to deploy a standalone Nginx application. This demonstrated the "Create from Form" workflow, which simplifies resource definition for those new to the ecosystem.

Resource Hierarchy Identification: Observed the relationship between Deployments, ReplicaSets, and Pods. We verified how a single Deployment instruction automatically handles the creation of underlying ReplicaSets to ensure the desired state of our Pods.

See you in the next part!

Master the Linux Terminal for Modern Data Analytics

Rahimah Sulayman — Mon, 30 Mar 2026 13:56:35 +0000

INTRODUCTION

In the high-stakes world of Data Analytics, your tools should never be your bottleneck. Most analysts can build a dashboard, but the elite 1% know how to handle data where it actually lives, that is, the Command Line.

Imagine a 10GB CSV file that crashes Excel on sight. While others wait for their GUI to load, the modern analyst uses the Linux Terminal to slice, filter, and audit millions of rows in milliseconds.
As a Data Analyst, I’ve realized that the CLI isn't just an 'extra' skill, it is the engine of efficiency in 2026. While prepping raw data for Power BI, mastering these 'black screen' secrets is how you move from being a passenger to being the pilot of your data infrastructure.

Welcome to the world of Linux! Think of the Linux file system as an upside-down tree. Everything grows from a single point at the very top. What is the Root Directory? The root directory is the starting point of the entire Linux file system.
Every single file, folder, and drive on your computer is contained within it.
It is represented by a single forward slash: /.
The "Parent": It has no parent directory, it is the absolute top level.

To get started, you have three ways to use these exact Linux commands on a Windows machine:

1. WSL
WSL (Windows Subsystem for Linux) is a literal Linux system living inside your Windows computer. It’s what almost all developers use today.

How to get it: Open your Windows Terminal and type wsl --install.
This runs the Result on your actual hard drive.

2.Git Bash
If you install Git for Windows, it comes with Git Bash. It’s a small emulator that lets you use Linux commands to navigate your Windows folders.

In Git Bash, your C: drive is usually mapped to /c/.

3.PowerShell
PowerShell actually has "aliases" for some Linux commands to make life easier for people moving between systems. It serves as a translator.
NOTE: Windows and Linux speak different "languages." though there are some similarities.
Windows uses PowerShell or Command Prompt (CMD), where the root is usually C:. Linux uses the Bash shell, where the root is /.

I'll be using Git Bash is actually one of the most popular ways for developers to use Linux commands on a Windows computer,and I already have it in VS Code.

When you open Git Bash in VS Code, you are essentially running a "mini Linux environment" that can see your Windows files.

HOW TO USE IT

Open the Terminal: In VS Code, press Ctrl +` (the backtick key). Or select View, then Terminal.

Select Git Bash: In the top-right corner of the terminal pane, click the dropdown arrow (usually says "powershell" or "cmd") and select Git Bash.

If you want to explore these right now in your terminal, here is how you can use those commands:

Jump to Root: Type cd / to move to the very top.
See Where You Are: Type pwd(Print Working Directory). It should just show /.
Look Around: Type ls to see all the folders (like bin, etc, and home) living inside the root. These aren't your Windows C: drive folders, they are the virtual Linux-style folders Git Bash creates to make your commands work.

This is the most important part for a beginner. Git Bash "mounts" your Windows drives inside the root.

To go to your C: Drive, type: cd /c/
To go to your Desktop, type: cd /c/Users/YourUsername/Desktop

Change directory to the desktop

NOTE: My computer is using the username Admin inside the folders, even though your machine name is RAHIMAH-ISAH. Linux is very literal about where things are stored.
So cd /c/Users/Admin/Desktop is the full "map" to my Desktop

where:

cd: Change Directory.
/c/: This is your C: Drive.
Desktop: This is your destination.

To move from my current location into the My_Analytics folder on the Desktop, I'll use the cd (change directory) command:
cd My_Analytics

Create a "test" folder
To create a new folder (directory), use the mkdir (make directory) command:
mkdir test

But first, change directory to the previous: cd ..

If you want to see if your new folder was actually created, type ls. It will list everything in your current location, and you should see test appearing in the list.

Out of curiosity, being a beginner it's allowed to check the Desktop.

Let's learn how to use these, try this "Real World" sequence in the VS Code Git Bash:

Go to your User folder: cd ~ (The tilde ~ is a Linux shortcut for your home).

Create a project folder: mkdir my-linux-practice2

Enter the folder: cd my-linux-practice2

Create a blank file: touch notes.txt

Verify it's there: ls

I made use of "-" instead of "_".
Let's make the correction together.

In Linux, we use the mv command (short for move) to rename files and folders.

Since am currently on the Desktop, I can "move" the folder from the old name to the new name.

The Correction Command
Type this and press Enter:

mv linux-practice linux_practice

How it works
The mv command follows a simple logic:
mv [old_name] [new_name]

linux-practice: The folder as it exists now.
linux_practice: What you want it to be named.
I did not remember the exact folder name, so I used the ls command.

And then verified the name change by running ls command.

Create a message
We are going to use the echo command. It literally "echoes" whatever you type back to you, but we are going to use a special symbol > to tell it to echo into a file instead.

Remember to enter the Directory if you aren't already there:
cd /c/Users/Admin/Desktop/notes.txt

echo "Hello from the Linux terminal!" > notes.txt

Read your file
Now, let's see if the file actually contains that message.

Type this and press Enter:

cat notes.txt
cat (short for concatenate) is the standard way to quickly read the contents of a file in the terminal.

What just happened?

echo "text": Prepared the message.
>: This is called a Redirect. It took the message that would normally print on the screen and "poured" it into the file.
cat: Showed you the result.

Since we've already used > to create the file, let's learn how to add a second line to it without deleting the first one.

Step 1:Go back into your folder (if you left it)
cd /c/Users/Admin/Desktop/notes

Step 2:Add a new line (use two symbols >>)

> = Overwrites the file (deletes old stuff).
>> = Appends (adds to the bottom).

echo "This is my second line!" >> notes.txt

Step 3:Read it (check your spelling!)
cat notes.txt

Use echo with >> to add another line:

echo "This is my third line!" >> notes.txt

Verify the result:
If you run cat notes.txt now, you should see:

Hello from me!
This is my second line.
This is my third line!

NOTE:
In Linux, case sensitivity is everything. If you create a file named Notes.txt (with a capital N) and then try to read notes.txt (with a lowercase n), the terminal thinks they are two completely different files.
When you type a command like cat and press Enter, the terminal will seem to "freeze." This is because cat without a filename waits for you to type something into it.

Whenever a command gets stuck like that, press Ctrl + C on your keyboard to kill the process and get your prompt back.

Hidden files
In Linux, you can make a file "hidden" just by starting its name with a period (.). These are usually used for important system settings that you don't want to see cluttering your folders.

Step 1: Create a hidden file (in my folder my_linux_practice2)
Type this and press Enter:
touch .secret_note.txt

Step 2:Try to find it with a normal ls
Type this:
ls
(Notice that it doesn't show up, even though it's there.)

Step 3:Reveal the hidden files
To see everything (including hidden files), you need to add a "flag" to your command.
Type this:
ls -a

-a: stands for "all".

.: This represents the current directory you are in.

..: This represents the parent directory (one level up).

.my_secret_file.txt: The brand new hidden file!

Being a Data Analyst and Cloud Engineer, I see these "dot files" (like .git or .env) all the time in your professional work. Knowing how to find them using ls -a is a critical skill.

To delete files in Linux, we use the rm command (short for remove).

Be careful: unlike Windows, there is no "Recycle Bin" in the Linux terminal. Once you delete a file with this command, it is gone for good!

The Deletion Command
Type this and press Enter:

rm .secret_note.txt

Verify it is gone
Since this was a hidden file, a normal ls wouldn't have shown it anyway. To be 100% sure it’s deleted, you need to use the "all" flag again.

Type this:
ls -a

What you should see: notes.txt, plus the system markers . and ...

What should be missing?: .secret_note.txt.

While working, for example, with Azure and Power BI, you'll often have folders full of data files. If you ever need to delete an entire folder and everything inside it, you have to add a "recursive" flag:

rm -r folder_name

Warning: Never type rm -rf /. This tells Linux to "Force Delete Everything starting from the Root," which would erase your entire operating system!

Copying is another fundamental skill, especially when you want to create backups of your scripts or data reports before you make changes.

In Linux, we use the cp (copy) command.

Step 1: Create a simple copy
Let's take the existing notes.txt and create a backup called backup.txt.

Type this and press Enter:

cp notes.txt backup.txt
Step 2: Verify the copy
Now, let's see if you have two separate files now.

Type this:
ls

You should see both notes.txt and backup.txt listed.

Copy into a new folder
Now let's get a bit more organized. Let's create a "logs" folder and copy the file into it.

Step 1:
Create the folder:
mkdir logs

Step 2:
Copy the file into the folder:
cp notes.txt logs/

Step 3:
Check inside the logs folder:
ls logs
This tells ls to look specifically inside the logs directory without you having to cd into it.

Now the logs folder is no longer empty, it contains the notes.txt file.

The "Dot" Trick
If you are already inside a folder and want to copy a file from somewhere else into your current spot, you use a period . (which means "here").

Example (Try this on your own):
cp /c/Users/Admin/Desktop/important.txt .
(This translates to: "Copy important.txt from the Desktop to here.")

Copying a folder
Since we are copying a folder (the logs folder) instead of a single file, we need to use a special flag. In Linux, if you try to copy a folder without this flag, the terminal will give you an error saying "omitting directory."

To copy a directory and everything inside it, we use -r (which stands for recursive).

The Copy Directory Commands
Step 1: Copy the logs folder to a new name
Type this and press Enter:
cp -r logs logs_backup

Step 2:Verify both folders exist
Type this:
ls -F
(The -F flag is a neat trick,it adds a / to the end of folder names so you can easily tell them apart from files!)

Step 3:Copy a file from one folder to another
Let's practice moving things between folders without leaving your current spot. Let's copy the file inside logs into logs_backup but give it a new name.

Type this:
cp logs/notes.txt logs_backup/archive_copy.txt

Step 4:Check the contents of the backup folder
ls logs_backup
You should now see both notes.txt and archive_copy.txt inside that folder.

The "Tab" Trick
To avoid typos (like lowercase vs. uppercase), try this:
Type cd lin and then press the Tab key on your keyboard. Git Bash will automatically finish the word linux_practice for you! It’s like magic and prevents almost all errors. You can try it with the first few letters of your file and folder names.

Creating Multiple folders
Creating multiple folders at once is a huge time-saver for any Data Analyst. Instead of typing mkdir five separate times, we can do it in one single line.

In Linux, there are two ways to do this: the Simple List and the Brace Expansion (the "Pro" way).

Method 1: The Simple List
You can simply type mkdir followed by all the names you want, separated by spaces.
mkdir Jan Feb Mar Apr May Jun

Result: 6 new folders appear instantly.

Method 2: Brace Expansion {} (The Power Move)
This is how engineers create hundreds of folders in a second. It uses curly brackets to tell Linux: "Take this prefix and attach all these options to it."

Try creating six months of data folders like this:

mkdir month_{1..6}
Result: You will get month_1, month_2, up to month_6.

Method 3: Nested Folders (The -p Flag)
Sometimes you want to create a folder inside a folder that doesn't exist yet (like a file path). If you just try mkdir Project/Data, it will fail. You need the -p (parents) flag.

Try this to build a full project structure in one go this way:

mkdir -p Analytics_Project/{customer,date,region,price}

What happened?

It created the main folder Analytics_Project.
Inside it, it created 4 sub-folders: customer, date, region, and price. To see your beautiful new structure without clicking around your Desktop, use the "Recursive List" command: ls -R Cloud_Project

After creating multiple folders, knowing how to clean them up is just as important. In Linux, there are two main ways to delete a directory, depending on whether it has files inside it or not.

Method 1: The "Safety" Way (rmdir)
If a folder is completely empty, you use rmdir (remove directory). This is safe because Linux will refuse to run the command if there is even one tiny file inside, preventing accidental data loss.

Try it on one of your empty month folders:
rmdir Jan

Method 2: The "Force" Way (rm -r)
If the folder has files, scripts, or other folders inside it, rmdir won't work. You must use the rm command with the -r (recursive) flag. This tells Linux to go "inside" the folder and delete everything first, then delete the folder itself.

Try it on your Analytics_Project folder:
rm -r Analytics_Project
A Critical Warning for Cloud Engineers and Data Analysts
In Linux, there is no "Recycle Bin." Once you run rm -r, that data is gone forever.

The "Danger" Command:
You will often see rm -rf.

-r: Recursive (deletes folders).
-f: Force (doesn't ask "Are you sure?").

Always double-check your current location with pwd before running a recursive delete.

The "Real-life" Challenge
We are going to simulate a real-world task: Organizing a project*.
Step 1: Create the Workspace
Create a main project folder and two sub-folders in one line:
**mkdir -p My_Analytics/{raw_data,final_reports}*

Step 2:Create a "Data" file
Let’s create a dummy data file inside the raw_data folder:

touch My_Analytics/raw_data/sales_2026.csv

Step 3:Copy the file (The "Backup" Move)
Before you edit data, you should always have a copy. Use cp (copy)

cp My_Analytics/raw_data/sales_2026.csv My_Analytics/raw_data/sales_backup.csv

Step 4:Move the file (The "Organization" Move)
Now, let's pretend you finished your analysis. Move the original file to the final_reports folder using mv (move):

mv My_Analytics/raw_data/sales_2026.csv My_Analytics/final_reports/

Check Your Work
Use the Tree view (or recursive list) to see your organized project:

ls -R My_Analytics

Since you've already learned how to create, move, and delete folders, the next "superpower" for a Data Analyst is being able to see what is inside a file without needing to open a heavy application like Excel or Notepad.

Imagine you just downloaded a massive dataset from an Azure storage bucket. You need to know if it's the right data before you start your analysis.

Practice 1: Creating a "Data" File
First, let's create a file with some actual content inside it so we have something to look at.

Type this command:

echo -e "ID,Name,Sales\n1,Rahimah,500\n2,Ibrahim,750\n3,Dickson,300" > sales_data.csv
What this does:

echo prints text.
-e allows for "new lines" (\n).
> saves that text into a new file called sales_data.csv.

Practice 2:The "Peeking" Commands
Now, let's look at the data using three different tools.

The cat Command (Concatenate) This dumps the entire file onto your screen.

cat sales_data.csv
Use this when: The file is small (like a configuration file).

2.The head Command
This only shows the first few lines.

head -n 2 sales_data.csv
Use this when you have a 1-million-row CSV and just want to see the column headers.

3.The tail Command
This shows the very end of the file.

tail -n 1 sales_data.csv
Use this when: You want to see the most recent entry in a log file.

Practice 3:The "Search" Power (grep)
This is the command Data Analysts use most. It searches for a specific word inside a file. Suppose you only want to see the sales for "Ibrahim".

Type this:
grep "Ibrahim" sales_data.csv

Result: It will ignore everything else and only show you the row for Ibrahim.

It actually created an .csv file, amazing!

Why this matters for you
Analysts love finding needles in haystacks.

Imagine searching a 2GB file for a specific Transaction ID. In Excel, your computer freezes. In the CLI, grep 'TXN_9984' data.csv finds it in milliseconds.
When you are working as a Data Analyst, you might have thousands of logs. Instead of scrolling through them, you use grep Error to find exactly where something went wrong in your Azure pipeline.

Final Command for today: history
Want to see a list of everything you've done in this session?

Type this in your Git Bash:
history

CONCLUSION

Mastering the Linux Terminal is more than just learning a list of commands; it is about adopting a mindset of efficiency and automation. In an era where data volumes are exploding and cloud infrastructure is the standard, the ability to navigate a server, audit a massive CSV, or automate a directory structure is what separates a traditional analyst from a modern data professional.

As you move from the GUI to the CLI, you aren't just changing how you interact with your computer—you are expanding your capacity to handle "Big Data" that others simply cannot touch. Whether you are building pipelines in Azure, managing repositories on GitHub, or cleaning raw data for Power BI, the terminal is the bridge that connects your analytical skills to the global tech ecosystem.

The Challenge
Don't let these commands sit idle. Open your Git Bash today, navigate to your projects using only your keyboard.

Creating Azure Resources via Azure CLI: Part 3

Rahimah Sulayman — Thu, 19 Mar 2026 15:28:22 +0000

Introduction

In Part 3 of this series, I continue building a fully functional Azure environment using only the Azure CLI, expanding on the resources created in earlier parts. This phase focuses on working with storage, securing sensitive data, and implementing operational best practices.

You’ll see how to create and interact with a storage account, upload and manage files in Blob Storage, securely handle secrets using Azure Key Vault, and explore cost management strategies. Along the way,I also highlight real-world challenges like RBAC permission barriers and subscription limitations. I'll be showing you how to navigate them effectively as a cloud engineer.

Create a Storage Account & Upload Files

Step 1: Create the Storage Account

This will generate a unique random string and create a storage account in Azure.

This is very important because storage accounts provide the scalable backend object storage required for storing logs, backups, container apps, and static assets.

Reliability - Local Redundant Storage (LRS) keeps 3 synchronized copies of your data across multiple fault domains in a single data center.
Protection: Guards against hardware failures (e.g., disk crash).
Limitation: If the entire data center goes down, your data may be lost.
Use case: Cheapest option, good for non-critical data.

Zone-Redundant Storage (ZRS)
Reliability - It replicates your data across multiple availability zones in the same region.
Protection: Survives data center failure (since zones are separate).
Advantage: It has a higher availability than LRS.
Use case: Applications that need high availability within a region.
Geo-Redundant Storage (GRS) (often called regional redundancy)
Reliability - It copies your data to a secondary region far away from the primary region.
Protection: Survives regional outages (e.g., natural disasters).
Bonus: Some versions allow read access to the secondary region, that is, RA-GRS.
Use case: Critical data requiring disaster recovery.

Quick Comparison
Type Copies Location Protection Level
LRS Single data center, Low protection
ZRS Multiple zones (same region), Medium protection
GRS Different regions, High protection

Run the following command block to create a storage account:
$STORAGE_NAME="labstoragefeb26"
az storage account create
--name $STORAGE_NAME
--resource-group azurecli-lab-rg
--kind StorageV2
--location korecentral
--sku Standard_LRS

Step 2:Create a Blob Container

This creates a logical folder/bucket inside the storage account.

It's needed because you cannot upload blobs directly to the storage account root, they must live inside a container.

Security — containers provide access boundaries allowing RBAC segmentation.

To upload a file into an Azure Blob Storage container, use the az storage blob upload command.

az storage container create
--name lab-files
--account-name $STORAGE_NAME
--auth-mode login

auth-mode login : This tells Azure to use your current az login credentials rather than an access key.

Step 3:Upload a file

This will locally scaffold a text file, then pushes it to Azure and stores it as a blob.
It's very much needed because Azure Blob storage is the most common storage mechanism for handling files (like images, docs, and backups).

Pillar Connection
Operational Excellence — automated asset and artifact uploads.
Run:
az storage blob upload
--account-name $STORAGE_NAME
--container-name lab-files
--name sample.txt
--file "C:\Users\Admin\Documents\New folder\sample.txt"
--auth-mode login

NOTE:This error shows that I hit a permissions wall.

The error "You do not have the required permissions" happens because, in Azure, being the "Owner" of a subscription doesn't automatically give you the right to upload data inside a storage account when using auth-mode login. You need a specific Data Plane role.
The solution is to assign the "Storage Blob Data Contributor" Role
You need to give yourself permission to handle the actual data inside the blobs.
RBAC (Role-Based Access Control): Azure separates "Management" (creating the storage account) from "Data" (uploading files).

The Storage Blob Data Contributor role is exactly what the error message is asking for so you can upload, read, and delete blobs.
If you decide to go the Role Assignment route,note that propagation time after running the command takes about 1–2 minutes. Role assignments in Azure can take a moment to "settle" across the global network.
I will go with the alternative (The "Key" Method).
I don't want to deal with roles right now, so I can bypass this by using the storage account's Access Key instead of my login:
Run this command first to get the key:
$ACCOUNT_KEY=$(az storage account keys list --account-name $STORAGE_NAME --query "[0].value" -o tsv)

Then, Upload using the key:
az storage blob upload
--account-name $STORAGE_NAME
--account-key $ACCOUNT_KEY
--container-name lab-files
--name sample.txt
--file "C:\Users\Admin\Documents\New folder\sample.txt"

That success message is exactly what I was looking for! The 100.0000% progress bar and the JSON output confirm that your file, sample.txt, has been successfully uploaded to the lab-files container in Azure.

After the upload using the Access Key method, the next logical step and good practice is to confirm the file is visible in the cloud. This takes us to the next step..
Step 4:List blobs in the container

This queries the Azure storage API for the contents of the container.

It's needed as a verification step to ensure your push succeeded.

Pillar Connection
Operational Excellence — automated verification.
Run this command to list all blobs in your container:

az storage blob list --account-name $STORAGE_NAME
--account-key $ACCOUNT_KEY --container-name lab-files
--output table

If this was just a test, you should know how to remove the file to keep your storage environment clean. To achieve this, run:
az storage blob delete
--account-name $STORAGE_NAME
--account-key $ACCOUNT_KEY
--container-name lab-files
--name sample.txt

By using the $ACCOUNT_KEY, I bypassed the complicated RBAC permissions (Roles) that were blocking you earlier.
While roles are safer for large teams, using the key is the fastest way to get things done in a personal lab environment, such as this one.

Store Secrets in Azure Key Vault

Step 1:Create a Key Vault

This provisions an Azure Key Vault instance.

It's needed credentials, connection strings, certificates and API keys must Never be hard-coded. They belong in Key Vaults.

Pillar Connection
Security — secure secret storage.

Recall that a Key Vault stores certificates, keys and secrets.
Also note that key vault names must be globally unique, just like storage accounts.
Run this command block:
$KV_NAME="labkvrahfeb26"
az keyvault create
--name $KV_NAME
--resource-group azurecli-lab-rg
--location koreacentral
--enable-rbac-authorization false

Step 2:Store a secret

It ingests the db-password secret securely.

It's needed because it provides safe retrieval instead of storing cleartext credentials locally.

Security — ensuring robust secrets lifecycle.
Run this command:
az keyvault secret set
--vault-name $KV_NAME
--name db-password
--value 'SuperSecure@pass123'

Step 3: Retrieve the secret

It fetches the decrypted plain text variable value securely using your currently authenticated user.

It proves the CLI works to securely obtain values from Key Vault context.

Pillar Connection
Security — programmatic retrieval over TLS.
Run the following command:
az keyvault secret show
--vault-name $KV_NAME
--name db-password
--query value
--output tsv

Step 4:Assign VM a Managed Identity to access the vault

This step configures Azure AD to grant the VM identity-based permissions to extract secrets.

It's needed because it allows background services in the VM to get the secret later without logging in themselves.

Pillar Connection
Security — Zero-credential deployment utilizing Managed Identities.
Run this command:
az vm identity assign
--resource-group azurecli-lab-rg
--name lab-vm
$PRINCIPAL_ID=$(az vm show
--resource-group azurecli-lab-rg
--name lab-vm
--query identity.principalId
--output tsv)
az role assignment create
--role 'Key Vault Secrets User'
--assignee $PRINCIPAL_ID
--scope $(az keyvault show --name $KV_NAME --query id --output tsv)

Monitor Costs & Set a Budget Alert

Step 1:Get your subscription ID

This queries the active subscription ID programmatically.

Why It's Needed
Required when sending alerts so it explicitly monitors current active account.

Pillar Connection
Cost Optimization — understanding which account you are billing towards.
Run: SUB_ID=$(az account show --query id --output tsv)
echo "Subscription: $SUB_ID"

Step 2:Create a $10 monthly budget with an alert at 80%
This sets a strict ceiling for consumption using native Azure limits.

Why It's Needed
Setting alerts prevents surprise billing caused by unmonitored rogue or misconfigured compute arrays.

Pillar Connection
Cost Optimization — preventative guard-rails ensuring fiscal control.
Setting a budget is the "responsible" side of being a Cloud Engineer. It proves you aren't just building things, you're managing the Cost Management aspect of the cloud, which is a major focus for businesses in 2026.
Run:
az consumption budget create
--budget-name lab-budget
--amount 10
--category Cost
--time-grain Monthly
--start-date (Get-Date -Format "yyyy-MM-01")
--end-date 2026-12-31
--resource-group azurecli-lab-rg
--notifications '[{"enabled":true,"operator":"GreaterThan","threshold":80,"contactEmails":["you@example.com"]}]'

The output shows notification errors so we'll run another command. This version avoids all the JSON/notification issues that broke earlier.
**$subId = az account show --query id -o tsv

az consumption budget create --budget-name "lab-budget"
--amount 10 --category Cost
--time-grain Monthly --start-date "2026-03-01"
--end-date "2026-12-31" `
--subscription $subId**

This displays a RBACAccessDenied error, but this screenshot:

confirms ownership of the subscription.

This above screenshot shows Invalid budget configuration.

The CLI keeps failing with different error types.

I ran into another Invalid budget configuration error.

I confirmed the subscription is active, enabled:

I ran another command which finally confirms the "root cause" 100%.

From your output:
"quotaId": "FreeTrial_2014-09-01",
"spendingLimit": "On"

This means am using a Free Trial subscription with spending limit ON.
Why the budget creation keeps failing:
Azure does NOT allow budget creation via CLI for:

Free Trial subscriptions
Subscriptions with spending limit ON

That’s why I keep getting invalid budget configuration and
RBACAccessDenied (misleading error).

Important insight
Since I already HAVE a built-in spending cap, it automatically shuts down when credits finish.
So Azure assumes “You don’t need a budget — we already limit your spending.”

These are the available options:

OPTION 1 — Use Azure Portal to create it manually (works sometimes) when CLI/API is blocked.

Go to:
Cost Management → Budgets → + Add

OPTION 2 — Upgrade subscription (guaranteed solution) Click “Upgrade” at the top of your portal and this will remove spending limit, convert to Pay-As-You-Go. This allows budgets and alerts, with Full CLI support.

The ONLY blocker is the Free Trial restriction.

Recommendation: For learning (especially Azure CLI labs), Upgrade the subscription otherwise, you’ll keep hitting hidden limitations like this.

Step 3:Check current resource group costs

This creates Log Analytics workspace to ingest usage metrics and performance logs later on.

Why It's Needed
Provides unified overview. Essential monitoring dependency for true Production Readiness.

Pillar Connection
Operational Excellence — creating the hub for telemetry.
terminal
Run:
az monitor log-analytics workspace create
--resource-group azurecli-lab-rg
--workspace-name lab-logs
--location koreacentral

Clean Up & Document Your Work

Step 1: Delete the resource group (and everything in it)

It removes the resource group and triggers the recursive cascading wipe of all associated child network and data structures attached within it.

Why it's Needed
The ultimate power move of organized Resource tiering and management. Cloud instances incur hourly charges, immediate destruction preserves free-tiers.

Pillar Connection
Cost Optimization — decommission what you no longer use.
terminal
Run:
az group delete --name $azurecli-lab-rg --yes --no-wait
az group list --output table

The fist line of the command deletes ALL resources in the group — VM, VNet, Storage, Key Vault. While the second line
verifies deletion. (wait a few minutes, then check)

Step 2:Create a project folder and write a README

It scaffolds standard markdown files documenting everything accomplished here.

Why It's Needed
It ensures recruiters see exactly what was executed instead of an empty claim regarding Cloud expertise.

Pillar Connection
Operational Excellence — automated documentation.
Run the following commands:
mkdir azure-cli-lab; cd azure-cli-lab
This creates a new directory (folder)
(The semicolon (;) is the valid statement separator in my Powershell version. It does the exact same thing, that is, it tells the computer to finish the first task and then start the second one.)

git init
Initializes a new Git repository in the current directory.

To display the content of a file in the terminal, run this command:
**@'

Azure CLI Cloud Lab

What I Built

A complete Azure environment using only the Azure CLI — no portal.

Resources Created

Resource Group (azurecli-lab-rg in East US)
Virtual Network (10.0.0.0/16) with Subnet (10.0.1.0/24)
NSG with SSH (22) and HTTP (80) rules
Ubuntu VM (Standard_B1s) with Nginx installed
Storage Account with blob container
Key Vault with secret & managed identity
Cost Budget at $10/month with 80% alert

Key Commands

az group create, az vm create, az network vnet create, az storage account create, az keyvault create

What I Learned

How to provision a full Azure environment from the CLI
VNet + NSG = the network security foundation
Key Vault + Managed Identity = zero-credential secret management
Always delete resources after a lab to avoid charges '@ | Set-Content -Path "README.md"**

.
The error you see in my screenshot resulted when I used a bash command instead of PowerShell.

Now that I've "built" the file, let's "see" it. Run this command to read it back in your terminal:
Get-Content README.md

Notice the README.md is in the azure-cli-lab file.

Step 3:Commit and push to GitHub

This pushes your locally created lab notes to an external hosted tracking service.

Why It's Needed
A standard CI workflow for real-world projects and portfolio sharing.

Pillar Connection
Operational Excellence — tracking version history in remote repos.
Run the following commands:
git add .
Stages all changed files for the next commit.
If you want to be specific, you can name the file:git add README.md

git commit -m 'docs: Azure CLI cloud lab — full environment from scratch'
Creates a new commit with all staged changes and the message after -m
git branch -M main
Lists, creates, or manages branches.
git remote add origin https://github.com//azure-cli-lab.git
Stages the specified file(s) for the next commit
git push -u origin main
Uploads your local commits to the remote repository.
The Goal is actually sending the box to the cloud.

The -u "links" your local folder to the GitHub folder forever, so next time you only have to type git push.

We need to make sure there is a "landing pad" waiting for your code on the internet.
Think of it like this - your terminal knows what to send, but GitHub doesn't know where to put it yet.
Step 1: Create the "Landing Pad" (GitHub Website)
Before running the next command, you need to do this manually in your browser:

Go to github.com.
Click the + icon in the top right and select New repository. Name it exactly azure-cli-lab.

Important: Do not check "Initialize this repository with a README" (because we already created one in your terminal).

Scroll to the page bottom and Click Create repository.

Step 2: The "Git Log" Check (Terminal)
While setting that up, let's verify that the current branch 'main' already has commits, by running this command:

git log --oneline

Step 3:Connect and Push
Once the GitHub repository is created on the website,I'll run these two final commands to finish the lab:

Connect your computer to the web address (Replace YOUR_USERNAME)

git remote add origin https://github.com/rahimahisah17/azure-cli-lab.git

Upload the files

git push -u origin main

The latest screenshot shows a total success. I've officially "pushed" your code from your local machine to the cloud. Seeing * [new branch] main -> main is the final green light for any developer.

Writing objects: 100% (3/3) means All 3 parts of your Git snapshot (the files, the folder info, and the message) were uploaded.
branch main set up to track 'origin/main' means your computer and GitHub are now "synced." Next time you change your README, you only have to type git push, no extra settings needed.

Correction to READme

I realized, I used East US, instead of Korea Central. I must also state that I failed to create the budget and state the reason.

Step 1: Update the README.md File
This command uses a "Here-String" to overwrite your existing file with the new location (Korea Central) and the note about subscription limitations.
Run this block:
**@'

Azure CLI Cloud Lab

What I Built

A complete Azure environment using only the Azure CLI — no portal.

Resources Created

Resource Group (azurecli-lab-rg in Korea Central)
Virtual Network (10.0.0.0/16) with Subnet (10.0.1.0/24)
NSG with SSH (22) and HTTP (80) rules
Ubuntu VM (Standard_B1s) with Nginx installed
Storage Account with blob container
Key Vault with secret & managed identity

[!IMPORTANT]
Cost Budget Note: The $10 monthly budget failed to implement in this specific environment due to Azure subscription limitations (e.g., Free Tier or specific tenant restrictions).

Key Commands

az group create, az vm create, az network vnet create, az storage account create, az keyvault create

What I Learned

Regional differences: Migrated deployment to Korea Central.
API Constraints: Budgeting tools are restricted on certain subscription types.
Always delete resources after a lab to avoid charges. '@ | Set-Content -Path "README.md"**

Step 2: Update Your Resource Group Location
Since I decided to change the location to Korea Central, I ran this to update your Azure environment to match your new documentation:

az group update --name "azurecli-lab-rg" --set location="koreacentral"

Step 3: Amend and Force Push to GitHub
Since I already pushed a version of this project, I will "amend" the previous commit so your history stays clean and professional.

git add README.md

Step 4: Overwrite the last commit message

git commit --amend -m "docs: update location to Korea Central and note budget limit

Step 5: Force push to the cloud
(This is required because we are changing history that was already uploaded.)

git push origin main --force

Summary

In this part of the project, I successfully extended my Azure CLI lab by implementing storage, security, and operational workflows. I created a storage account and container, uploaded and verified files, and explored two authentication approaches: RBAC and access keys. I also set up Azure Key Vault to securely store and retrieve secrets, and configured a managed identity for secure, credential-free access.

While attempting to implement cost monitoring, I encountered Azure subscription limitations that prevented budget creation via CLI, this is an important real-world insight into how Free Trial subscriptions behave.

Overall, this phase reinforced key cloud principles of secure data handling, identity-based access, cost awareness, and environment cleanup. It also demonstrated that beyond just running commands, understanding Azure’s underlying constraints and design decisions is critical for building reliable, production-ready solutions.

Data-Driven Energy Insights: Analyzing National Fuel Markets with Power BI & DAX

Rahimah Sulayman — Mon, 16 Mar 2026 17:35:13 +0000

Introduction

Why Fuel Market Data Matters
In a global economy, understanding energy consumption and fuel distribution is more than just looking at numbers, it’s about identifying economic patterns and infrastructure needs. I recently completed a deep-dive analysis into the National Fuel Market in Argentina, transforming raw datasets into an interactive, actionable intelligence report.

This project wasn't just about visualization, it was about building a robust data model that could handle complex regional variables and provide clear insights for stakeholders.

The Technical Challenge

From Raw Data to Insights
Every data project starts with a hurdle. For this analysis, the focus was on ensuring data integrity across various provinces and fuel types.

1.Data Architecture & Modeling

I implemented a Star Schema to ensure the report remained performant despite the dataset's size. By separating fact tables (sales and prices) from dimension tables (geography, time, and fuel categories), I ensured that the report remains scalable for future data updates.

2.Advanced Analytics with DAX
To go beyond basic arithmetic, I utilized DAX (Data Analysis Expressions) to create dynamic measures. These allowed for:

Year-over-Year (YoY) Growth: Tracking how consumption shifted across different quarters.
Regional Market Share: Identifying which provinces dominated specific fuel categories.
Price Volatility Tracking: Visualizing how price fluctuations impacted sales volume.

3.I customized a wireframe using Powerpoint.
Into the wireframe, I inserted my shapes and resized and added fill colors of my choice. I imported the icons from Flaticons.

4.I used a high-end UI/UX design
This demonstrated the effective use buttons and bookmarks to enhance interactivity.

Key Insights Discovered

The data revealed several compelling trends that would be vital for any policy-maker or private stakeholder.

Regional Concentration: Highlighting specific hubs where infrastructure investment would yield the highest ROI.

Consumption Shifts: Identifying the transition points between traditional fuels and emerging alternatives.

Market Resilience: How various regions reacted to pricing shifts over the analyzed period.

The Interactive Experience

Static reports only tell half the story. To truly explore the data, I’ve published the full interactive version of the dashboard.

View the Interactive Report on NovyPro

Explore the Full Technical Repository on GitHub

Conclusion

Turning Data into Strategy
As a Data Analyst, my goal is always to bridge the gap between technical complexity and business strategy. This project reinforced the importance of clean modeling and the power of interactive storytelling in data.

Creating Azure Resources via Azure CLI: Part 2

Rahimah Sulayman — Thu, 12 Mar 2026 15:52:12 +0000

Introduction

Adaptability is the core of DevOps. After navigating subscription-level constraints in our previous VM setup, it became clear that understanding 'where' and 'how' you deploy is just as vital as the 'what.'
In this second part of our Azure CLI series, we apply those hard-won lessons to build a faster, more agile deployment workflow. From optimizing locations to selecting the right VM sizes on the fly, this guide provides a professional blueprint for mastering Azure resources through the command line.

Here, I skipped Install Azure CLI and headed straight to verification.

Step 1: Verify the installation.
To verify the installation, run the Azure CLI command: az --version command.

This gives details of the Azure version in use.

Step 2: Login

Run the Azure command az login. This opens a browser for interactive authentication and sets your active Azure subscription context.

Notice I selected my account and then Continue.

Note I did not have to sign in because the account was set in the previous exercise, using the az account set command.

Step 3: To confirm my active subscription, I entered 1, because it is the only active subscription I have. If you have more than one subscription, enter the number that corresponds to the subscription you intend to use.

We can go ahead and provision the Resource Group now.

Create a Resource Group

In this section, we aim to create a resource group to act as the logical container for the entire lab environment.

Step 1: Set a variable for the resource group.
Store the resource group name and region in powershell variables. This is highly recommended to prevent typos throughout the rest of the lab and make the script easily reusable.

RG="azurecli-lab-rg"
This sets the shell variable RG so later commands can reference it with $RG.

LOCATION="koreacentral"
This sets the shell variable LOCATION so later commands can reference it with $LOCATION.

Step 2: Create the Resource Group
Create a named resource group in korea central this time around. All resources in this lab will be placed here for easy cleanup.

This is needed because Azure requires every resource to live inside a resource group. They make it easy to manage, monitor, and delete everything together at the end of the lab.

Operational Excellence — grouping related resources together is a best practice for manageability and cost tracking.
Run the command: az group create --name $RG --location $LOCATION.
This creates a resource group called "$RG" — a logical container for all the Azure resources in this lab.

Clearly, it was created because the properties are stated and Notice the ProvisioningState reads "Succeeded".

Build a Virtual Network (VNet) & Subnet

This is aimed at creating a secure private network for your Azure resources to communicate on.

Step 1: Create the Virtual Network
Here, you will create a Virtual Network with a broad 10.0.0.0/16 IP address space.

This is necessary because VMs and other infrastructure need a secure, isolated private network to communicate with each other.
Creating an isolated network boundary is the foundational step of cloud security.
Run the command: az network vnet create --address-prefix 10.0.0.0/16 --resource-group $RG --name lab-vnet --location $LOCATION

It took just 4 seconds for this virtual network to provision. That's amazing!

Step 2: Create a Subnet
This would carve out a smaller 10.0.1.0/24 piece (subnet) of the VNet specifically for your VMs.

Why this is relevant
Segmenting networks allows you to apply different routing and firewall rules to different types of resources.

This aspect of security is known as network segmentation.
Run the CLI command: az network vnet subnet create --resource-group $RG --vnet-name lab-vnet --name lab-subnet --address-prefix 10.0.1.0/24

Step 3: Create a Network Security Group (NSG)
A Network Security Group acts as a virtual firewall.

This is important because without an NSG attached, Microsoft allows no inbound traffic but allows all outbound traffic. We need an NSG to poke specific holes in the firewall.

Controlling traffic flow with firewalls is a basic security requirement.
Run the command: az network nsg create --resource-group $RG --name lab-nsg

Step 4: Open port 22 (SSH) & 80 (HTTP)
Let's add inbound rules prioritizing SSH (port 22) and HTTP (port 80) access from the internet.
The reason for this action is that you'll need SSH to log in and configure the server, and HTTP so users can view the web page.

This explicitly defining inbound access using the principle of least privilege.
First ensure your terminal knows what $RG is by running this line first: $RG="azurecli-lab-rg"
Then create the SSH rule using this command:
az network nsg rule create --resource-group $RG
--nsg-name lab-nsg --name AllowSSH
--priority 1000 --destination-port-ranges 22
--access Allow --protocol Tcp
--direction Inbound
Wait for the first command to finish.

Then create the HTTP Rule by running this separate block:
az network nsg rule create --resource-group $RG
--nsg-name lab-nsg --name AllowHTTP
--priority 1010 --destination-port-ranges 80
--access Allow --protocol Tcp
--direction Inbound
Notice (`)serves as a line breaker because the command is long. Leave one space before the "backtick" and then enter.

Step 5:Attach NSG to Subnet
This enforces the firewall rules (NSG) at the subnet boundary.

It's needed because by applying the NSG to the subnet ensures that any VM created in that subnet automatically inherits those exact firewall rules, thereby protecting the entire subnet.

Security — subnet-level application of security controls.
Run this block of commands:
az network vnet subnet update --resource-group $RG
--vnet-name lab-vnet --name lab-subnet
--network-security-group lab-nsg
Remember to run the resource group variable first if you restart the terminal.

Provision a Linux Virtual Machine

Here, you will create an Ubuntu VM with a public IP inside your VNet.

Step 1: Allocate a Public IP
This allocates a static public IP address in Azure.

It's needed because without a public IP, the VM can only be accessed internally through the VNet or a VPN. You need this to reach your web server from your browser.

Reliability — using a Static IP ensures the address does not change upon reboot.
Run this command:
az network public-ip create --resource-group $RG
--name lab-public-ip --allocation-method Static
--sku Basic

Notice due to error, I had to switch to "standard". Pay attention to error messages.

Step 2: Create the VM
This creates a B1s Ubuntu VM with auto-generated SSH keys and connects it to the existing subnet and firewall.

It's necessary because this is the actual cloud compute instance that will run your web application code.

Performance Efficiency — selecting the appropriately sized VM for your workload (B1s for dev/test).
Run this command: az vm create --resource-group azurecli-lab-rg
--name lab-vm --image Ubuntu2204
--size Standard_B2s_v2 --location koreacentral
--admin-username azureuser --generate-ssh-keys
--vnet-name lab-vnet --subnet lab-subnet
--public-ip-address lab-public-ip
--nsg lab-nsg

Notice this time around, I did not have to change anything because am now aware of the limitations that come with the subscription and the Powerstate reads running.

Step 3: Retrieve the public IP
This will filter the Azure API response to return just the IP address string.

It's important because you'll need this IP to SSH into the machine and to test the web application.

Operational Excellence — automated retrieval of resource attributes avoids manual portal lookups.
Run the command: az network public-ip show --resource-group azurecli-lab-rg
--name lab-public-ip --query ipAddress
--output tsv

Notice the error occurred because I mistakenly omitted the "-rg" suffix.

Step 4: Verify the VM is running
This queries the VM status and displays it in a clean table format.

It's needed because you always verify provisioning success before attempting connections.

Operational Excellence — verification and monitoring.
Run the command: az vm show --resource-group azurecli-lab-rg
--name lab-vm --show-details
--query '{Name:name, State:powerState, IP:publicIps}'
--output table

Step 5:SSH into your VM & install Nginx

It logs into the VM over the internet via SSH, installs the Nginx package using APT, and starts the service.

Why It's Needed
A fresh VM is blank. Nginx serves as the web server to test our HTTP port 80 firewall rule.

Pillar Connection
Operational Excellence — bootstrap scripts or userdata are typically used to automate this step.

You can go ahead to verify the resources' provision in your Azure Portal. This will help you appreciate resource creation via the Azure CLI. It's very fast and efficient.

Conclusion: Your Turn to Command the Cloud

Stepping out of the comfort zone of the Azure Portal and into the CLI is more than just a technical shift, it’s a mindset shift. By following this guide, you’ve moved from being a "user" of the cloud to someone who truly "architects" it.

Don't be discouraged if you hit errors along the way. Every "SkuNotAvailable" or "InvalidParameter" is just a signal that you're learning how the machine actually thinks. The more you practice, the more these commands will feel like a second language.

I’d love to hear from you! Let's go to the comment section👇👇

Microsoft Azure Management Tasks: Manage Tags and Locks

Rahimah Sulayman — Thu, 12 Mar 2026 10:57:23 +0000

Overview

In a fast-paced cloud environment, visibility and protection are the difference between seamless operations and costly downtime. As a cloud-focused professional, I understand that managing resources isn't just about deployment,it's about governance.
This project demonstrates my ability to implement Azure Resource Governance by applying strategic metadata via tags for cost center tracking and enforcing Resource Locks to prevent accidental deletions of mission-critical infrastructure.

If you’ve completed the previous exercises(in the Microsoft Azure Management Tasks), you’ve managed added a subnet to a virtual network, made changes to a virtual machine, and worked with an Azure storage account. The final set of tasks for this guided project focus around working with tags and resource locks to help manage and monitor your environment. During this exercise you’ll go back into each of the areas you’ve already worked to add tags, locks, or a combination of both.

This exercise should take approximately 5 minutes to complete.

Scenario

Pleased with your progress so far, the Azure admin hopes that you can wrap a few things up to help with monitoring and protecting resources. They want to know that someone can’t accidentally get rid of the virtual machine that’s running as an FTP server, and they want a quick way to see what department is using resources and the resource’s purpose.

Manage tags and locks on VMs

Adding tags to resources is a quick way to be able to group and organize resources. Tags can be added at different levels, giving you the ability to organize and group resources at a level that makes sense for you.

Add tags to a virtual machine

You’ll start by adding a pair of tags to the virtual machine. One tag will be to identify the purpose of the virtual machine and the other will be to indicate the department the machine supports.

1.Login to Microsoft Azure at https://portal.azure.com
2.From the Azure portal home page, in the search box, enter virtual machines.
3.Select virtual machines under services.
4.Select the guided-project-vm virtual machine.
5.From the menu pane, select Tags.

6.On one line for Name enter Department and for Value enter Customer Service
7.On the next line, for Name enter Purpose and for Value enter FTP Server.
8.Select Apply.

While you’re working on the virtual machine, it’s a great time to add a resource lock.

Add a resource lock to a VM

1.If necessary, expand the Settings submenu.
2.Select Locks.

3.Select + Add.
4.For the name, enter VM-delete-lock.
5.For the Lock type, select Delete.
6.You may enter a note to help remind you why you created the lock.
7.Select OK.

That’s it. Now the VM is protected from deletion and has tags assigned to help track use. Time to move onto the network.

1.Select Home to return to the Azure portal home page.

Add tags to network resources

1.From the Azure portal home page, in the search box, enter virtual networks.
2.Select virtual networks under services.
3.Select the guided-project-vnet network.
4.From the menu pane, select Tags.
Note: Notice that now you can select an existing tag to apply or add a new tag. You can also select just the name or value and apply create something new in the other field.

5.For the Name select Department.
6.For the Value enter IT.
7.Select Apply.

Now both the VNet and VM have been organized.

Congratulations! You’ve completed this exercise. .

Conclusion

By successfully implementing tags and resource locks, I have ensured that the environment is not only organized for departmental billing and monitoring but also hardened against human error.
These foundational governance tasks are essential for maintaining a secure, scalable, and professional Azure footprint.

Microsoft Azure Management Tasks: Control storage access

Rahimah Sulayman — Thu, 12 Mar 2026 10:43:14 +0000

Overview

In modern cloud environments, storing files is only part of the job, controlling who can access them and how they are accessed is just as critical. Organizations rely heavily on secure and scalable storage solutions to share data across teams, applications, and services.
In Microsoft Azure, storage accounts, containers, and file shares provide powerful ways to manage data while maintaining strict control over access.
In this exercise, you’ll explore how to create storage containers and file shares, upload files, manage access tiers, and securely control access using shared access signatures.In this exercise, you’ll complete several tasks related to managing a storage account and components of the storage account.

This exercise should take approximately 12 minutes to complete.

Scenario

The Azure admin wants you to get more familiar with storage accounts, containers, and file shares. They anticipate needing to share an increasing number of files and need someone who is skilled using these services. They’ve given you a task of creating a storage container and a file share and uploading files to both locations.

Create a storage container

1.Login to Microsoft Azure at https://portal.azure.com
2.From the Azure portal home page, in the search box, enter storage accounts.
3.Select storage accounts under services.
4.Select the storage account you created in the Prepare exercise. The storage account name is the hyperlink to the storage account. (Note: it should be associated with the resource group guided-project-rg).

5.On the storage account blade, under the Data storage submenu, select Containers.
6.Select + Add container.

7.In the Name field, enter storage-container.
8.Select Create.

Great! With a storage container created, you can upload a blob to the container. Locate a picture that you can upload, either on your computer or from the internet, and save it locally to make uploading easier.

Upload a file to the storage container

1.Select the storage container you just created.

2.Select Upload and upload the file you prepared.

3.Once the file is ready for upload, select Upload.

With the file uploaded, notice that the Access tier is displayed. For something we uploaded just for testing, it doesn’t need to be assigned to the Hot access tier. In the next few steps, you’ll change the access tier for the file.

Change the access tier

1.Select the file you just uploaded (the file name is a hyperlink).
2.Select Change tier. Screenshot of menu for a blob storage item with Change tier highlighted.

3.Select Cold.
4.Select Save.

Note: You just changed the access tier for an individual blob or file. To change the default access tier for all blobs within the storage account, you could change it at the storage account level.

5.Select Home to return to the Azure portal home page.

Good job! You’ve successfully uploaded a storage blob and changed the access tier from Hot to Cold. Next, you’ll work with file shares.

Create a file share

1.From the Azure portal home page, in the search box, enter storage accounts.
2.Select storage accounts under services.
3.Select the storage account you created in the Prepare exercise. The storage account name is the hyperlink to the storage account. (Note: it should be associated with the resource group guided-project-rg.)
4.On the storage account blade, under the Data storage submenu, select File shares.
5.Select + File share.
6.On the Basics tab, in the name field enter file-share.
7.On the Backup tab, uncheck Enable backup.

8.Select Review + create.
9.Select Create.
10.Once the file share is created, select Upload.
11.Upload the same file you uploaded to the blob storage or a different file, it’s up to you.

12.Select Home to return to the Azure portal home page.

The next piece of the puzzle is figuring one way to control access to the files that have been uploaded. Azure has many ways to control files, including things like role-based access control. In this scenario, the Azure admin wants you to use shared access tokens or keys.

Create a shared access signature token

Note: Blob container is another name for the storage containers. Items uploaded to a storage container are called blobs.

6.Select the storage container you created earlier, storage-container.

7.Select the ellipses (three dots) on the end of the line for the image you uploaded.

8.Select Generate SAS.

Note: When you generate a shared access signature, you set the duration. Once the duration is over, the link stops working. The Start automatically populates with the current date and time.

9.Set Signing method to Account key.
10.Set Signing key to Key 1.

Tip: There are two signing keys available. You can choose either one, or create SAS tokens with different durations.

11.Set Stored access policy to None.
12.Set Permissions to Read.
13.Enter a custom start and expiry time or leave the defaults.

14.Set Allowed protocols to HTTPS only.
15.Select Generate SAS token and URL.
16.Copy the Blob SAS URL and paste it in another window or tab of your browser. It should display the image you uploaded. Keep this tab or window open.

Tip: You can configure SAS tokens for files shares and blob containers using the same process.

17.Select Home to return to the Azure portal home page.

With the SAS token created, anyone with that link can access the file for the duration that was set when you created the SAS token. However, controlling access to a resource or file is about more than just granting access. It’s also about being able to revoke access. To revoke access with a SAS token, you need to invalidate the token. You invalidate the token by rotating the key that was used.

Rotate access keys

6.For Key 1, select Rotate key.
7.Read and then acknowledge the warning about regenerating the access key by selecting Yes.

8.Once you see the success message for rotating the access key, go back to the window or tab you used to check the SAS token and refresh the page. You should receive an authentication failed error.

Congratulations! You’ve completed this exercise. Return to Microsoft Learn to continue the guided project.

Key Takeaway

By creating a storage container, uploading files, configuring file shares, and generating shared access signature tokens, you’ve learned how to manage and secure storage resources in Microsoft Azure. You also explored how to revoke access by rotating access keys—an essential security practice. These hands-on tasks highlight the importance of balancing accessibility with strong access control when managing cloud-based storage systems.