A pattern turns up in almost every group of DevOps learners. Someone completes a lab, feels proud, posts it to their portfolio and moves on to the next one. Months later a recruiter or a classmate tries to run it, and nothing works. The pipeline fails at the first step, the container image cannot be pulled, the walkthrough points to a page that no longer exists. The learner is surprised, because nothing was changed. That is the diagnosis in one sentence: nothing was changed, and everything around it was. This article treats the situation like an incident review, with the symptom, the likely causes and a repair for each.
The symptom
A project that worked on the day it was finished now fails or confuses people. The failures look different each time, but they share one feature: they appear without any change to your own code. That is a strong clue. When behaviour changes and your code did not, the cause lives in the environment, the dependencies or the references your project relies on.
Diagnosis one: dependencies moved on
Most labs pull in packages, base images, plugins and tool versions. If you left versions unpinned, each fresh run may fetch something newer than what you tested. Sooner or later one of those newer versions changes behaviour, removes a feature or stops being published. Your project did not break; it was never fully specified.
Fix: record exact versions of the tools, images and packages your project needs, and re-run it on a schedule to see when it drifts. Updating on your own terms, a little at a time, is much calmer than discovering six changes at once.
Diagnosis two: hidden assumptions on your machine
Your laptop holds environment variables, cached credentials, local files and installed tools that you stopped noticing long ago. A project can depend on them without any mention in the documentation. When someone else runs it, those invisible helpers are absent.
Fix: start from a clean environment, follow your own instructions literally and note every step that fails. This is the best way to find gaps in your documentation, and it is the same habit used when a team verifies a deployment. It also builds the skill we describe in developing structured thinking for DevOps problems.
Diagnosis three: expired free tiers and abandoned resources
Cloud accounts used for practice often rely on trial credits or free allowances that expire. Resources left running may start to cost money, and resources shut down by the provider may leave your project pointing at nothing.
Fix: keep a short inventory of every resource you created in each account, with the purpose and a review date. Delete what you no longer need, and write a note in the project explaining which resources it expects to exist. Checking before you build another lab protects both your budget and your portfolio.
Diagnosis four: links that stopped working
This cause is easy to overlook because it sits in the text rather than the code. Walkthroughs cite documentation pages, tutorials, repositories and dashboards. Over time, addresses change or vanish. A reader who follows one and lands on an error loses confidence in the entire project, even if the code is flawless.
Fix: list every external address in your README and portfolio, test them and replace or remove broken ones. If you publish many of them, a link-management platform can do the checking for you. URLSnow keeps published links organised and runs automatic health checks that note which ones have stopped responding, so you can repair them before a hiring manager finds them.
Diagnosis five: knowledge gaps that were hidden by the guide
Following a guided lab can create the feeling of understanding without the substance. When you revisit the project and a step fails, you may find you cannot explain why it worked before. That is not a failure of the project; it is a signal about the learning underneath it. We discuss this at length in our piece on the foundational gaps students often need to close.
Fix: when an old lab breaks, treat the repair as the actual exercise. Work out the cause and write down what you learned. A repaired project with an honest changelog says more about your ability than a pristine one that nobody has touched.
Diagnosis six: no owner and no schedule
The deepest cause is organisational, even for an individual. Nobody was responsible for the project after it was finished, and no date was set to look at it again. Without an owner, decay is the default.
Fix: give every portfolio piece a status: active, maintained, archived or retired. Archive clearly, with a note that says the project is no longer maintained and explains what it was for. A tidy archive is respectable. A broken project presented as current is not.
A repair routine you can adopt
- List your projects and write down their current status honestly.
- Pick the one that matters most for your goals and run it from a clean environment.
- Record each failure, its cause and the fix.
- Pin versions and add a short note about assumptions.
- Check every external link and resource reference.
- Archive or retire projects that no longer serve you.
- Set a recurring date to repeat the review.
A quick worked example
Imagine a deployment lab finished in spring. In autumn its pipeline fails at the build stage. Reading the log shows an unpinned base image that was updated upstream (diagnosis one). While fixing it, the learner discovers that the lab relied on a credential stored only on their old laptop (diagnosis two), and that a screenshot in the README links to a dashboard that was shut down (diagnosis four). One failure, three causes, all findable in an hour with a clean environment and a patient read of the log.
What this does for your learning
It is tempting to treat maintenance as a detour from learning. In truth, it is where some of the most valuable learning happens, because real systems spend most of their lives in the stage after launch. Employers know this, and they respond well to candidates who can say what broke, how they found out and what they changed. Before you start your next lab, spend an evening reviving the last one. The result will be a smaller, sturdier portfolio and a clearer idea of what you can actually do.
