I realized I needed a reset. I stopped writing code for the timeline and started writing it for myself.

Before diving into AWS and Cloud Security, I knew I needed to establish a rock-solid foundation. You cannot secure a cloud environment if you don't understand the underlying operating system and networking primitives. This is the breakdown of my "Level 0" phase: building a systems substrate with Networking, Linux, and Python.

1. Networking Primitives

Networking concepts initially felt straightforward, but memorizing port numbers and protocols required some repetition. The biggest takeaway was understanding how strictly the OSI model dictates traffic.

Every layer has a highly specific role. For instance, at Layer 4 (Transport), knowing exactly how TCP operates and understanding that protocols bind to specific ports—like HTTP on port 80 or HTTPS on port 443—is critical baseline knowledge for any security architecture.

2. The Linux CLI Shift

As a lifelong Windows user, transitioning to Linux was a shock to the system. I was used to navigating with a mouse; suddenly, I had to do everything via the command line.

I spent this phase mastering core commands (cd, pwd, mkdir, cat) and understanding the sheer power of sudo. Running scripts with root privileges means you can automate massive system-wide tasks instantly—but it also means you can break things just as fast.

I also dove heavily into permissions using chmod, learning how to restrict and grant access across users, groups, and others. The biggest lesson? Precision. A single spelling mistake in a shell script is incredibly frustrating to debug. Editing files directly in the terminal forces you to slow down and write code attentively.

3. Python Security Tooling

With the basics out of the way, I applied Python to fundamental security tasks. Because my syntax fundamentals were clear, building the Level 0 Python scripts felt relatively smooth.

However, this was just the warm-up. These foundational scripts are setting the stage for much heavier logic in Level 1.

The Proof of Work

I am officially moving past the basics. I have consolidated my deliverables—including log_parser.py, port_scanner.py, and system_health.sh—into a single repository.

🔗GitHub Repository

What’s Next? Level 1 is already underway. I am pushing deeper into advanced scripting and security mechanics.

I will be dropping my Level 1 Build Log right here on November 1st.

If you are also building in the cloud or platform security space, let's connect:

🔗 LinkedIn Profile

🐍 Python Basics — More About Thinking Than Coding

I recently completed Python basics.

At first, I thought Python would be about syntax — variables, loops, conditions.

But very quickly, I realized:

Python is less about syntax and more about how you think through problems.

📚 Learning Approach

I used:

Apna College Python playlist ChatGPT for debugging and hints

But the biggest difference came from changing my approach:

Instead of copying code, I tried to:

think through the problem first write logic in plain English then convert it into code

This slowed me down, but improved understanding significantly.

🧠 Key Areas I Covered Variables & data types Conditionals (if-else) Loops (for vs while) Strings (iteration, patterns) Lists (basic data handling) 🔍 Where Things Broke (and Why)

Most of my issues weren’t syntax errors — they were logic errors.

Examples:

loops not terminating → condition never updated wrong output → print statements inside loops confusion between for and while → unclear control flow

One small but important mistake:

new_list = new_list.append(i)

This failed because:

append() mutates the list — it does not return it

This kind of issue highlights a bigger point:

Understanding behavior is more important than memorizing syntax.

🛠 Practical Output

By the end of this phase, I could solve:

string reversal vowel counting palindrome checking list operations (max, sum, duplicates)

These are simple problems, but they helped build logic confidence.

🐧 Linux Deep Dive — Where Systems Start Fighting Back

Alongside Python, I focused on Linux and Bash.

This felt very different.

If Python is forgiving, Linux is strict and unforgiving.

✅ Day 8 — Text Editors (vim, nano)

Vim initially felt unusable.

After going through vimtutor, I started understanding:

modes navigation editing workflow

This wasn’t just about editing text — it was about learning how tools expect you to think.

✅ Day 9 — Bash Scripting

I learned:

variables conditionals loops

Then tried building a backup script.

💥 Where Things Broke

Most errors came from small details:

missing spaces in [ ] incorrect variable usage (\(file vs "file") argument handling (\)1) path issues file system assumptions

Errors like:

missing ']' No such file or directory

This led to an important realization:

In Bash, small syntax mistakes don’t degrade gracefully — they break execution completely.

⚠️ Incomplete Work (Carrying Forward) Backup script → partially working, still debugging Log analysis (Day 10) → not started

Instead of rushing, I’m moving these into the next week.

💡 Key Technical Insights from This Week

1. Strict Systems Expose Weak Thinking

Linux doesn’t “adjust” to your mistakes. It forces you to be precise.

1. Debugging Is the Core Skill

Most time is not spent writing code — it’s spent fixing it.

1. Small Errors Have Large Impact

A missing space or wrong path can completely break execution.

1. Learning Slower Can Be Better

Rushing leads to shallow understanding. Struggling leads to retention.

🔥 Shift in Perspective

Earlier, I thought:

Coding = writing code

Now it feels like:

Coding = understanding why things fail, and fixing them step by step

🎯 What’s Next (Week 3) Complete backup script Start log analysis (/var/log, grep, etc.) Improve Bash debugging Continue Python problem solving 🧠 Final Thought

This week wasn’t clean or complete.

But it was real.

And more importantly, it was useful.

💬 Open to Feedback How did you get better at Bash scripting? Any structured way to improve debugging?

Would love to learn from people ahead in this field.

instead of just studying theory. i deciced to focus on hands on learning by buiding projects.

this is week 1/52.

🖥️ Setting Up My Lab (Ubuntu on VirtualBox)

This week started with setting up my cybersecurity lab using VirtualBox.

Since I had already installed Kali Linux before, I thought it would be quick.

It wasn’t 😅

What went wrong:

• VirtualBox didn’t ask for storage/memory like I expected

• Faced graphics errors during boot

• Ubuntu sometimes switched to safe graphics automatically

• Guest Additions caused more confusion than help

• ISO mounting issues during restart

At one point, the system just wouldn’t boot properly.

After multiple restarts, tweaks, and trying different settings, I finally got it working.

What I learned:

Setting up the environment is not a side task — it is part of cybersecurity learning.

⚙️ Initial System Setup

Once Ubuntu was running, I started with basic setup:

sudo apt update
sudo apt upgrade -y
sudo apt clean

Then installed essential tools:

sudo apt install git curl wget net-tools htop -y

And build tools for future work:

sudo apt install build-essential dkms linux-headers-$(uname -r) -y

🧠 Learning Linux Fundamentals

After setup, I focused on Linux basics — the foundation of cybersecurity.

📁 File Navigation & Management

I practiced:

• pwd, ls, cd

• mkdir, cp, mv, rm

Insight:

Understanding where you are in the system (paths) is more important than memorizing commands.

🔍 File Viewing & Editing

• cat, less

• echo "text" > file.txt

Also learned this the hard way:

One missing quote can break your command 😅

🔐 File Permissions (Most Important Part)

Using:

ls -l

I started understanding permissions like:

-rw-r--r--

Then practiced:

chmod 644 file.txt
chmod 755 script.sh
chmod 600 secret.txt

What clicked:

• 4 = read

• 2 = write

• 1 = execute

Real insight:

Permissions aren’t just syntax — they control who can access what.

⚠️ Security Insight

• 777 → dangerous

• 600 → private files

• 755 → executable scripts

Misconfigured permissions = real vulnerability

👤 Users & Ownership

Commands I used:

sudo adduser testuser
sudo chown testuser file.txt
sudo deluser --remove-home testuser

Important realization:

Deleting a user doesn’t delete all their files.

Only files inside /home/testuser are removed.

This introduced me to:

Orphaned files — leftover files without a user

(which can be a real security risk)

🧠 Process Management

I learned how to monitor and control processes:

• ps, ps aux

• top

• kill, kill -9

Practice:

• Ran sleep in background

• Found it using ps

• Killed it manually

This felt like real system control.

📦 Package Management

Learned how software is installed in Linux:

sudo apt update
sudo apt install htop
sudo apt remove htop
sudo apt clean

Also understood:

• update vs upgrade

• install vs remove vs purge

🧠 Key Takeaways from Week 1

• Linux is not just commands — it’s how systems behave

• Permissions are the foundation of security

• Debugging teaches more than tutorials

• Mistakes are part of the process

• Setting up your lab is real learning

⚡ Challenges I Faced

• VirtualBox graphics issues

• Storage limitations

• Permission confusion

• User deletion behavior

• File ownership problems

🔥 Let’s connect

If you’re on a similar path or already working in cybersecurity, I’d love to learn from you.