Como funciona o state do Terraform, e como você o gerencia em um time?

O state é o registro do Terraform de quais recursos reais correspondem a quais endereços de configuração, mais atributos em cache que ele usa para calcular um plan. Para um time ele precisa viver em um backend remoto com locking, como o S3 com suporte nativo a lockfile ou um backend gerenciado, para que dois applies não rodem ao mesmo tempo. Nunca faça commit dele no git, já que ele guarda segredos em texto puro, e divida por raio de impacto em vez de manter um arquivo gigante.

O state é o mapa entre o que eu escrevi em código e o que de fato existe no provedor, indexado por endereço de recurso, mais um cache de atributos para o plan não precisar ler tudo do zero. Em um time ele vai para um backend remoto com locking, para que duas pessoas rodando apply ao mesmo tempo não consigam corrompê-lo. O que surpreende as pessoas é que o state contém os atributos dos recursos literalmente, então senhas de banco e chaves geradas ficam ali em texto puro; isso significa que o bucket é criptografado, versionado e restrito à role do pipeline, não legível por todo mundo. Sobre organização, eu divido por raio de impacto e por taxa de mudança. Rede e contas mudam raramente e ganham o seu próprio state, cada serviço ou ambiente ganha o dele, e eles leem uns dos outros via data sources ou outputs publicados em vez de um módulo raiz segurando tudo. O motivo prático é que um arquivo de state com quinhentos recursos deixa todo plan lento e todo erro enorme. Para recuperação eu conto com versionamento do bucket mais state mv e import, em vez de editar o arquivo na mão.