APRENDER. PRATICAR. EVOLUIR.O objeto da revisão
Imagina uma mudança fictícia num serviço de processamento de fundos. Às 10:00, uma equipa revê um plano; às 10:15, outro commit chega ao diretório de execução. A pergunta operacional é qual das duas propostas será aplicada. No laboratório, terraform_data guarda apenas valores num state temporário. O plano contém approved-a, mas o ficheiro passa a working-b antes de apply. Ao receber o ficheiro guardado, a CLI aplica approved-a. Não interpreta o novo ficheiro como uma alteração adicional aprovada. A revisão deve identificar o artefacto efetivamente entregue à execução e o contexto que o produziu.
Mudança proposta depois da execução
Depois da aplicação guardada, o guião volta a planear com o ficheiro que contém working-b. Surge uma atualização pendente e detailed-exitcode devolve 2. A execução anterior pode ter sido correta relativamente ao seu plano, embora a configuração atual peça outra coisa. Regista separadamente a intenção aprovada e a intenção mais recente. Não transformes automaticamente o segundo plano numa continuação da primeira autorização. Numa pipeline, a decisão depende do processo definido para novas alterações, dos recursos afetados e das condições atuais. O exercício conserva o segundo plano sem o aplicar para tornar essa fronteira observável.
Integridade não assegura atualidade
Um segundo caso começa num state já criado. O guião guarda old.plan, executa uma alteração intermédia e tenta aplicar old.plan. O hash do plano continua igual. Contudo, a CLI rejeita-o com Saved plan is stale; o serial do state avançou dentro da mesma lineage. A rejeição deixa o ficheiro de state inalterado neste ensaio. Investiga a operação intermédia, confirma o objetivo atual e produz um novo plano para revisão. Repor um state antigo apenas para tentar fazer passar o plano não desfaz efeitos de infraestrutura e pode esconder a associação correta entre configuração e objetos.
O destino tem identidade própria
O laboratório cria dois diretórios independentes com a mesma configuração inicial. Cada um recebe o seu state local e uma lineage diferente. Copiar para o segundo diretório um plano feito no primeiro provoca rejeição por lineage diferente; o segundo state fica intacto. Esta observação mostra que nomes e valores semelhantes não estabelecem a mesma identidade de state. Em trabalho real, acrescenta backend, workspace, conta, região e permissões à identificação do destino. O exercício não contacta nenhum backend remoto e não demonstra que esses controlos estejam implementados numa pipeline. A decisão sobre o ambiente requer evidência própria.
A autorização precede o comando
Passar o plano guardado a apply é suficiente para a CLI executar sem pedir confirmação interativa. Isso não significa que exista uma aprovação de negócio, de segurança ou da janela de mudança. Esses controlos pertencem ao fluxo que entrega o artefacto. No ensaio, tentar acrescentar -var ao apply guardado é rejeitado antes de criar state: as decisões de planeamento já estão no ficheiro. Se uma entrada precisa de mudar, gera e revê outra proposta. Um recibo de aprovação útil associa identidade do plano, origem da configuração, destino, responsável, restrições e resultado esperado, segundo o processo da organização.
Interpretar o resultado e fechar a mudança
O guião observa os três resultados de plan com detailed-exitcode: 0 para ausência de alterações, 2 para alterações propostas e 1 para erro de configuração. Estes códigos servem caminhos diferentes no automatismo. Um código 2 não deve disparar uma aplicação automática sem a decisão prevista; um código 1 não é equivalente a um plano vazio. Mesmo depois de obter 0, o laboratório só sabe que o modelo local não propõe mudanças. A saúde da aplicação, a reconciliação funcional e a capacidade de suporte exigem verificações adicionais. No handover, identifica explicitamente quais foram realizadas e quais continuam pendentes.
# Run only in a new local terraform_data exercise directory.
terraform init -input=false
terraform plan -input=false -out=approved.plan
terraform show -no-color approved.plan
# Applying the saved file is treated as approval by the CLI.
terraform apply -input=false approved.plan
terraform plan -input=false -detailed-exitcode
# Interpret exit status: 0 no changes; 2 changes; 1 error.
O plano guarda approved-a; o ficheiro passa a working-b. A execução guardada aplica approved-a e o plano seguinte propõe working-b.
Armadilhas comuns
Confundir o commit atual com o plano guardado; interpretar um hash como autorização; tentar ultrapassar uma rejeição de state restaurando uma cópia antiga.
Tópicos relacionados: Revisão de planos e aprovação · State e recuperação operacional
A integridade do ficheiro e a validade da execução respondem a perguntas diferentes. Confirma ambas antes da mudança.
Referência: Saved-plan execution and planning options · Terraform v1.16 concepts; official documentation consulted 2026-09-30; provider and backend capabilities must be confirmed