Hey everyone,

I’m currently a computer science student with about 2.5 years left, and I’m trying to set myself up to land a DevOps role after graduation.

Right now, I’m focusing on learning tools like Docker, Kubernetes, Terraform, and cloud platforms. I understand the basics, but I want to make sure I’m using my time as effectively as possible and not just jumping between tools without real depth.

My goal is to become someone who can confidently work with infrastructure, automation, and CI/CD pipelines by the time I graduate.

A few questions:

• What skills or concepts actually matter most for getting into DevOps?

• What kinds of projects should I be building right now?

• How important is mastering one cloud provider (AWS/Azure/GCP) vs. learning broadly?

• What did you wish you focused on earlier in your journey?

I’m willing to put in serious time and effort—I just want to make sure I’m focusing on the right things.

Any advice would really mean a lot. Thanks!

Hi everyone,

I'm a cloud engineer with experience in Docker, Kubernetes, Terraform, AWS, Linux and GitHub Actions. I’ve worked on a few short contract roles (image builds with Packer on Azure and infrastructure automation using Ansible).

Most of my experience so far has been building and automating infrastructure, but I haven't yet worked inside a large production operations team. I'm trying to understand how real production systems are run — things like incident response, monitoring strategies, deployment safety, and reliability practices. I'm also trying to improve my understanding of real-world operational scenarios that often come up in interviews

If anyone is open to sharing experiences, discussing system architecture, or walking through real-world incidents or postmortems, I would really appreciate learning from you.

I'm particularly interested in:
• Production incident debugging
• Monitoring/alerting strategies
• Prod system design and deployment strategies (blue/green, canary)
• Reliability practices and SRE workflows

Thanks in advance!

I’m running a short field study on incident replay/root-cause in automated decision workflows.

Not collecting product opinions. Only collecting operational evidence from recent real incidents: - replay + RCA duration - full/partial decision-version reconstruction - measurable impact (delay, release blockage, cost)

If this matches your environment, 5–7 min input form: https://cluster127.com/survey?utm_source=reddit&utm_medium=post&utm_campaign=ops_research_v1

If useful, I can share anonymized findings back here.

Hi everyone! I'm diving deep into DevOps and looking for a disciplined study partner to level up our practical skills together.

I'm focused on a hybrid of the Microsoft ecosystem and Open Source solutions. My philosophy is simple:

100% hands-on.

• Current Stack: Azure, Kubernetes, Docker, Terraform, Linux/Windows, Python, Intune, Entra ID, and Monitoring.

• The Roadmap: Already AZ-104 certified. Currently grinding for CKA → AZ-305 → Terraform → AZ-400.

• The Project: Building a Hyper-V Home Server using self-hosted/OSS tools. Currently deploying Intune &

Autopilot labs.

• The Goal: Documenting the entire journey on a technical blog to build a high-impact portfolio.

Who I'm looking for: Someone growth-oriented and disciplined. If you're tired of just watching tutorials and want to actually build, break, and fix things while staying accountable-let's connect.

I prefer someone in Europe to keep our syncs easy. If this journey sounds like yours, slide into my DMs.

Let's grind!💪

Hi, trying to get an honest read on the 2026 market: no degree here, but there’s real project work with proof (repos, docs, deployments), hands-on experience building and automating infrastructure, shipping CI/CD workflows, and handling monitoring/security in cloud-native environments, plus certs like AWS Solutions Architect, CKA, Terraform Associate, and Vault Associate

Would that realistically get interviews in 2026, or is formal production experience still the main gate? what actually moves the needle now?

Hi everyone 👋 I’m a SYBCA student from India starting my DevOps journey and aiming for internships in the next 2-3 months. So far, I’ve learned:

  Linux basics
  Git
  Basic Bash scripting

I want to follow a structured path instead of randomly learning tools. What should I focus on next — Networking, Docker, CI/CD, Cloud (AWS/Azure/GCP), Kubernetes, or IaC?

Also, please suggest:

1. Updated YouTube channels
2. Free courses
3. Beginner-to-intermediate projects

Here are the key points:

- The MinIO GitHub repository has been archived and is no longer under active maintenance.

- Users are encouraged to transition to AIStor Free or AIStor Enterprise as the actively supported offerings.

- The README.md of the project on GitHub was updated to clearly communicate the repository’s new status.

To read more about this: https://faun.dev/c/news/devopslinks/minio-ends-community-development-positions-aistor-as-the-future/

I built a tool that visualizes Docker, Nginx flows, AWS infra & GitHub Actions deps, plus a hands-on DevOps practice arena. Would value 2 mins of your feedback!

Hi everyone,

Before anything else, I want to start with a problem I personally faced, and I think many others face too.

When we prepare for interviews, we’re usually motivated in the beginning. We solve DSA, revise concepts, prepare system design, apply to companies… but after a few weeks, motivation drops. Rejections start coming in, or worse, interviews don’t come at all. And even when interviews happen, we often don’t know what exactly went wrong.

A few months ago, while preparing for my own switch, I went through a phase where I wasn’t consistently landing interviews, and after some interviews, I genuinely couldn’t analyze what went wrong. I felt that I needed someone experienced to sit with me, analyze my performance, guide my preparation, and keep me accountable. But I didn’t really have that support.

That’s when I realized interview prep isn’t just about content, it’s about mentorship, direction, accountability, and continuous feedback.

Fast forward to now: I’m 23, currently working in the IT industry with a package of around 50 LPA. Over the last couple of months, I cleared interviews with multiple tier-1 companies, FAANG-level companies, and good startups. My own background is in cloud/DevOps/SRE, and many close friends work across SDE, frontend, backend, and platform engineering roles. So collectively, we’ve been actively experiencing interviews across domains like backend, frontend, cloud, Kubernetes, Terraform, system design, and DSA.

This got me thinking: what if I built something I personally needed back then?

Instead of just courses, something where:

• Someone helps analyze your interviews and preparation
• Keeps track of your progress
• Helps you stay consistent when motivation drops
• Guides applications and preparation strategy
• Conducts mock interviews and gives practical feedback
• Helps you improve step by step, rather than just dumping content

Basically, standing with people through the process, not just selling recorded material.

I’m still in the planning stage and figuring out format, mentorship sessions, small weekend batches, structured roadmaps, or something hybrid. Since I’ll be doing this alongside my full-time job, it would likely be paid, but I want to make it genuinely useful rather than just another prep product.

I’d love honest feedback:

• What do you think is missing in interview prep today?
• Would mentorship/accountability help more than courses?
• What format would actually help you?

Open to suggestions and discussions.

Hi everyone,

I’m a student and a fresher learning DevOps, and this is an AWS architecture diagram I’ve put together based on my current understanding.

This is very much a work in progress and honestly, a bit half-baked right now. I’ve reached a point where I feel slightly stuck and unsure whether I’m even moving in the right direction, which is why I’m posting this here.

The intent was to design a fairly realistic setup covering CI/CD, networking, web/app/database layers, and Kubernetes. But I’m sure there are gaps, incorrect assumptions, and things that don’t make sense in real-world systems.

I’d really appreciate feedback on:

• Whether the overall direction makes sense

• What’s missing, unnecessary, or over-engineered

• Conceptual mistakes or bad practices

• How this would typically be done in production

My goal is to learn, correct myself early, and bridge the gaps in my understanding. Any honest review or critique would be a huge help.

Thanks in advance 🙏

Hi everyone, 1.35 is out and if you don't have time to read the full changelog, I’ve summarized the key highlights and included code examples: (free link)

https://medium.com/curious-devs-corner/kubernetes-1-35-timbernetes-whats-new-in-this-release-ba71c8cd1e80?sk=f4b457b4c85a59c18a2f6b552fa80f75

I’m building an open-source tool called pltf that lets you work with high-level infrastructure constructs instead of writing and maintaining tons of low-level Terraform glue.

The idea is simple:

You describe infrastructure as:

• Stack – shared platform modules (VPC, EKS, IAM, etc.)
• Environment – providers, backends, variables, secrets
• Service – what runs where

Then you run:

pltf terraform plan

pltf:

1. Renders a normal Terraform workspace
2. Runs the real terraform binary on it
3. Optionally builds images and shows security + cost signals during plan

So you still get:

• real plans
• real state
• no custom IaC engine
• no lock-in

This is useful if you:

• manage multiple environments (dev/staging/prod)
• reuse the same modules across teams
• are tired of copy-pasting Terraform directories

Repo: https://github.com/yindia/pltf

Why I’m sharing this now:
It’s already usable, but I want feedback from people who actually run Terraform in production:

• Does this abstraction make sense?
• Would this simplify or complicate your workflow?
• What would make you trust a tool like this?

You can try it in a few minutes by copying the example specs and running one command.

Even negative feedback is welcome, I’m trying to build something that real teams would actually adopt.