Forem: Rahimah Sulayman

Create DNS zones and configure DNS settings

Rahimah Sulayman — Tue, 26 May 2026 13:12:28 +0000

Introduction

Reliable name resolution is a critical part of modern cloud infrastructure, especially in secure, private network environments. In this hands-on guide, we’ll configure Azure Private DNS to enable seamless internal communication using custom domain names instead of IP addresses. The exercise covers creating a private DNS zone, linking it to a virtual network, and configuring DNS records for backend resources: demonstrating practical Azure networking and cloud administration skills used in real-world enterprise environments.

Scenario

Your organization requires workloads to use domain names instead of IP addresses for internal communications. The organization doesn’t want to add a custom DNS solution. You identify these requirements.

A private DNS zone is required for contoso.com.
The DNS will use a virtual network link to app-vnet.
A new DNS record is required for the backend subnet.

Skilling tasks

Create and configure a private DNS zone.
Create and configure DNS records.
Configure DNS settings on a virtual network.

Exercise instructions

Note: This exercise requires the Lab 01 virtual networks and subnets to be installed. A template is provided if you need to deploy those resources.
Create a private DNS zone

Azure Private DNS provides a reliable, secure DNS service to manage and resolve domain names in a virtual network without the need to add a custom DNS solution. By using private DNS zones, you can use your own custom domain names rather than the Azure-provided names.

1.On the Azure portal, search for and select Private dns zones.

2.Select + Create and configure the DNS zone.

Property	Value
Subscription	Select your subscription
Resource group	RG1
Name	`private.contoso.com`
Region	East US

3.Select Review + create and then select Create.

4.Wait for the DNS zone to deploy, and then select Go to resource.

Create a virtual network link to your private DNS zone

To resolve DNS records in a private DNS zone, resources must be linked to the private zone. A virtual network link associates the virtual network to the private zone.

1.In the portal, continue working on the private.contoso.com DNS zone.

2.In the DNS Management blade, select + Virtual network links.

3.Select + Add and configure the virtual network link.

Property	Value
Link name	`app-vnet-link`
Virtual network	app-vnet
Enable auto registration	Enabled

4.Select Create and wait for the deployment to finish. If necessary, Refresh the page.

Create a DNS record set

DNS records provide information about the DNS zone.

1.In the portal, continue working on the private.contoso.com DNS zone.

2.In the DNS Management blade, select + Recordsets.

3.Notice that two A records have automatically been created for each of the virtual machines.

4.Select + Add and configure a record set. When finished select Add.

Property	Value
Name	`backend`
Type	A
TTL	1
IP address	10.1.1.5

Note: This record set implies there is a virtual machine in app-vnet with a private IP address of 10.1.1.5.

Key takeaways
Here are the main takeaways:

Azure DNS is a cloud service that allows you to host and manage domain name system (DNS) domains, also known as DNS zones.
Azure DNS public zones host domain name zone data for records that you intend to be resolved by any host on the internet.
Azure Private DNS zones allow you to configure a private DNS zone namespace for private Azure resources.
A DNS zone is a collection of DNS records. DNS records provide information about the domain.

Summary

In this exercise, we configured Azure Private DNS to enable secure and reliable internal name resolution within a virtual network. We created a private DNS zone for private.contoso.com, linked it to the app-vnet virtual network, and configured DNS record sets for backend resources. This setup demonstrates how Azure Private DNS simplifies internal communication by allowing workloads to use custom domain names instead of IP addresses, while maintaining centralized and secure DNS management in Azure.

Configure network routing

Rahimah Sulayman — Tue, 26 May 2026 12:00:41 +0000

Introduction

In modern cloud environments, controlling how network traffic flows is just as important as securing the workloads themselves. In this guide, we’ll configure custom network routing in Azure by creating route tables, associating them with subnets, and directing outbound traffic through an Azure Firewall for centralized inspection and filtering. This hands-on exercise demonstrates practical cloud networking and security skills that are essential for designing secure, enterprise-grade Azure infrastructures.

Scenario

To ensure the firewall policies are enforced, outbound application traffic must be routed through the firewall. You identify these requirements.

A route table is required. This route table will be associated with the frontend and backend subnets.
A route is required to filter all outbound IP traffic from the subnets to the firewall. The firewall’s private IP address will be used.

Skilling tasks

Create and configure a route table.
Link a route table to a subnet.

Exercise instructions

Create a route table

Azure automatically creates a route table for each subnet within an Azure virtual network. The route table includes the default system routes. You can create route tables and routes to override Azure’s default system routes.

Record the private IP address of app-vnet-firewall

1.In the search box at the top of the portal, enter Firewall. Select Firewall in the search results.

2.Select app-vnet-firewall.

3.Select Overview and record the Private IP address.

Add the route table

1.In the search box, enter Route tables. When Route table appears in the search results, select it.

2.In the Route table page, select + Create and create the route table.

Property	Value
Subscription	Select your subscription
Resource group	RG1
Region	East US
Name	`app-vnet-firewall-rt`

3.Select Review + create and then select Create.

4.Wait for the route table to deploy, then select Go to resource.

Associate the route table to the subnets

1.In the portal, continue working with the route table, select app-vnet-firewall-rt.

2.In the Settings blade, select Subnets and then + Associate.

3.Configure an association to the frontend subnet, then select OK.

Property	Value
Virtual network	app-vnet (RG1)
Subnet	frontend

4.Configure an association to the backend subnet, then select OK.

Property	Value
Virtual network	app-vnet (RG1)
Subnet	backend

Create a route in the route table

1.In the portal, continue working with the route table, select app-vnet-firewall-rt.

2.In the Settings blade, select Routes and then + Add.

3.Configure the route, then select Add.

Property	Value
Route name	outbound-firewall
Destination type	IP addresses
Destination IP addresses/CIDR range	0.0.0.0/0
Next hop type	Virtual appliance
Next hop address	private IP address of the firewall

Key takeaways

Here are the main takeaways:

Network traffic in Azure is automatically routed across Azure subnets, virtual networks, and on-premises networks. System routes control this routing.
User-defined routes override the default system routes so traffic can be routed through a network virtual appliances (NVAs).
Network virtual appliances (NVAs) control the flow of network traffic. Examples of NVAs are firewalls, load balancers, and routers.
Route tables contain routing information and are associated with a subnet.

Summary

In this exercise, we configured Azure network routing to ensure outbound traffic is securely inspected through an Azure Firewall. We created a custom route table, associated it with the frontend and backend subnets, and added a user-defined route that forwards all outbound traffic to the firewall’s private IP address. This setup demonstrates how Azure route tables and network virtual appliances work together to provide centralized traffic control, improved security, and enterprise-grade network management.

Create and configure Azure Firewall

Rahimah Sulayman — Mon, 25 May 2026 21:21:10 +0000

Introduction

As cloud applications scale, simple subnet-level filtering isn't enough to defend against sophisticated attack vectors. This project demonstrates how to implement a centralized network security strategy in Microsoft Azure by deploying Azure Firewall to protect corporate workloads (app-vnet). Moving beyond basic port restrictions, this guide covers how to design and enforce Firewall Policies,including Layer 7 Application Rules to securely lock down egress traffic to Azure DevOps pipelines (dev.azure.com) and Network Rules to safeguard core infrastructure traffic like DNS resolution.

Scenario

Your organization requires centralized network security for the application virtual network. As the application usage increases, more granular application-level filtering and advanced threat protection will be needed. Also, it is expected the application will need continuous updates from Azure DevOps pipelines. You identify these requirements.

Azure Firewall is required for additional security in the app-vnet.
A firewall policy should be configured to help manage access to the application.
A firewall policy application rule is required. This rule will allow the application access to Azure DevOps so the application code can be updated.
A firewall policy network rule is required. This rule will allow DNS resolution.

Skilling tasks

Create an Azure Firewall.
Create and configure a firewall policy
Create an application rule collection.
Create a network rule collection.

Create Azure Firewall subnet in our existing virtual network

1.In the search box at the top of the portal, enter Virtual networks. Select Virtual networks in the search results.

2.Select app-vnet.

3.Select Subnets.

4.Select + Subnet.

5.Enter the following information and select Add.

Property	Value
Name	AzureFirewallSubnet
Address range	10.1.63.0/26

Note: Leave all other settings as default.

Create an Azure Firewall

1.In the search box at the top of the portal, enter Firewall. Select Firewall in the search results.

2.Select + Create.

3.Create a firewall by using the values in the following table. For any property that is not specified, use the default value.

Note: Azure Firewall can take a few minutes to deploy.

Property	Value
Resource group	RG1
Name	app-vnet-firewall
Firewall SKU	Standard
Firewall management	Use a Firewall Policy to manage this firewall
Firewall policy	select Add new
Policy name	fw-policy
Region	East US
Policy Tier	Standard
Choose a virtual network	Use existing
Virtual network	app-vnet (RG1)
Public IP address	Add new: fwpip
Enable Firewall Management NIC	uncheck the box

4.Select Review + create and then select Create.

Update the Firewall Policy

1.In the portal, search for and select Firewall Policies.

2.Select fw-policy.

Add an application rule

1.In the Rules blade, select Application rules and then Add a rule collection.

2.Configure the application rule collection and then select Add.

Property	Value
Name	`app-vnet-fw-rule-collection`
Rule collection type	Application
Priority	`200`
Rule collection action	Allow
Rule collection group	DefaultApplicationRuleCollectionGroup
Name	`AllowAzurePipelines`
Source type	IP address
Source	`10.1.0.0/23`
Protocol	`https`
Destination type	FQDN
Destination	`dev.azure.com, azure.microsoft.com`

Note: The AllowAzurePipelines rule allows the web application to access Azure Pipelines. The rule allows the web application to access the Azure DevOps service and the Azure website.

Add a network rule

1.In the Rules blade, select Network rules and then Add a rule collection.

2.Configure the network rule and then select Add.

Property	Value
Name	`app-vnet-fw-nrc-dns`
Rule collection type	Network
Priority	`200`
Rule collection action	Allow
Rule collection group	DefaultNetworkRuleCollectionGroup
Rule	AllowDns
Source	`10.1.0.0/23`
Protocol	UDP
Destination ports	`53`
Destination addresses	1.1.1.1, 1.0.0.1

Verify the firewall and firewall policy status

1.In the portal search for and select Firewall.

2.View the app-vnet-firewall and ensure the Provisioning state is Succeeded. This may take a few minutes.

3.In the portal serach for and select Firewall policies.

4.View the fw-policy and ensure the Provisioning state is Succeeded. This may take a few minutes.

Summary

This project demonstrates the implementation of a centralized network security perimeter within Microsoft Azure using Azure Firewall and Firewall Policies. By shifting from decentralized security rules to a unified firewall model, this architecture enforces granular Layer 4 (network) and Layer 7 (application) filtering to protect cloud workloads from malicious egress traffic while enabling secure CI/CD automation.

Create and configure network security groups

Rahimah Sulayman — Mon, 25 May 2026 15:25:22 +0000

Introduction

Want to ensure your web infrastructure is tightly controlled and protected against unauthorized traffic? In this hands-on lab breakdown, I dive into securing a multi-tier architecture in Microsoft Azure. From configuring Network Security Groups (NSGs) for backend subnets to leveraging Application Security Groups (ASGs) to abstract network configurations for Ubuntu web servers, this walkthrough covers the exact skilling tasks required to manage enterprise-grade network filtering policies cleanly.

Scenario

Your organization requires the network traffic in the app-vnet to be tightly controlled. You identify these requirements.

The frontend subnet has web servers that can be accessed from the internet. An application security group (ASG) is required for those servers. The ASG should be associated with any virtual machine interface that is part of the group. This will allow the web servers to be easily managed.
The backend subnet has database servers used by the frontend web servers. A network security group (NSG) is required to control this traffic. The NSG should be associated with any virtual machine interface that will be accessed by the web servers.
For testing, a virtual machine should be installed in the frontend subnet (VM1) and the backend subnet (VM2). The IT group has provided an Azure resource manager template to deploy these Ubuntu servers.

Skilling tasks

Create a network security group.
Create network security group rules.
Associate a network security group to a subnet.
Create and use application security groups in network security group rules.

Create the network infrastructure for the exercise

Note: This exercise requires the Create and Configure Virtual Networks Exercise's virtual networks and subnets to be installed.
A template is provided if you need to deploy those resources.

1.Use the icon (top right) to launch a Cloud Shell session. Alternately, navigate directly to https://shell.azure.com.

2.If prompted to select either Bash or PowerShell, select PowerShell.

3.Storage is not required for this task Select your subscription. Apply your changes.

4.Use these commands to deploy the virtual machines required for this exercise.

Note: If the deployment fails for capacity restriction, edit the template and change the “location” value.

Copy:

$RGName = "RG1"

New-AzResourceGroupDeployment -ResourceGroupName $RGName -TemplateUri https://raw.githubusercontent.com/MicrosoftLearning/Configure-secure-access-to-workloads-with-Azure-virtual-networking-services/main/Instructions/Labs/azuredeploy.json

NOTE: It failed and I had to edit the Template. I also did not use TemplateUri because I now have the file to my local environment.

1.In the portal search for and select virtual machines. Verify both vm1 and vm2 are Running.

Create Application Security Group

Application security groups (ASGs) let you group together servers with similar functions. For example, all the web servers hosting your application.

1.In the portal, search for and select Application security groups.

2.Select + Create and configure the application security group.

Property	Value
Subscription	Select your subscription
Resource group	RG1
Name	`app-frontend-asg`
Region	East US

3.Select Review + create and then select Create.

Note: You are creating the application security group in the same region as the existing virtual network.

Associate the application security group to the network interface of the VM

1.In the Azure portal, search for and select VM1.

2.In the Networking blade, select Application security groups and then select Add application security groups.

3.Select the app-frontend-asg and then select Add.

Create and Associate the Network Security Group

Network security groups (NSGs) secure network traffic in a virtual network.

1.In the portal search for and select Network security group.

2.Select + Create and configure the network security group.

Property	Value
Subscription	Select your subscription
Resource group	RG1
Name	`app-vnet-nsg`
Region	East US

3.Select Review + create and then select Create.

Associate the NSG with the app-vnet backend subnet.

NSGs can be associated with subnets and/or individual network interfaces attached to Azure virtual machines.

1.Select Go to resource or navigate to the app-vnet-nsg resource.

2.In the Settings blade select Subnets.

3.Select + Associate

4.Select app-vnet (RG1) and then the Backend subnet. Select OK.

Create Network Security Group rules

An NSG use security rules to filter inbound and outbound network traffic.

1.In the search box at the top of the portal, enter Network security groups. Select Network security groups in the search results.

2.Select app-vnet-nsg from the list of network security groups.

3.In the Settings blade, select Inbound security rules.

4.Select + Add and configure an inbound security rule.

Property	Value
Source	Any
Source port ranges	***
Destination	Application Security group
Destination application security group	app-frontend-asg
Service	SSH
Action	Allow
Priority	100
Name	AllowSSH

Key takeaways
Here are the main takeaways:

Application security groups let you organize virtual machines and define network security policies based on your organization’s applications.
An Azure network security group is used to filter network traffic between Azure resources in an Azure virtual network.
You can associate zero, or one, network security group to each virtual network subnet and network interface in a virtual machine.
A network security group contains security rules that allow or deny inbound network traffic to, or outbound network traffic from, Azure resources.
You join virtual machines to an application security group. Then you use the application security group as a source or destination in the network security group rules.

Conclusion

This technical project demonstrates how to implement a Zero-Trust network architecture within Microsoft Azure to secure a multi-tier application. By decoupling network security rules from IP addresses and subnets, the design ensures that communication between frontend web servers and backend database workloads is tightly controlled, audited, and scalable.

Create and configure virtual networks

Rahimah Sulayman — Mon, 25 May 2026 11:17:19 +0000

Introduction

Imagine migrating a critical enterprise web application to the cloud, only to face network bottlenecks, unsegmented traffic, or exposure to the public internet. Designing a resilient, production-ready cloud environment always begins at the foundational layer: secure, scalable networking.

In this article, I demonstrate how to architect a modern cloud infrastructure blueprint using a Hub-and-Spoke topology in Microsoft Azure. This structural design isolates workloads, enforces security boundaries, and minimizes latency.

As a cloud professional, my focus isn't just on clicking buttons in the portal,it is on delivering architectural patterns that protect data, optimize costs, and align with the Azure Well-Architected Framework.

Scenario
Your organization is migrating a web-based application to Azure. Your first task is to put in place the virtual networks and subnets. You also need to securely peer the virtual networks. You identify these requirements.

Two virtual networks are required, app-vnet and hub-vnet. This simulates a hub and spoke network architecture.
The app-vnet will host the application. This virtual network requires two subnets. The frontend subnet will host the web servers. The backend subnet will host the database servers.
The hub-vnet only requires a subnet for the firewall.
The two virtual networks must be able to communicate with each other securely and privately through virtual network peering.
Both virtual networks should be in the same region.

Skilling tasks

Create a virtual network.
Create a subnet.
Configure vnet peering.

Note: To complete this lab you will need an Azure subscription with Contributor RBAC role assigned. In this lab, when you are asked to create a resource, for any properties that are not specified, use the default value.

Create hub and spoke virtual networks and subnets

An Azure virtual network enables many types of Azure resources to securely communicate with each other, the internet, and on-premises networks. All Azure resources in a virtual network are deployed into subnets within the virtual network.

1.Sign in to the Azure portal - https://portal.azure.com.

2.Search for and select Virtual Networks.

3.Select + Create and complete the configuration of the app-vnet.

This virtual network requires two subnets, frontend and backend.

Property	Value
Resource group	RG1
Virtual network name	`app-vnet`
Region	East US
IPv4 address space	10.1.0.0/16
Subnet name	`frontend`
Subnet address range	10.1.0.0/24
Subnet name	`backend`
Subnet address range	10.1.1.0/24

Note:Leave all other settings as their defaults.

When finished select Review + create and then Create.

4.Create the Hub-vnet virtual network configuration. This virtual network has the firewall subnet.

Property	Value
Resource group	RG1
Name	`hub-vnet`
Region	East US
IPv4 address space	10.0.0.0/16
Subnet name	AzureFirewallSubnet
Subnet address range	10.0.0.0/26

5.Once the deployments are complete, search for and select your ‘virtual networks`.

6.Verify your virtual networks and subnets were deployed.

Configure a peer relationship between the virtual networks

Virtual network peering enables you to seamlessly connect two or more Virtual Networks in Azure.

1.Search for and select the app-vnet virtual network.

2.In the Settings blade, select Peerings.

3.+ Add a peering between the two virtual networks.

Property	Value
Remote peering link name	`app-vnet-to-hub`
Virtual network	`hub-vnet`
Local virtual network peering link name	`hub-to-app-vnet`

Note: Leave all other settings as their defaults. Select “Add” to create the virtual network peering.

4.Once the deployment completes, verify the Peering status is Connected.

Key takeaways

Here are the main takeaways:

Azure virtual networks (VNets) provide a secure and isolated network environment for your cloud resources. You can create multiple virtual networks per region per subscription.
When designing virtual networks make sure the VNet address space (CIDR block) doesn’t overlap with your organization’s other network ranges.
A subnet is a range of IP addresses in the VNet. You can segment VNets into different size subnets, creating as many subnets as you require for organization and security within the subscription limit. Each subnet must have a unique address range.
Certain Azure services, such as Azure Firewall, require their own subnet.
Virtual network peering enables you to seamlessly connect two Azure virtual networks. The virtual networks appear as one for connectivity purposes.

Summary

This project isn't just about spinning up resources, it is a demonstration of secure, production-grade cloud architecture. By implementing this Hub-and-Spoke topology, I have successfully:

1.Enforced Strict Network Isolation: Segmented the application layer into dedicated frontend and backend subnets to implement a defense-in-depth security model.

2.Designed for Enterprise Scale: Established a central hub-vnet to allow seamless, future integration of centralized security appliances like Azure Firewall.

3.Optimized Performance & Security: Leveraged VNet Peering to ensure high-bandwidth, low-latency communication that remains entirely off the public internet.

I designed this infrastructure with a Zero-Trust mindset, ensuring that every deployment is scalable, compliant, and structurally aligned with enterprise security standards.

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.