Are you making the argument that they should have a default API route? I don't think that's very common.

I'm making the argument that I wouldn't rely on an API endpoint to serve up the secrets that enable my application to work. Imagine a network outage or endpoint failure when the app just happens to be redeployed.

I think it depends on the API - we do this with AWS Secret Managers. I haven't seen it fail but if did it would only effect new instances coming into service so I think we'd have to be pretty unlucky for it to have a noticeable impact.

This wasn’t an AWS Secrets Manager example, and yes, there’s a guy named Murphy who wrote a law about this kind of thing.

It's true that anything that can go wrong will go wrong but I wouldn't use that as a maxim to direct designs - risk is one trade-off and it's significance varies.

Nah, we’ve been doing this long enough that handling network failure is just the default assumption now, we should be designing and coding for it, by default.

Where should secrets come from then? Burn them into the deployable artifact??? Place them on the host filesystem in perpetuity???

That's a whole category of software that makes large systems work: etcd, Zookeeper, HashiCorp Vault, etc.

Yes! All built with redundancy in mind.

https://etcd.io/docs/v3.3/op-guide/

https://zookeeper.apache.org/doc/r3.9.3/zookeeperStarted.htm...

https://developer.hashicorp.com/vault/tutorials/day-one-raft