As my final cloud engineering capstone project, I was tasked with provisioning a production-grade Kubernetes environment on AWS and deploying a microservices retail application. This is the story of how I built “Project Bedrock” for InnovateMart — including every mistake, every error, and every lesson learned along the way.

The Mission

The project required me to:

• Provision a VPC and EKS cluster using Terraform
• Deploy the AWS Retail Store Sample App
• Set up managed databases (RDS MySQL, RDS PostgreSQL, DynamoDB)
• Implement secure developer access
• Configure CloudWatch observability
• Build a serverless S3 + Lambda pipeline
• Automate everything with GitHub Actions CI/CD

Architecture Diagram

Setting Up the Foundation

Tools and AWS Configuration

The first thing I did was verify my tools were installed — AWS CLI, Terraform, kubectl, and Helm. Interestingly, my AWS credentials were already configured from a previous project (a month 3 assessment where I had created a terraform-user with AdministratorAccess). That saved me some time.

Creating the GitHub Repository

I created a public GitHub repository called project-bedrock and cloned it locally. I set up the folder structure:

project-bedrock/
├── terraform/
├── k8s/
├── lambda/
└── .github/workflows/

Remote State Management

Before writing any Terraform code, I manually created an S3 bucket for remote state:

Made an error here btw but let’s continue.

aws s3api create-bucket \
  --bucket bedrock-tfstate-ifhy1 \
  --region us-east-1

Then configured the Terraform backend to use it. This is crucial — local state files are not acceptable for CI/CD pipelines.

First Mistake: Pushing Terraform Provider Files to GitHub

When I tried to push my code, GitHub rejected it because the Terraform provider binary (terraform-provider-aws) was 691MB — way above GitHub's 100MB limit. I had forgotten to add .terraform/ to my .gitignore.

Fix: Added .gitignore and used git filter-branch to remove the large files from history:

git filter-branch --force --index-filter \
  'git rm -rf --cached --ignore-unmatch terraform/.terraform' \
  --prune-empty --tag-name-filter cat -- --all
git push origin main --force

Lesson: Always add .terraform/ to .gitignore before your first commit.

Provisioning the VPC

I used the terraform-aws-modules/vpc/aws module to create:

• A VPC named project-bedrock-vpc
• Public and private subnets across 2 AZs (us-east-1a and us-east-1b)
• NAT Gateway for private subnet internet access
• Internet Gateway for public subnets

The default_tags feature in the AWS provider ensured every resource was automatically tagged with Project: karatu-2025-capstone.

Running terraform apply created 19 resources successfully.

Provisioning the EKS Cluster

Second Mistake: Wrong Instance Type

I configured t3.medium for the EKS node group, but got this error after 37 minutes of waiting:

AsgInstanceLaunchFailures: Could not launch On-Demand Instances. 
InvalidParameterCombination - The specified instance type is not 
eligible for Free Tier.

Fix: Changed to t3.small. The cluster came up successfully with 2 nodes.

Lesson: Always check instance type availability in your account before applying. 37 minutes of waiting is painful!

Deploying the Databases

I created:

• RDS MySQL for the catalog service
• RDS PostgreSQL for the orders service
• DynamoDB for the cart service
• Secrets Manager to store all database credentials securely

Third Mistake: Reserved Username

PostgreSQL on RDS doesn’t allow admin as a username — it's a reserved word. Got this error:

MasterUsername admin cannot be used as it is a reserved word used by the engine

Fix: Changed PostgreSQL username to dbadmin.

Lesson: PostgreSQL on RDS has reserved usernames. Always use something like dbadmin instead of admin.

Installing the AWS Load Balancer Controller

This was needed to create an Application Load Balancer (ALB) for the application ingress.

Fourth Mistake: Outdated IAM Policy

The Load Balancer Controller kept failing with:

AccessDenied: not authorized to perform: 
elasticloadbalancing:DescribeListenerAttributes

Fix: Downloaded the latest IAM policy from the v2.11.0 release instead of v2.7.2:

curl -o terraform/lb-controller-policy.json \
  https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.11.0/docs/install/iam_policy.json

Lesson: Always use the latest IAM policy file when installing the AWS Load Balancer Controller. Older versions miss new required permissions.

Deploying the Retail Store Application

Fifth Mistake: Wrong Helm Repository URL

I tried several Helm chart URLs that didn’t work:

Error: looks like "https://aws-containers.github.io/retail-store-sample-app" 
is not a valid chart repository

Fix: The app doesn’t have a traditional Helm repo. I downloaded the Kubernetes YAML manifests directly:

curl -L -o k8s/kubernetes.yaml \
  https://github.com/aws-containers/retail-store-sample-app/releases/download/v1.5.0/kubernetes.yaml
kubectl apply -f k8s/kubernetes.yaml -n retail-app

After the pods came up, I created an Ingress resource and within minutes had a working retail store accessible at a public ALB URL!

CloudWatch Observability

Sixth Mistake: Node Capacity Issues

When installing the CloudWatch Observability addon, it went into DEGRADED state:

InsufficientNumberOfReplicas: 2 Too many pods. 
no new claims to deallocate

Fix: Scaled up from 2 to 3 nodes to give the CloudWatch DaemonSet enough capacity:

aws eks update-nodegroup-config \
  --cluster-name project-bedrock-cluster \
  --nodegroup-name <nodegroup-name> \
  --scaling-config minSize=1,maxSize=3,desiredSize=3

Lesson: CloudWatch Observability addon runs a DaemonSet on every node. Make sure you have enough node capacity before installing it.

The S3 Bucket Name Mistake

Seventh Mistake: Wrong Student ID in Bucket Name

The project required the S3 bucket to be named bedrock-assets-[your-student-id]. I had used my GitHub username (ifhy1) instead of my actual student ID (ALT/SOE/***/****).

Fix: Updated the bucket name to bedrock-assets-alt-soe-***-**** in Terraform and reapplied. Since the old bucket had a test file in it, I had to empty it first:

aws s3 rm s3://bedrock-assets-ifhy1 --recursive
terraform apply

The error I made mention of earlier, lol. It was an oversight on my end.

The Credentials Exposure Incident

Eighth Mistake: Exposing AWS Credentials on GitHub

This was my biggest mistake. When generating grading.json with terraform output -json, the file contained the bedrock-dev-view secret access key and console password in plain text. I pushed this to GitHub.

Within hours I received emails from:

• AWS Security — notifying me that the key had been quarantined with AWSCompromisedKeyQuarantineV3 policy
• GitGuardian — alerting me about the exposed secret

Fix:

1. Detached the quarantine policy
2. Deleted the compromised access key
3. Created a new access key via Terraform
4. Cleaned git history using git filter-branch
5. Updated grading.json to redact sensitive values with SEE-GOOGLE-DOC

NEVER commit AWS credentials to GitHub, even for exam purposes. Always redact sensitive values before pushing. Use sensitive = true in Terraform outputs and never include them in files committed to source control.

The TLS/HTTPS Bonus (Extra Objectives)

The bonus objective required exposing the application over HTTPS using ACM which is the AWS CERTIFICATE MANAGER and a custom domain. The project suggested using nip.io (a free magic DNS service) if you don’t own a domain.

Ninth Mistake: nip.io doesn’t work with ACM

I requested an ACM certificate for retail.54.152.50.23.nip.io but it stayed in PENDING_VALIDATION forever because ACM requires DNS validation — and you can't add DNS records to nip.io since you don't own it.

Fix: I had to purchase a real domain projectbedrock.xyz from Namecheap for $xx to properly validate the ACM certificate.

The project documentation suggested nip.io but this doesn’t actually work with ACM certificate validation. You need a real domain you control to complete TLS termination properly.

CI/CD Pipeline

I implemented GitHub Actions with two workflows:

PR workflow (pr.yml): Runs terraform plan on every pull request and posts the output as a PR comment so the team can review infrastructure changes before they're applied.

Apply workflow (apply.yml): Runs terraform apply automatically when code is merged to main.

AWS credentials are stored as GitHub repository secrets — never hardcoded in workflow files.

Final Architecture

The completed architecture includes:

• VPC with public/private subnets across 2 AZs
• EKS cluster (v1.34) with managed node groups
• ALB exposing the retail store application
• RDS MySQL for catalog data
• RDS PostgreSQL for order data
• DynamoDB for cart data
• Secrets Manager storing all database credentials
• CloudWatch with FluentBit shipping all container and control plane logs
• S3 + Lambda for serverless image processing
• GitHub Actions for automated infrastructure management

Key Lessons Learned

1. Always add .terraform/ to .gitignore before your first commit
2. Check instance type availability before applying EKS node groups
3. PostgreSQL on RDS doesn’t allow admin as a username
4. Always use the latest IAM policy for the AWS Load Balancer Controller
5. Scale your nodes before installing DaemonSet-based addons
6. Read requirements carefully — student ID means your actual student ID!
7. NEVER commit AWS credentials to GitHub — use sensitive = true and redact before pushing
8. nip.io doesn’t work with ACM certificate validation — use a real domain

Conclusion

Building Project Bedrock was a challenging but incredibly rewarding experience. Every error I encountered taught me something new about AWS, Terraform, and Kubernetes. The key to success was staying calm when things went wrong, reading error messages carefully, and fixing issues methodically.

If you’re working on a similar project, I hope this article saves you from making the same mistakes I did!

The complete source code for this project is available at: https://github.com/Ifhy1/project-bedrock

And most importantly, if there’s anything I’ve learned althrough my Cloud/DevOps Engineering journey — it’s PATIENCE.

I had never done anything at this scale before. I knew the concepts, I had done smaller projects, but putting it all together end to end was a different thing entirely.

This article is not a tutorial. It is an honest account of what actually happened— the things that broke, the things that confused me, and the small victories that kept me going. If you are learning cloud engineering or about to attempt something similar, I hope this saves you some of the hours I lost.

The Architecture

The application was a full-stack task management app called MuchToDo. Here is what the stack looked like:

• Frontend: React with TypeScript, hosted on AWS S3 and served globally via CloudFront
• Backend: a Golang API running inside a Docker container on EC2, sitting behind an Application Load Balancer
• Database: MongoDB Atlas for data persistence
• Cache: AWS ElastiCache Redis for session and data caching
• Infrastructure: all provisioned with Terraform
• CI/CD: GitHub Actions for automated deployments.

Stay with me…

Setting Up the Infrastructure with Terraform

I used Terraform to provision everything — VPC, subnets, EC2, ALB, ElastiCache, S3, CloudFront, IAM roles, security groups. All of it.

This part actually went relatively smoothly. Terraform is opinionated in a good way. You write what you want, it figures out the order, and when it works it is deeply satisfying to see 27 resources created in one go.

The key thing I learned here is to always use modules. Keeping networking, compute, storage and monitoring in separate modules made everything easier to reason about and debug. And you might be wondering why, here it is:

Because when everything is in one big Terraform file it becomes very hard to manage.

Easier to debug — if your EC2 is having issues you go straight to the compute module. You don’t have to scroll through 500 lines of mixed code looking for the right resource.

Easier to reason about — each module has one responsibility. Networking handles VPC and subnets. Compute handles EC2 and ALB. You always know where things live.

Reusable — if you start another project you can copy just the networking module and reuse it without touching anything else.

Less risk — changes to your storage module won’t accidentally affect your networking. They’re isolated from each other.

Think of it like organizing a house. You don’t throw everything in one room. Kitchen stuff in the kitchen, bedroom stuff in the bedroom making it easier to find things, easier to clean up when something goes wrong.

The DNS Nightmare

This is where things started getting interesting.

I was trying to run my Go application locally and connect to MongoDB Atlas. I had checked everything— my Atlas network access settings were fine, my connection string was correct, my code was fine. But the app kept throwing DNS resolution errors. It simply could not find the MongoDB Atlas hostname.

I changed my Mac’s DNS to Google’s 8.8.8.8. Still nothing. My MiFi was the problem— it just refused to resolve the MongoDB Atlas address. No amount of DNS changes on my end was going to fix that.

So I moved to my EC2 instance instead. AWS data centers do not have WiFi DNS issues. I also passed dns 8.8.8.8 directly to Docker just to be safe. It connected immediately.

Sometimes the bug is not in your code. It could just be your internet connection being difficult.

EC2 Running Out of Resources

Once I was on EC2, I tried running the Go application directly on the instance. This was a mistake.

I ran go run cmd/api/main.go and the instance just hung. Then it crashed. Then I got a "disk quota exceeded" error. I added an extra 2GB RAM to the instance thinking that would help, honestly this was a first. It did not.

The problem was that compiling a complex Go application on a small EC2 instance is just too much. The instance did not have the resources for it.

The fix was to stop building on EC2 entirely. I moved the Docker build to GitHub Actions instead. GitHub Actions spins up a fresh runner with 2 vCPUs and 7GB RAM — far more than my t3.micro. The runner builds the Docker image, pushes it to ECR, and EC2 simply pulls and runs the already built image.

EC2 does not touch the compilation anymore. GitHub Actions does the heavy lifting, EC2 just runs the result.

Build where you have resources. Run where you need to.

The MongoDB Password Problem

At some point, my MongoDB connection stopped working and I could not figure out why. The URI looked correct. The password looked correct. But I kept getting authentication errors.

It turned out my Atlas password had characters, especially underscores, that were causing issues when used inside the connection string URI. I switched to a clean alphanumeric password and it connected immediately.

Keep your database passwords simple when embedding them in connection strings. Small thing, costs a lot of time.

Getting the CI/CD Pipelines Working

This was the most frustrating and most rewarding part of the whole project.

The frontend pipeline was relatively straightforward— build React, sync to S3, invalidate CloudFront cache. The backend pipeline was more involved— run tests, build Docker image, push to ECR, SSH into EC2 and deploy the new container.

At one point GitHub sent me a “secret detected” notification. GitHub has a feature called secret scanning— it automatically scans every push for exposed credentials like API keys, access tokens and passwords. If it finds one it alerts you immediately and in some cases revokes the credential automatically. I had accidentally pushed a file with my AWS credentials exposed in plain text. GitHub flagged it immediately. I had to rotate my AWS keys, change passwords and audit everything I had pushed. I was so frustrated I genuinely considered scrapping the whole project and starting over.

I did not. But it was close.

This taught me something important— never hardcode credentials. Ever. Use environment variables, use GitHub secrets, use whatever your platform provides. GitHub will catch it and so will bad actors if you are not careful.

The SSH part caused the most grief after that. My original key pair did not work. I spent a long time trying to figure out why before realizing the key file permissions were wrong on my Mac, and eventually that the key just did not match the EC2 instance. I had to create a new key pair, update Terraform to use it, recreate the EC2 instance, and start fresh.

Then there was the issue of secrets not passing correctly through the SSH action in GitHub Actions. Secrets referenced inside an SSH script do not expand the way you expect. The fix was to pass them explicitly as environment variables to the action.

Another thing that caught me off guard— when a workflow fails and you fix the code, do not just click Re-run failed jobs. That reruns the old version of your workflow, not the new one you just pushed. You have to trigger a completely fresh run. I spent longer than I would like to admit pushing fixes that were not actually being picked up because I kept rerunning the wrong version.

Every one of these problems taught me something I would not have learned from just reading documentation.

When It Finally Worked

After everything— the DNS issues, the disk quota errors, the SSH key drama, the secrets not passing, the MongoDB authentication failures— I opened my browser and hit the ALB URL.

{"message":"Welcome to MuchToDo API"}

Then I opened the S3 frontend URL and saw the full application loading— sign in, sign up, the whole thing.

It is a feeling that is hard to describe. Not just relief. Something closer to proof. Proof that all the concepts I had been studying were real, that I could actually build something that works, that runs, that deploys automatically when I push code. I felt so proud of myself.

What I Learned

A few things I would tell anyone attempting something similar:

Build in CI, run in production. Do not try to compile heavy applications on small EC2 instances. Use GitHub Actions or any CI runner for builds and let your server just run the result.

DNS issues are real. If your app cannot resolve a hostname, check your network before touching your code.

Never hardcode credentials. GitHub secret scanning will catch it, but by then you have already exposed yourself. Use environment variables and GitHub secrets from day one. Rotating keys and auditing your commit history because of one careless push is not a fun afternoon.

Keep secrets simple. Special characters in passwords and connection strings will cost you time. Keep them alphanumeric until you know exactly how your stack handles them.

SSH keys matter. Understand how your key pairs work before you need them in a pipeline. It is much harder to debug under pressure.

The documentation is the last thing but not the least thing. A good README, architecture doc and runbook are part of the work, not an afterthought.

Most importantly— build things. Nobody gets it right the first time. The goal is to get it running.

CIAO!!!

This is what that actually looked like.

The Crash Loop I Didn’t See Coming

I set up my docker-compose.yml, ran docker compose up, and watched my backend container immediately start dying and restarting. Over and over. The classic Restarting (1) status.

My first instinct was that something was wrong with the code. It wasn’t.

Running docker logs much-todo-api told me everything:

level=ERROR msg="could not connect to MongoDB" error="error parsing uri: scheme must be \"mongodb\" or \"mongodb+srv\""

The URI was malformed — which meant the app was reading an empty string and trying to use it as a connection string. I went digging. Checked the compose file. The environment variable was set. Checked the Go code with grep -r "Getenv" . — and found that the app wasn't using os.Getenv at all. It was using Viper.

Opened config.go and there it was:

MongoURI string `mapstructure:"MONGO_URI"`

My compose file had MONGODB_URL. The config expected MONGO_URI. One rename later, the container stayed up.

It’s the kind of bug that feels embarrassing in hindsight but teaches you to actually read your config structs instead of assuming the names match.

I also learned patience the hard way. After running docker compose up -d --build, I'd just sit there staring at the terminal for 10-15 seconds before even daring to run docker ps — because MongoDB needs time to fully initialize before the API can connect to it. If you check too early, everything looks broken. So I just waited. Uncomfortably. Counting in my head.

What made it sweeter was opening the browser right after and hitting localhost:8080/health. Just a single line back:

{"cache":"disabled","database":"ok"}

Tiny response. But after all that digging, seeing "database":"ok" felt genuinely good. The thing was alive.

Moving to Kubernetes

Getting Docker Compose working felt like a win, but the real task was orchestrating everything on a local Kubernetes cluster using Kind.

This meant writing manifests for deployments, services, and persistent volume claims — making sure MongoDB data would survive pod restarts, and that the API and database could actually find each other inside the cluster.

The first time I applied my manifests and ran kubectl get pods, I got this:

much-todo-api   0/1   CrashLoopBackOff   4   2m57s

More crashing. More logs. More fixing. Eventually I got the startup timing sorted — Kubernetes doesn’t wait for MongoDB to be fully ready before starting the API, so the app was trying to connect before the database was up. A rollout restart after MongoDB settled fixed it.

Then, finally:

mongodb-86f7655f86-h2vpp        1/1   Running   0   21m
much-todo-api-6f9975bc94-92g6q  1/1   Running   0   14m

That 1/1 Running on both lines is a specific kind of satisfaction I didn't expect to feel this strongly about.

Checking the Work

With everything running, the API was accessible at localhost:30001/health through the NodePort service. Browser showed:

{"cache":"disabled","database":"ok"}

Simple. But after everything it took to get there, it felt like a lot.

I also set up an Ingress resource for future scalability — not required right now, but good practice to have it in place. The full kubectl summary showed pods, services, deployments, replicasets, and ingress all healthy.

What I Actually Learned

The technical stuff — Docker multi-stage builds, PVCs, NodePort vs ClusterIP, Ingress — that’s all in the documentation. You can read your way to understanding it. That part is fine.

What the docs don’t teach you is how to stay calm when your container has been crash looping for 20 minutes and you genuinely don’t know why. Or how to resist the urge to change five things at once when something breaks, because then you won’t know which change actually fixed it. I learned to slow down, read the logs properly, and follow the error to its source — even when the source turned out to be something as small as MONGODB_URL vs MONGO_URI.

I also learned that DevOps has a very specific relationship with waiting. You run a command and then you just… sit there. Waiting for pods to come up, waiting for MongoDB to initialize, waiting for the build to finish. At first it feels like nothing is happening. Eventually you realize that’s just how it works, and you stop refreshing every two seconds.

Honestly, the most valuable thing this project gave me wasn’t Kubernetes knowledge — it was the experience of being stuck, not knowing the answer, and finding my way out anyway. That’s the skill that actually transfers. The commands I’ll look up again. That feeling of working through something confusing until it clicks? That stays.

This project broke me a little and then put me back together with more knowledge than I started with. That feels like exactly the point.

Onwards.

I set out to build what I call the “Chaos Resume” — a dynamic, cloud-native portfolio hosted on AWS, deployed entirely via Terraform. What started as a “simple” infrastructure-as-code project quickly turned into a masterclass in troubleshooting, folder structures, and the importance of the Cmd+S keys.

The Vision: Infrastructure as Art

The goal was honestly clear:

• Backend: Python (Flask) running on an Ubuntu EC2 instance.
• Infrastructure: A custom VPC, subnets, and security groups in us-east-1.
• The Twist: A “Chaos Engineering” dashboard with interactive UI elements, floating cloud animations, and glass-morphism design.

The Reality: A Comedy of Errors

If you think DevOps is just writing code and watching it work, let me tell you about my day.

1. The “Ghost” Edits (The Save Button Struggle)

The most humbling part of the journey? Forgetting to save. I would spend ten minutes perfecting my main.tf or app.py, run terraform apply, and… nothing changed. I was genuinely confused, staring at the screen wondering if AWS was gaslighting me.

The Lesson: Terraform doesn’t care how good your code is if it’s still sitting in your text editor’s “unsaved” memory. Cmd+S is a DevOps engineer's best friend.

2. The Initial Design Slump

When I finally got the first version live, I hated it. It was plain, static, and frankly, didn’t scream “Cloud Engineer.” I wasn’t just looking for functionality — I wanted an experience. I spent hours scrapping the basic look and pivoting to a high-end dashboard with terminal typing effects and real-time infrastructure stats. If I’m putting my name on it, it has to look the part.

3. The Folder Inception

I hit a wall when Terraform started screaming: Error: Invalid function argument. I had created a templates folder for my HTML, but in the heat of the moment, I had accidentally dragged it inside my virtual environment (venv) folder. I was shouting at the terminal that the file existed, but Terraform—the strict librarian that it is couldn't see it because it wasn't in the root directory. I spent far too long fighting the terminal and moving directories until I finally realized I had buried my assets where the compiler couldn't breathe.

4. The 16KB Wall & The S3 Pivot

Once I finally got the folder structure right and the design ready, I hit a hard limit. My “Chaos” design was so CSS-heavy that it exceeded the 16KB limit for AWS User Data — the maximum size for the startup script passed to an EC2 instance at launch.

I went from being confused to being challenged. Instead of stuffing everything into a startup script, I pivoted to a more professional architecture: S3-backed deployments. The EC2 instance would boot lean, then pull the heavy HTML file directly from a secure storage bucket.

Here’s the logic that saved the project:

user_data = <<-EOF
  #!/bin/bash
  sudo apt-get update -y
  sudo apt-get install -y python3-pip python3-flask python3-requests awscli -y

  mkdir -p /home/ubuntu/templates

  # Copy the Python logic
  cat << 'APP' > /home/ubuntu/app.py
  ${file("app.py")}
  APP

  # Pull the "Heavy" HTML from S3 (Bypassing the 16KB limit)
  aws s3 cp s3://$${aws_s3_bucket.resume_assets.id}/index.html /home/ubuntu/templates/index.html

  sudo python3 /home/ubuntu/app.py &
  EOF

Note: The $${...} double-dollar syntax is intentional because it's how Terraform escapes a literal $ inside a heredoc so it doesn't get treated as a variable interpolation.

5. The Terminal Stand-off (The Destruction Refusal)

Even the exit strategy was a fight. By the time I was exhausted and ready to wrap up, I deleted my local files, thinking I was done. But when I ran terraform destroy, the system threw a fit — it refused to tear down the infrastructure because it couldn't find the very file I had already deleted. The fix? I had to touch a ghost file back into existence just so Terraform had something to reference, and then it finally let me wipe the slate clean.

The Cycle: Architect → Deploy → Troubleshoot → Delete

Looking back, I realized I lived the entire DevOps lifecycle in a single session:

Architect: Designed the VPC, subnets, and security groups.

Deploy: Pushed the first “Minimalist” version live.

Troubleshoot: Fought path errors, venv traps, unsaved files, and AWS limits.

Delete: Ran terraform destroy — the most satisfying command of the day.

Final Thoughts

This project was “chaos” by name and chaos by nature. I felt lost more than once, but that’s where the growth happens. Seeing the cute design live on an AWS IP address made every Error: Invalid path worth it.

At the end of the day, Infrastructure as Code is less about clean code and more about refusing to quit when nothing makes sense and to keep applying until the thing you built is actually out there.

And if anyone asks how long it took? “A couple of hours.” We don’t talk about the save button.

Would I do it again? Absolutely. Will I remember to save my files first? …We’ll see.

While it wasn’t completely smooth, cloud projects rarely are, especially when troubleshooting is involved — the challenges helped me build confidence in my problem-solving ability.

Let me walk you through what I built and why each decision mattered.

Architecture Overview

I designed this infrastructure to reflect real-world cloud practices — prioritizing security, controlled access, and high availability from the start. Here’s what the setup looked like:

i. A custom VPC to isolate my resources.

aws ec2 create-vpc — cidr-block 10.0.0.0/16

ii. A Public Subnet

• Bastion Host
• Load Balancer

iii. A Private Subnet

• Web Servers

iv. An Application Load Balancer to distribute traffic.

v. EC2 instances running NGINX.

vi. Ansible to automate configuration.

Architecture Diagram

The diagram shows how user traffic and administrative access are separated within the infrastructure.

Incoming requests from the internet first reach the Application Load Balancer (ALB) in the public subnet. The ALB distributes traffic evenly between Web Server 1 and Web Server 2, both running NGINX inside private subnets. This ensures high availability — if one server fails, the other continues serving traffic.

The web servers are not publicly accessible. Instead, they only accept traffic from the load balancer on port 80.

Below the web servers is the Bastion Host, which serves as a secure administrative gateway. Engineers connect to the Bastion Host via SSH from the internet, and from there, access the private web servers. This prevents direct SSH exposure of the web servers and significantly reduces the attack surface.

This architecture ensures:

• Only the load balancer is exposed to public traffic
• Web servers remain private and protected
• Administrative access is controlled through a single secure entry point
• Traffic is distributed for fault tolerance and availability

Why I Used a Bastion Host

Security is a top priority in cloud environments because if there’s one thing I’ve learned in cloud engineering is that “If a server doesn’t need to be public, do not make it public”.

Instead of assigning public IP addresses to my web servers, I placed them inside private subnets and created a Bastion Host as the only entry point.

What this means is that:

i. The web servers are hidden from the internet.

ii. SSH access is tightly controlled.

iii. The attack surface is significantly reduced.

SSH into Bastion Host

ssh -i ~/.ssh/key.pem ec2@user<bastion-public-ip>

SSH from Bastion Host to private EC2 server

ssh -i ~/.ssh/key.pem ec2@user<private-ec2-ip>

Rather than managing multiple exposed servers, I only needed to secure one gateway.

It’s a simple decision that makes a huge difference in real-world environments.

How Ansible Made Things Easier

Before this project, automation was something I mostly understood in theory. After working through this setup and doing a fair amount of troubleshooting — I finally understood why engineers rely on it.

Imagine installing NGINX manually on multiple servers… Now imagine repeating that process every single time you add a new one especially when something breaks and you have to trace the issue step by step!!!

NO THANKS.

With Ansible, I wrote the playbook once and ran:

ansible-playbook -i inventory nginx.yml

…and whenever I hit a configuration issue, fixing it in one place meant it was fixed everywhere. Instead of troubleshooting the same problem across multiple servers, I only had to solve it once.

Automation doesn’t just save time, it saves you from future headaches.

Direct EC2 Access vs Load Balancer Access

When you’re new to AWS, it can feel easier to just expose an EC2 instance and call it a day.

But that approach doesn’t scale well in real environments.

Direct EC2 Access:

i. One server handles everything.

ii. If it goes down, your application goes with it.

iii. Each server is publicly exposed.

Load Balancer Access:

i. Traffic is distributed automatically.

ii. Healthy servers receive requests.

iii. Users don’t notice when one instance fails.

iv. Only the load balancer is public.

Basically, Direct access works for demos.

Load balancers work for production.

ALB CLI

aws elbv2 describe-target-health — target-group-arn <target-group-arn>

Challenges I Faced And Lessons Learned

SSH Errors that Tested My Patience

I ran into multiple permission denied errors while trying to connect to my instances. At first, It was frustrating. But troubleshooting forced me to slow down and check the basics:

Was my key pair in the correct location?

Did it have the right permissions?

Were my security groups configured properly?

After fixing the permissions with:

chmod 400 ~/.ssh/key.pem

Everything worked.

Take home lesson: some cloud “mysteries” are usually configuration issues.

When Ansible Refused to Cooperate

There’s honestly nothing like writing a playbook, hitting run… and watching it fail instantly.

Well, my issue turned out to be connectivity.

The fix involved:

Verifying private IP addresses.

Ensuring the bastion host could reach the servers.

Correcting my inventory file.

Once that was sorted, the playbook executed perfectly.

And honestly? Watching your automation work after loads of troubleshooting/debugging is extremely satisfying. Definitely a very satisfying moment.

Load Balancer Health Checks

While setting up the load balancer, I noticed a message indicating that the targets were not yet in use and for a moment I thought I had missed something along the way but it turned out that this was just part of the normal setup process.

Once NGINX was running, port 80 was open, and the configuration was complete, everything registered properly and started working as expected.

What I learned there was that, sometimes a message looks like an issue when it’s really just the system waiting for everything to be fully ready.

What This Project Really Taught Me

More than anything, this project changed how I think about the infrastructure. I no longer see servers as things you just launch.

Now I automatically think about:

• Security first
• Private vs Public access
• Fault tolerance
• Automation
• Scalability

Because Cloud Engineering isn’t just about knowing services but designing systems that survive real-world conditions.

My Final Thoughts

This project pushed me from just learning cloud concepts to actually implementing them.

• AWS networking
• Secure architecture
• Infrastructure automation
• Designing with security in mind
• Thinking more like an engineer instead of just following steps
• Real troubleshooting(breaking things and figuring out why)
• Reading cloud error messages without panicking

I’m still learning, but projects like this remind me that I’m steadily moving from studying cloud to actually building in the cloud.

And honestly, there’s no better way to learn than by getting your hands dirty and figuring things along the way.

On to the next build. 🚀

Step 1: Creating the S3 Bucket

First, I logged into the AWS S3 console and created a new bucket. I gave it a unique name: ifeyinwa-public-bucket and selected my region as Europe (Stockholm).

One tricky part was Object Ownership. AWS defaults to “Bucket owner enforced,” which blocks public access. To allow my file to be public, I selected ACLs enabled and unchecked Block all public access, acknowledging AWS’s warning about exposing objects publicly.

Step 2: Uploading the Image

Next, I uploaded an image to my bucket. During the upload process, under Permissions, I checked Grant public read access. This step is crucial because it ensures anyone with the file’s URL can view it. After clicking Upload, the image appeared in the bucket.

Step 3: Making the Image Public

Once uploaded, I clicked on the file and copied the Object URL. Opening the URL in my browser confirmed that the image was publicly accessible.

Challenges I Faced

• Public access issues: Initially, the default “Bucket owner enforced” setting prevented me from granting public access. I had to create a new bucket with ACLs enabled.
• Permissions confusion: AWS has multiple ways to control access (ACLs, bucket policies, block public access). Learning the difference took some trial and error.
• Verifying public access: I had to remember to test the Object URL in a browser to ensure it was truly public.

Lessons Learned

This exercise taught me the importance of bucket settings and object permissions in AWS S3. Understanding how ACLs and public access work is critical when you want to share files publicly.

By carefully configuring the bucket and checking permissions during upload, I successfully made my image accessible to anyone with the link.

The Great Pivot: From Zero to sudo

Six months ago, if you asked me what “the Cloud” was, I’d probably point vaguely at the sky and then offer to share my Google Drive link. Today, I’m navigating the deep waters of Cloud Engineering, and frankly, I’m loving every mkdir of it.

I’m currently in the thick of my second semester at AltSchool Africa, and if the first semester was a leisurely paddle, this one is a deep-sea dive. I decided to start writing about this journey — not just to document my progress, but because I’ve realised that starting in tech can often feel like you’re the only person who doesn’t already know the difference between cat and ls.

If you’re considering a similar path, or you’re already elbow-deep in your Linux terminal, here’s a sneak peek at what’s been happening and why you should be paying attention to the foundations(very necessary).

* The OS Whisperer: Making Friends with Linux

The core of my initial learning has been understanding Operating Systems, particularly Linux. Before this, I thought an operating system was just the fancy wallpaper and icons I clicked on. Now, I see the matrix:

• The Shell & Commands: I’ve spent hours talking to the machine through the command line. It’s like learning a new, efficient language. I now know how to move files, check system health, and navigate directories faster than I can find my keys in the morning. We’ve explored piping (|) and redirection (>, >>) to chain commands together, making repetitive administrative tasks a breeze.
• Permissions & Privacy: Ever accidentally delete a critical file? Me neither (now!). Understanding file operations, permissions, users, and groups has been crucial. Learning about chmod, chownand the octal system (755, 644) felt like unlocking a secret code. It's the difference between a secure system and a digital house of cards.
• Linux Process Management: Learning about processes and how they run, sleep, or get terminated has been like peering into the system’s brain. I can now manage resource consumption like a seasoned pro — or at least, like someone who knows how to use the top command. We also covered background processes (&) and job control, which is essential for any long-running script.

* Vagrant: My Portable, Reusable Workspace

One of the coolest tools we’ve tackled is Vagrant. For the uninitiated, it lets you create and manage virtual development environments using a simple configuration file. It’s a game-changer for consistency. No more “But it works on my machine!” excuses.

The moment I typed vagrant init and then vagrant up for the first time, I felt a rush. It was the feeling of seeing an entire, perfectly configured server environment spring to life from a single command. It was the first tangible proof that I could provision infrastructure, not just use it.

* The Version Control Lifeline: Git

Finally, we hit Version Control with Git. If Linux is the engine of the cloud, Git is the insurance policy. Learning to commit, push, pull, and branch has unlocked the door to collaborative work and, more importantly, saved me from panicking when I accidentally break something. It’s the ultimate time machine for code. The power of a well-crafted commit message and the safety of branching before tackling a major feature have fundamentally changed how I approach any project.

What’s Next? Join the Journey!

I’m only a few modules in, and the road ahead is packed with concepts like networking protocols (TCP/IP, DNS), virtualization, and eventually, the big cloud platforms like AWS, Microsoft Azure and Google Cloud Platform(GCP). But right now, I’m enjoying the solid foundation AltSchool is providing.

If you’ve ever wanted to jump into Cloud Engineering, remember this: The most common lie in Linux is when your shell says, “command not found.” The truth is, the command is always there; you just need to tell the system where to look!

Stay tuned as I dive deeper into networking protocols and maybe even manage to spin up my first real cloud instance without needing to call for help.

_inthecl0ud…

https://x.com/inthecl0ud_?s=21

I am part of a growing tech community in Isolo, Lagos, Nigeria, although it hasn’t always been easy to find a place to belong. While my local area is not a hub for open-source activities, I sought out opportunities to connect with other tech enthusiasts by going beyond my immediate environment. I reached out to online communities, attended events, and conducted research to gain the knowledge and network I needed to grow. This exploration has led me to open-source conferences and meetups, which were pivotal in expanding my horizons.

Overcoming Barriers to Growth

Common Challenges

My local community in Isolo, unfortunately, lacks many of the resources and structured support that larger tech hubs offer. As a result, I have faced several challenges in fostering a thriving open-source presence within my area:

• Lack of Established Community: There isn’t a strong, established open-source or tech community locally in Isolo. I’ve had to go beyond my immediate area to find other like-minded individuals, resources, and communities. This has meant that I’ve had to actively seek out online resources, attend external conferences, and do my own research to learn and grow in the open-source space.
• Resource Constraints: Without access to venues, tech infrastructure, or funding, organizing events within the community is difficult. I’ve struggled to create local meetups or workshops due to limited resources, making it harder to build a physical space for engagement.
• Sustaining Engagement: Keeping people engaged, especially when you don’t have regular local events, has been a challenge. The initial excitement about open-source tech can wear off without a consistent community and physical meetings to maintain momentum.
• Limited Outreach: Since my local network is small, it’s been difficult to grow the community and attract new members, particularly people from diverse backgrounds or those unfamiliar with open source. This limited outreach makes it harder to diversify contributions and perspectives.

Strategies That Worked

Given these challenges, I had to get creative to stay connected and engaged with the open-source world:

• External Networking and Conferences: I realized early on that in order to grow and learn, I had to seek opportunities outside my immediate community. Attending my first open-source conferences — such as CHAOSScon Africa 2023 (focused on open-source project health), OSCAfest, and She Code Africa — helped me meet like-minded individuals, learn from experts, and understand what makes an open-source community thrive. These events broadened my perspective and gave me the chance to build connections with global contributors.
• Building Virtual Communities: While physical presence was lacking, I made use of online spaces. Platforms like Discord, Telegram, and GitHub allowed me to connect with other open-source enthusiasts. Virtual collaboration became an essential tool in my journey, and I have continued to use these platforms to stay involved in discussions and contribute to projects.
• Independent Learning and Research: In the absence of a local community, I’ve made research a priority. I’ve followed blogs, tutorials, and contributed to online open-source projects. This independent learning has been crucial in staying up-to-date with the latest developments and best practices in open source.
• Collaborating with Global Communities: While my local community was limited, I’ve been fortunate to connect with global open-source groups and mentorship opportunities. These networks have allowed me to be part of something bigger than my immediate environment and continuously grow.

Through these strategies, I’ve been able to overcome the absence of a local community and continue my open-source journey, despite the challenges.

My First Open Source Conferences: CHAOSScon, OSCAfest, and She Code Africa

A significant milestone in my open-source journey was attending CHAOSScon Africa 2023. This conference, focused on “Open Source Project Health,” gave me a deep dive into understanding the sustainability of open-source projects, how to measure community health, and ways to engage contributors. CHAOSScon allowed me to connect with industry experts and learn how open-source metrics could shape community engagement.

Key Highlights:

• I participated in workshops where I learned how to analyze contributor activity and project health, something that felt particularly important to apply back home.
• Networking with open-source leaders provided me with insights into how open-source communities thrive, especially through inclusivity and active contributor engagement.

Later that year, I attended OSCAfest, which had the theme “Sustainability for Growth.” This event helped expand my network within the African open-source community, offering a broader perspective on how open-source can be scaled and sustained across regions. I gained valuable knowledge on best practices for project contributions, documentation, and strategies for onboarding newcomers.

My experience at She Code Africa was another highlight. This event created a unique space for women in tech, which inspired me to pursue open-source contributions with confidence and passion. It reinforced my belief in the power of mentorship and the importance of creating inclusive spaces for underrepresented groups.

In summary, these conferences and events were not only educational but also instrumental in connecting me with a global network of open-source advocates. I went from having no local community to being part of a vibrant international network that’s supporting my growth in open-source.

Fedora: My Next Step in Open Source

With the knowledge and inspiration I’ve gained from conferences and active participation in these communities, I now look to Fedora as my next step. Fedora’s commitment to inclusivity, mentorship, and community-driven development aligns perfectly with my values. I believe Fedora can further empower local communities by providing more resources, guidance, and financial support for community-driven initiatives.

Here’s how Fedora can play a vital role in expanding community efforts:

1. Expanding mentorship networks: Connecting local contributors with Fedora mentors for open-source guidance.
2. Providing financial support: Offering small grants for venue rentals, internet access, and community events would be highly beneficial.
3. Developing outreach kits: Resources like promotional materials and event planning guides would streamline community engagement efforts.
4. Recognizing active members: Showcasing local contributors through blog features or social media spotlights could boost motivation and participation.
5. Hosting Fedora-sponsored events: Organizing regional Fedora Days or hackathons could strengthen the Fedora ecosystem and foster deeper engagement.

Ideas for Fedora

How can Fedora better support local communities?

Fedora has the opportunity to further strengthen its support for local tech communities by offering tailored resources, mentorship programs, and financial assistance. As local communities often face challenges such as limited resources, outreach barriers, and participant retention, Fedora’s involvement in these areas can make a significant difference.

What resources, mentorship, or funding would be helpful?

1. Financial Support for Local Events: Community-driven events can struggle to secure funding for essential items like venues, refreshments, and internet access. Small grants from Fedora would go a long way in supporting these efforts and ensuring that local groups have the necessary resources to thrive.
2. Expanded Mentorship Programs: More experienced contributors mentoring newcomers is critical for growth. Fedora could provide a structured mentorship program that connects experienced members with local communities to help guide new contributors through the onboarding process, project contributions, and community engagement.
3. Community Outreach Materials: To help local groups grow their reach and attract a diverse pool of contributors, Fedora could provide outreach kits. These kits could include promotional templates, event planning guides, and best practices for inclusivity, all aimed at helping local groups engage with underrepresented communities and create a welcoming space for everyone.
4. Local Fedora Representatives: Introducing dedicated Fedora representatives in various regions who can advocate for Fedora at local events and mentor newcomers. These representatives would act as connectors between Fedora and emerging communities, fostering engagement through meetups, hands-on support, and outreach efforts in areas with limited open-source exposure.

Looking Ahead

Engaging with open-source communities and exploring new opportunities has been an incredible experience. The support from Fedora and similar initiatives would provide a solid foundation for local communities to grow, thrive, and create a welcoming environment for everyone, regardless of background or experience level.

As I continue my journey, I look forward to learning from Fedora’s diverse community, which actively promotes diversity, equity, and inclusion, and to furthering these values within the project. I am excited to contribute to its ecosystem, share my experiences, and work toward making open-source software more accessible to all. Together, we can create an open-source future that’s not only innovative but also supportive and open to everyone who wants to get involved.

Ever looked at open-source projects and thought, I’d love to be part of this, but where do I even start? That’s exactly what Outreachy is here for. It’s not just about getting your foot in the door, it’s about kicking that door wide open for underrepresented voices in tech.

But let’s be real: The Outreachy process can feel like stepping into the unknown. What makes an application stand out? How do you choose a project? What if you’re not a coding pro? Relax, ‘cause’ I’ve got you.

This isn’t just a checklist, it’s your roadmap to standing out in Outreachy. From application to acceptance, here’s how to make your journey count.

Outreachy: A Gateway to Open Source

Outreachy is a fully remote, paid internship designed to bring underrepresented voices into Open Source. If you’ve ever felt like tech wasn’t built for people like you, because of race, gender identity, location, or lack of access — this program exists to change that.

But Outreachy isn’t just about writing code. It’s about contributing to real-world projects, collaborating with a global community, and gaining the kind of experience that makes doors open.

Navigating Outreachy: A Step-by-Step Guide.

Success in Outreachy doesn’t happen by chance, it’s about preparation and persistence. The process follows three key stages:

Application Stage- Prove your eligibility and submit your initial application.

Contribution Stage- Find a project, engage with mentors, and make meaningful contributions.

Final Selection- Submit a compelling final application and wait for that acceptance email!

First Steps: Making Your Application Stand Out

Your application is the first opportunity to demonstrate to Outreachy that you meet their eligibility criteria and are genuinely committed to open source. To strengthen your application, focus on:

Your motivation- Clearly explain why open source matters to you and how it aligns with your long-term goals.

Your journey- Highlight the challenges you’ve faced as someone from an underrepresented background in tech. Be honest and specific.

Your goals- Outline what you hope to gain from this internship and how it will contribute to your growth.

Outreachy requires interns to dedicate 40 hours per week to their projects, so emphasize your availability and commitment. Be precise and thorough because vague or generic responses won’t cut it. Authenticity and attention to detail matter.

Choosing the Right Project: Where do you fit in?

This is where passion meets skill. Once your application is approved, the next challenge is selecting the right project. Here’s how to narrow down your options:

Leverage your strengths- Whether you’re skilled in frontend development, backend systems, UX design, or technical writing, choose a project that aligns with your expertise.

Do your research- Read project descriptions thoroughly, go through past contributions, and study the documentation to understand the project’s scope and requirements.

Stay adaptable- If your first choice feels overwhelming or becomes unavailable, be flexible and explore other options.

Exploring Open Source with Fedora

Fedora, a community-driven Linux distribution, is one of the many open-source projects you might encounter during Outreachy. It provides a welcoming space for contributors of all skill levels, whether you’re interested in coding, documentation, or testing. If you’re looking for a project with strong mentorship and real-world impact, Fedora could be a great place to start for you!

The key is to find a project that not only aligns with your skills but also excites you. A genuine interest will make the contribution process smoother and more rewarding.

Making an Impact: More Than Just a Contribution

Many applicants struggle at this stage, whether by overanalyzing their approach, doubting their abilities, hesitating to seek guidance, or assuming a minor fix is sufficient. To stand out, go beyond the basics by:

Deepen your understanding- Read the documentation(emphasis on this), explore past discussions, and analyze issues to gain clarity.

Engage proactively- Introduce yourself, participate in conversations, and seek guidance and feedback from mentors to establish your presence.

Focus on meaningful contributions- Solve real problems rather than making surface-level edits, and be open to mentor feedback for improvements.

Showcase problem-solving skills- Identify gaps, suggest improvements, implement solutions, and refine them based on feedback.

Stay consistent- Regular contributions and responsiveness to feedback demonstrate reliability and commitment to the project.

Communicate effectively- Ask relevant questions, provide clear explanations, and collaborate with mentors and peers to enhance your work.

Effort, engagement, and a willingness to learn will set you apart from other applicants.

The Final Application: Telling Your Story

By this stage, you should have at least one accepted contribution — though multiple contributions will strengthen your application. Your final submission should effectively highlight:

Your Impact- Clearly outline what you contributed to the open-source project, why it mattered, and how it improved the project.

Your Growth- Reflect on your learning process, the challenges you overcame, and how you adapted along the way.

Your Passion- Demonstrate genuine enthusiasm for open source and your commitment to contributing beyond the Outreachy internship.

Success in Outreachy comes from curiosity, resilience, enthusiasm, and a strong commitment to open-source collaboration, qualities that make a lasting impression on mentors.

Your Path Forward: The Beginning of Something Bigger

Outreachy is a highly competitive program, and getting ahead early can make all the difference. Consistency, meaningful contributions, and engagement with mentors set strong applicants apart.

But no matter the outcome, this journey is an opportunity for growth. You’ll gain hands-on experience, build connections, and develop skills that extend far beyond this internship and become part of a thriving open-source community. Keep learning, keep contributing, and let this be the start of your open-source journey.

Before starting the Outreachy application process, I had heard of Fedora but didn’t know much about it beyond it being a Linux distribution and honestly didn’t know what to expect. Fast forward to today, and I’ve realized Fedora is so much more than just an operating system — it’s a thriving, ever-evolving open-source community that fuels innovation and collaboration.

What is Fedora?

At its core, Fedora is a free and open-source Linux distribution sponsored by Red Hat. But calling it “just another Linux distro” wouldn’t do it justice. Fedora is where cutting-edge technology meets community-driven development. It’s a place where developers, designers, writers, and enthusiasts from all over the world come together to build something great.

Fedora isn’t just about an Open Source, it’s about pushing the boundaries of open-source software. It serves as the testing ground for new features that often make their way into Red Hat Enterprise Linux (RHEL), making it an essential part of the broader Linux ecosystem.

The Four Foundations: The Heart of Fedora

Fedora operates under four guiding principles: Freedom, Friends, Features, and First. And honestly, they’re pretty inspiring:

Freedom: Fedora is all about free and open-source software, giving users complete control over their system. No proprietary nonsense, just pure, community-driven innovation.

Friends: This is a big one cause the Fedora community is one of the most welcoming I’ve come across. Whether you’re a coder, writer, designer, or just curious, there’s a place for you.

Features: Fedora is always ahead of the curve. It’s where new technologies are introduced, tested, and refined before being adopted by other distributions.

First: If you love staying on the cutting edge of tech, Fedora is your playground. It’s constantly evolving, delivering the latest and greatest in open-source software.

What Stands Out About Fedora

One thing that really caught my attention is how open everything is. Discussions, decisions, and contributions happen in public, which makes it easy to see what’s going on and learn from others.

Also a cool thing, Fedora’s Workstation edition is a dream for developers. Whether you’re into web development, AI, or cybersecurity, it provides a smooth, efficient, and customizable environment. Plus, with its GNOME desktop, everything feels modern and polished.

I also found the Fedora DEI (Diversity, Equity, and Inclusion) team inspiring. It’s great to see a team focused on making sure Fedora is welcoming and accessible to contributors from different backgrounds.

What’s Confusing as a Newcomer?

Since I started learning about Fedora during the Outreachy application phase, I realized that diving into an open-source project like this can feel overwhelming at first. There’s a lot to explore, different Fedora editions, contributor roles, and community processes and it’s not always clear where to start. But thanks to Fedora’s rich documentation and friendly community, finding answers is easier than expected.

Advice for Future Outreachy Applicants

If you’re applying for Outreachy in 2026 (or even sooner), here’s my advice: get involved early, be consistent, don’t feel intimidated, be curious, join conversations and explore different areas. Fedora is a community-driven project, and the more you engage, whether through coding, documentation, design, or community initiatives — the more you’ll understand its culture and purpose. Don’t be afraid to ask questions; the Fedora community is incredibly supportive.

Final Thoughts

Fedora isn’t just an operating system, it’s a movement. It’s about collaboration, innovation, and building something greater than the sum of its parts. If you’re looking for an open-source project where you can learn, contribute, and grow, Fedora is an amazing place to start.

And who knows? Maybe a year from now, you’ll be writing your own blog post, reflecting on your journey with Fedora just like I’m doing now.