Skip to main content
DevOps Insightsguides & answers

Learn

Learn DevOps in an order that holds

Most DevOps material is organised the way the documentation is: by feature, in the order the API happens to list them. That works for reference and badly for learning, because it means you meet “use a volume” as a rule before you know what a writable layer is — and a rule without its cause does not survive contact with a real problem.

So there are two ways in here. If you want a sequence, the paths below are ordered by dependency: each step exists because the previous one raises the question it answers. If you already have a specific question, go straight to the kind of explanation that matches it.

If you want a sequence

Docker, in the order that makes it stick

You have run `docker run` and it worked, and you are not confident you could explain why.

The usual Docker curriculum teaches features in the order the documentation lists them. This orders them by dependency instead — each step exists because the previous one raises a question it answers.

  1. Why containers are not lightweight VMs

    Start here because the shared kernel explains almost every other Docker behaviour. Learn this last and everything before it was memorised.

  2. Image vs container

    The writable layer is the second load-bearing idea. It has to come before anything about persistence, or “use a volume” is a rule instead of a consequence.

  3. EXPOSE vs published ports

    The first thing that actually goes wrong for most people, and it needs the container's network namespace — which you now have.

  4. ENTRYPOINT vs CMD

    Introduces PID 1 and signal handling, which is where Docker stops being about packaging and starts being about process lifecycle.

  5. Analyse a real Dockerfile

    Paste one you have written. The findings will name things from the previous four steps, which is the point at which they stop being trivia.

  6. Docker interview chain

    Ends here because it tests exactly this sequence, and the last question in it is the one you can only answer if the earlier steps landed.

Kubernetes troubleshooting, from symptom to cause

You can deploy to Kubernetes and you lose time when something breaks.

Ordered the way an incident actually unfolds rather than the way the API is organised. Each step is either a failure you will meet or the concept you need to have already understood when you meet it.

  1. Why Kubernetes uses desired state

    First because it explains why failures are asynchronous and show up somewhere other than the command you ran. Without it, `kubectl apply` succeeding while nothing happens is baffling.

  2. Requests vs limits

    Two of the four common failures are here, and they are opposite: Pending is about requests, OOMKilled is about limits. Separating them early saves a lot of wrong turns.

  3. Pod stuck in Pending

    The first real failure to work through, and the one where the guided narrowing is most useful because the causes look alike from the outside.

  4. Readiness vs liveness

    Needed before CrashLoopBackOff, because a large share of restart loops are caused by the probes rather than the application.

  5. CrashLoopBackOff

    Now the cause list reads as a set of distinct things rather than one confusing state, because you can already tell a probe-induced restart from an application exit.

  6. What happens if a Pod is deleted

    Moves from single-pod faults to the concurrency between components — and explains the errors you see on every deploy.

  7. What happens if a deploy reports success

    The hardest of the four, because nothing is broken from Kubernetes' point of view. Needs readiness probes understood first.

  8. Kubernetes debugging interview chain

    A check on whether the sequence transferred. Every question in it is one of the steps above, asked without warning.

Securing a pipeline you did not design

You inherited a CI/CD setup and you are not sure what to worry about first.

Ordered by likelihood and irreversibility rather than by risk number. The first two are the ones that cause real incidents; the rest matter more once those are handled.

  1. Why you cannot remove a secret from Git

    First because it is the one where the mistake cannot be undone. Everything else on this list is fixable at leisure; this one needs a revocation.

  2. Credential hygiene

    The practical follow-on: where secrets leak from, and the handling rules that stop it. Build arguments and image layers are the two people miss.

  3. Insufficient flow control

    Second highest value for the least effort. One required review on the branch that deploys, with administrators included in the rule.

  4. Dependency chain abuse

    Two flags on your install command close most of it, which makes this the best ratio of protection to work on the whole list.

  5. Why artifacts should be immutable

    Explains what your green pipeline actually proves, and why a version tag is a weaker guarantee than it appears.

  6. Analyse a Dockerfile

    Turns the reading into findings on your own file. Most of the rules above show up as line numbers.

  7. CI/CD security interview chain

    Last because the final question asks you to prioritise these — which you can now do from reasoning rather than from the order they were listed in.

If you already have a question

Four kinds of explanation, each shaped for a different kind of question. The shape matters: a failure is a sequence, a confusion is a distinction, and flattening either into the other loses the thing that made it useful.

8 entriesCommonly confused“I thought these were the same thing.”Two concepts collapsed into one, separated — with the specific error the confusion produces.5 entriesWhat happens if…“What is happening right now, and who is doing it?”Failures as timelines, with every step attributed to the component responsible for it.6 entriesWhy does it work that way“Who decided this, and what were they trading off?”The constraint behind a design, what the system would look like otherwise, and the honest cost.3 entriesInterview chains“What do they ask after the answer I prepared?”Escalating follow-ups, with what a strong answer contains and the trap a weak one falls into.

Something failing right now? Start from the error instead — that route is built for people who do not have time to learn anything.