I had a talk proposal about this; config *is* code, this should come as no surprise to people using config management with the mantra "configuration as code". Surprise, the UTM theorem informs us that it is in fact code.
Your config changes the behaviour of your program -- it's a very stunted interpreter. The YAML or .ini or plain text you give is just a really bad programming language -- I want to say they're type 2 or 3 on the chomsky hierarchy but my knowledge here is weak.
They're also terrible because while your program is written in a language with a compiler that has error messages, linting, formatters, step debugging tools, your config typically does not. YAML isn't even formally defined!
This is not about YAML. Every application that has a config has this problem, and the good ones build config checkers. puppet parser test, apachectl configtest, and so on. Everyone ends up reimplementing the semantic checker. (It's not just good enough to pass a parse test.)
If you don't have this, you end up building it, because deploying a broken config file is equivalent to pushing code to production without compiling it first.
If you think that a common config language like YAML is good because it has a linter, you're not thinking about the effects in the program that the config controls. It's lit up or disabled certain codepaths in the binary, those features and parameters.
Config pushes need to be treated with at least the same care as you do with program binaries, and I argue more because unit testing config is Difficult without the compiler. You need integration tests.
You need to do canaried and staged rollouts of config changes because the only good place to test your config change is in the theatre of production, in the face of the actual users exercising the code paths enabled by your config. Global synchronised config change = outage.
For this reason, deploy features disabled and release config enabling them on a separate schedule. Package up config just as you do for binaries, in a nice little hermetic, transitive closure.
In summary,
