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
-
Quote your strings —
country: "NO"always works. It's the safest habit. - 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.
- 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)
