¿Cómo gestionas el estado de Terraform en un equipo y qué haces con la deriva?

Usa estado remoto con bloqueo, como S3 más DynamoDB o un backend gestionado, dividido en un archivo de estado por entorno y por radio de impacto, y nunca subas el estado a git porque guarda secretos en texto plano. Para la deriva, ejecuta plan de forma programada y alerta ante cualquier diff no vacío, haz que todos los cambios pasen por CI en vez de por la consola, y usa bloques import o removed a propósito en lugar de editar el estado a mano.

Backend remoto con bloqueo, siempre, para que dos apply no puedan competir. Más allá de eso, la gran decisión es cómo lo divides. Un único archivo de estado gigante significa que un plan tarda quince minutos y que cada cambio pone todo en riesgo, así que divido por entorno y luego por radio de impacto: la red separada del clúster, el clúster separado de los recursos de aplicación, y lo compartido se trae con salidas de estado remoto o data sources en vez de un monolito. El estado además contiene secretos en texto plano, cosa que la gente olvida, así que vive en un bucket cifrado con IAM estricto y versionado activado. Para la deriva ejecuto terraform plan cada noche en CI y alerto si el diff no está vacío. Eso encontró un grupo de seguridad que alguien había ampliado a mano durante un incidente, que es exactamente el caso que quieres cazar. No prohíbo el acceso a la consola en emergencias, pero la regla es que abres un pull request ese mismo día para codificar lo que hiciste, y el plan nocturno es lo que lo hace cumplir.