Keeping config entirely separate from app source is the way to go. Encrypted configs is a specific version of that general anti-pattern.
Encrypted configs (and configs in source code itself) seem like a good idea at first, "I don't have to configure anything and it works in prod!" but it also means you can't flip any switches or rotate config without pushing a new version.
This also makes it difficult to stand up a parallel environment, say for reproducing a defect, as the configs are expected to be baked internally. You can't just pull out the release build and run it in a different environment with one or two variables tweaked.
> We're doing encrypted secrets in config that get decrypt by aws kms on application startup and it's been working quite well for us.
Using KMS solves the problem of where do you keep the key that locks the configs but they should still be kept externally from the app code. Depending on the scale of how you're deploying that could be a local file, an external secrets server, or just a blob on S3 (accessible via EC2 IAM roles).