That time YAML silently broke your config because of Norway

A colleague pinged me last week with a config issue that had him chasing his tail for an afternoon. Turns out he was setting country: NO in a YAML file, expecting it to mean Norway. YAML thought he meant boolean false.

The Problem

YAML 1.1 treats these unquoted strings as booleans:

• yes, no, on, off, true, false
• Case-insensitive variants work too

So if you have:

database:
  country: NO
  enabled: true

YAML parsers will often read country: NO as country: false. Your application starts, the config loads, and nobody gets an error — it just silently does the wrong thing.

This has been documented for years. It bit DoorDash. It's been in Kubernetes manifests. It's in CI configs, Terraform variables, GitHub Actions, Helm charts.

Why It Matters in Practice

You won't see a crash. Your app just reads the wrong value. The country code field becomes a boolean, silently coerces to something unexpected, and the behavior diverges from what you intended. Debugging this is annoying because there's no error — just wrong behavior.

What Helps

1. Quote your strings — country: "NO" always works. It's the safest habit.
2. Use KYAML — The SIG CLI KEP 5295 introduces a strict YAML subset that quotes strings, braces maps, and brackets lists. No more ambiguity about whether whitespace or capitalization matters.
3. Lint your YAML — Tools like yamllint can catch some of these issues, though they won't catch semantic boolean confusion without schema awareness.

The Fix in Practice

If you're writing config that ships to others, get in the habit of quoting anything that could be misinterpreted:

example:
  country: "NO"   # quoted - will stay a string
  flag: false     # boolean - this is intentional
  message: "yes" # quoted - stays the string "yes", not boolean

It's a small discipline that prevents a class of silent failures that are otherwise hard to track down.

---

Source: DevOps'ish #322 (SIG CLI, KEP 5295)