Nobody Memorizes YAML

I saw a question on Reddit the other day that took me back to when I was starting out. Someone learning DevOps asked: “Do engineers actually memorize YAML? Or is it normal to check docs?”

Short answer: nobody memorizes YAML. If someone tells you they write K8s manifests from memory, they’re either lying or they’ve written the same deployment spec so many times it just stuck. That’s not memorization. That’s muscle memory from repetition.

The longer answer is more interesting. Because the question isn’t really about YAML. It’s about what you actually need to carry in your head versus what you can safely look up.

What I actually have memorized

After years of writing YAML for Kubernetes, Ansible, GitHub Actions… plus Terraform (okay, HCL, but same energy)… here’s what I can do from memory:

The basic structure of a K8s Deployment. apiVersion, kind, metadata, spec. I know where containers goes. I know replicas is under spec. I know there’s a template with its own metadata and spec inside. But ask me the exact field name for setting CPU limits? I’m opening the docs. Every time.

A simple GitHub Actions workflow. on, jobs, steps, run. The shape of it is in my head. But the exact syntax for actions/checkout@v4 inputs? Looked up. The if condition syntax for skipping steps? Looked up. Whether it’s env or environment for that one specific thing? Looked up.

The Ansible playbook skeleton. hosts, tasks, name, module name, module params. But the exact parameter names for the aws_ec2 module? Come on. There are hundreds of modules. Nobody knows all of them.

The pattern here is simple. I know the shape. I know the structure. I know what’s possible. The exact field names and options? That’s what docs are for.

What actually matters

There’s a comment from that Reddit thread that stuck with me. Someone said memorization is a “parlour trick.” The real value is knowing what you can do and why you’re doing it. That’s exactly right.

I’ve debugged enough production issues to know the difference between someone who understands what they configured versus someone who copied a YAML block until the pipeline stopped complaining.

A real example. I once spent two hours tracking down why a service kept getting OOMKilled in production. The manifest looked fine. Someone had set resources.limits.memory to 256Mi because that’s what the example they copied had. Nobody checked whether the actual app needed more than that. The config was valid YAML. It was correct syntax. It just didn’t match reality.

That’s the gap. You can memorize every field in a Deployment spec and still misconfigure the thing because you don’t understand what the values mean for your specific service.

On the other hand, if you understand that K8s will kill your pod when it exceeds its memory limit, you’ll know to actually measure your app’s memory usage before setting that number. You don’t need to remember the field name. You just need to know the concept exists and check the docs for the syntax.

The stuff that actually sticks

Here’s what happens in practice. You use something enough and it sticks on its own. No flashcards needed.

I’ve written ln -s probably thousands of times. I still get the argument order wrong sometimes. ln -s <target> <link>? Or ln -s <link> <target>? I check. Every few months. It’s been years.

Same energy with YAML. The stuff you touch daily becomes automatic. The stuff you touch twice a year, you look up twice a year. That’s fine. That’s how brains work.

One thing that helped me early on: I keep a personal repo of templates. K8s manifests, CI pipeline configs, Terraform modules, Ansible playbooks. When I need something new, I don’t start from scratch. I grab the closest template and modify it. Half the time I wrote the template myself months ago and forgot what half the fields do.

kubectl explain is also a lifesaver. kubectl explain deployment.spec.template.spec.containers gives you the field docs right in your terminal. No browser needed. Wish more tools had something like that.

Interviews that test memorization are broken

The Reddit thread had some horror stories about interviews that disable copy-paste and make you write Terraform from scratch in a text editor. No autocomplete. No docs.

I don’t know what that tests. Certainly not how anyone actually works. I’ve never seen a production environment where someone said “sorry, can’t use the docs today, we’re doing this from memory.”

If I’m interviewing someone, I care about three things. Can they explain what they’re trying to build? Do they know what options exist? Can they figure out the syntax when they need to? That third one means being comfortable with docs, not avoiding them.

The best technical interviews I’ve seen give you a real problem and let you use whatever tools you’d normally use. Google, docs, even AI. Because the value isn’t in typing the right YAML key from memory. It’s in knowing which key you need in the first place.

The school mindset

There was another comment in that thread that hit close to home. Someone pointed out that school trains you to think opening the book is cheating. So when you start working and you have to look something up, it feels wrong. Like you should already know this.

I felt that when I started. Every time I Googled a kubectl flag or opened the Ansible docs mid-task, there was this small voice going “shouldn’t you know this by now?”

No. That voice is wrong. Reading the docs isn’t a sign of weakness. It’s the actual job. The person who checks the docs writes correct configs. The person who goes from memory writes configs that are mostly correct, which in production usually means wrong in the way that’s hardest to debug.

What to focus on instead

If you’re learning DevOps and feeling overwhelmed by the amount of YAML you’re seeing… relax. Here’s what’s worth your time:

Understand the tool’s model. Before memorizing K8s YAML fields, understand what a Deployment actually does. Why does it create ReplicaSets? What happens during a rolling update? Why would you pick Recreate strategy instead? Once you get the model, the YAML is just how you express it.

Learn to read YAML before you write it. When something breaks, your first job is reading the existing config and understanding what it does. That’s harder than writing new YAML and more valuable.

Build a personal reference. Keep a repo of working examples. When you need something similar, copy and modify. This is what everyone does. The people who seem fast aren’t typing from memory. They have good templates.

Get comfortable with docs. Bookmark kubernetes.io/docs. Learn kubectl explain. Know where the GitHub Actions workflow syntax reference lives. Being fast at finding the answer beats having the answer memorized. Especially when the answer changes between API versions.

Set up your editor. VS Code with the right YAML extensions and schema validation catches most syntax issues before you even run anything. A linter that knows the K8s schema will tell you when you misspell containerPort or put a field at the wrong indentation level. Let the tools do the memorization.

The real skill

Nobody wakes up one morning with all of Kubernetes memorized. The stuff you use daily becomes second nature. The rest lives in docs and templates. That’s not a limitation. That’s how every experienced engineer I’ve worked with actually operates.

The real skill is knowing what’s possible, understanding why you’re doing it, and being fast at finding the exact syntax when you need it. Everything else is just repetition doing its thing over time.