Learn DevOps in an order that holds

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

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.

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

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

Right after ENTRYPOINT because this is the kernel refusing to start exactly the program those settings name. It also brings back step one: the container shares the host's kernel, so it needs a binary built for the host's CPU.

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.

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.

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.

Two of the four common failures are here, and they are opposite: Pending is about requests; OOMKilled is about limits, except when the whole node runs out of memory and the kernel picks a victim by QoS class. Separating them early saves a lot of wrong turns.

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.

Needed before CrashLoopBackOff, because failing liveness or startup probes are one of the documented causes of a restart loop, separate from the application exiting on its own.

The failure the previous comparison predicts: the pod keeps running but gets no traffic, because readiness never restarts anything. The message after the colon says which of a handful of causes it is.

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.

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

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

A check on whether the sequence transferred. Most of its questions are steps above, asked without warning; the rest build on them.

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.

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.

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

Installing strictly from the lockfile with install scripts switched off is cheap and shuts two direct routes in — a silently updated malicious version, and code running at install time — which makes this the best ratio of protection to work on the whole list.

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

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

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.

First because it is how you prove who you are to a server, and its causes — the wrong user, a key never offered, file permissions sshd will not trust — show where SSH looks before it lets anyone in.

The other direction: the server proving who it is to you. Together with the first step it is the whole of SSH trust, and the safe response to it is a habit worth forming before the day it matters.

The first reading most people get wrong on a healthy machine. Learn why free looks alarming and available is the number to watch before diagnosing anything that uses memory.

Now the services on the box. The exit status splits the failure into never launched and launched-then-quit, which tells you whether to read the unit file or the program's own output.

Placed between processes and networking on purpose: every socket costs a file descriptor, so this is where a per-process limit starts to look like a network fault. One of its fixes lives in the unit file from the previous step.

Addresses before rules about addresses. Work out what a /24 and a /26 contain, because the firewall rules in the next step are written in this notation.

Stateful against stateless filtering, and the outbound rule for ephemeral ports that people miss. It needs CIDR blocks to read, which is why it follows the calculator.

Traffic has reached your proxy; now the proxy reports on the service behind it. A 502 is an attempt that ended and a 504 is one that never did, and they need opposite fixes.

The cause list for the more common of the two. It starts from the proxy's error log, which records whether the upstream refused the connection, hung up, or answered with something unusable.

The proxy again, this time refusing the request itself instead of reporting on the service behind it. Reading which layer wrote the error page is the same skill as reading a 502.

Ends on trust again, now for TLS. A chain of signatures leading back to an authority you already trust answers the same question the host key answered in step two, and every HTTPS client asks it.

First because it draws the line the rest of the path keeps returning to: rebase rewrites commits, which is harmless on work only you have and trouble on anything others have pulled.

The first refusal you will meet, and a direct consequence of the previous step: the remote has commits yours is not built on. The fix is to bring them in, not to force.

The same refusal from the other end: two histories with no commit in common, usually because the repository was created on the host with its own first commit. It only makes sense once you know a merge starts from a shared commit.

Undoing comes after combining because the right tool depends on the line from step one: reset rewrites, revert adds. It is also where uncommitted work can be lost for good, with reset --hard.

The undo that does not exist. After reset and revert it is clear why deleting a committed secret leaves it reachable, in your history and in every clone already made.

Ends with the host stopping the push for you. Fixing it means rewriting commits you have not pushed yet, which is everything above at once, and replacing the credential if it is real.

First because everything else here follows from it: state maps blocks of code to real resources, and it is the only record of things the provider does not report back.

Who may write state, and the one command in this path that can corrupt it. The whole question is whether the run holding the lock is dead or still alive, which only matters once you know what state is.

Reality moving out from under the state, or a provider describing the same value in a different form. The two look identical in a plan and need opposite responses.

A saved plan is worked out against one version of state. If anything writes state before you apply it, Terraform refuses, and after the lock and drift steps it is clear why there is no flag to force it.

Now the language, because how instances are named decides what a plan does when a list changes: removing an item from the front of a count list rewrites every instance after it.

The error that comes with choosing for_each: every key must be known before apply. The fix the message suggests reads naturally once you know why instances need stable names.

Last because it is about the providers rather than state. The lock file pins their versions and belongs in version control next to the configuration; the error is the two disagreeing.

First because every other step uses the words: what you measure, the target you hold yourself to, and the contract, which should promise less than the target.

Turns a target into minutes. 99.9% over 30 days allows about 43 minutes of downtime, and seeing that number is what makes a target a decision rather than a slogan.

With a budget in hand the paging rule follows: page on what users feel, because a cause can look unusual while users are fine, and paging on causes is the route to alert fatigue.

The monitoring system failing on its own terms: a target too slow to answer is marked down. Worth meeting early, because a missed scrape leaves a gap in every graph and alert built on that target.

Health checks are signals too. The wrong one in the wrong place turns a slow start into a restart loop, which is a reliability problem the platform creates by itself.

The case the path builds to: every check passed and the application is broken. It shows why the measurement behind an SLO has to be what users experience, not what the platform reports.

What clients do when you fail. Retries without backoff and jitter add load to a service that is already struggling, so this belongs next to the failure it amplifies.

Last because it is where the earlier choices land on people: alerts on causes rather than symptoms show up here as a rotation nobody can sustain.