Target e fecho das dependências
O exemplo declara source, consumer e independent. Consumer usa o output de source; independent não participa nessa relação. Ao planear com target em consumer, a CLI inclui source e consumer. O aviso assinala o uso de targeting. A intervenção não se limita ao nome passado pelo operador, porque precisa de incluir dependências. Antes de autorizar uma operação semelhante, lê todos os endereços e ações realmente presentes no plano. Na situação fictícia de suporte, o facto de o pedido mencionar uma aplicação não prova que só essa aplicação será afetada. Documenta os componentes necessários e o motivo da seleção excecional.
Êxito local com trabalho por fazer
O apply guardado do plano limitado termina com código 0 e um aviso de possível incompletude. O state contém source e consumer. O guião gera então um plano sem target: independent ainda precisa de ser criado. Esta sequência separa o sucesso da operação escolhida da convergência da configuração inteira. Num incidente, mantém visível o trabalho que ficou de fora e define quem o revê. A documentação reserva targeting para situações excecionais; não deve ser o mecanismo habitual para esconder diferenças persistentes. Para equipas com fronteiras de operação independentes, avalia uma separação de configurações e contratos de dependência devidamente desenhados.
Valores que ainda não existem no plano
O recurso terraform_data do exercício recebe um input conhecido, mas o seu output permanece desconhecido até à aplicação inicial. No JSON do plano, after omite output e after_unknown assinala output como true. Um consumidor que leia apenas after pode confundir informação pendente com ausência definitiva. A combinação das estruturas permite conservar essa distinção. Quando uma regra depende de um valor ainda desconhecido, regista a decisão pendente e o ponto em que será obtida evidência suficiente. Não inventes um valor vazio para conseguir um resultado favorável. A observação local também não mede quando um serviço remoto estará efetivamente pronto.
Sensibilidade e exposição do artefacto
O laboratório usa um marcador fictício, explicitamente sem credenciais, numa variável sensitive. A apresentação normal do plano oculta esse valor; show -json devolve-o juntamente com a indicação de sensibilidade. Após apply, a representação JSON do state também contém o marcador. A máscara serve para orientar a apresentação, não para eliminar o valor do artefacto. Ao construir um relatório, seleciona os campos necessários e respeita as marcações antes de os apresentar. Define acesso, retenção e destino dos planos e JSON produzidos. Não assumas que o log é seguro porque a interface humana mostrou apenas sensitive value.
Ações compostas e motivo da substituição
Outro caso mantém o input e pede explicitamente replace para terraform_data.release. O plano apresenta ações delete e create, com o motivo replace_by_request. O guião guarda essa proposta sem a executar. A ausência de diferença no valor de entrada não exclui uma substituição pedida pelo operador. Uma regra que só procura a ação isolada delete pode perder substituições representadas por uma sequência. Analisa os elementos do conjunto de ações e a ordem quando relevante. O motivo acrescenta contexto, mas um código desconhecido não autoriza ignorar ações destrutivas. Para recursos reais, capacidade, dados e continuidade precisam de análise específica.
Evidência que pode ser entregue ao suporte
Entrega uma sequência legível: contexto e destino, plano revisto, ações incluídas, restrições, resultado e diferenças ainda pendentes. Se o plano foi limitado, junta a reconciliação posterior sem target. Se existem valores desconhecidos, indica como serão confirmados; se existem dados sensíveis, controla o relatório que os transporta. O laboratório prova comportamento da CLI 1.16.5 com state local e terraform_data em operações sequenciais. Não prova locking concorrente, um backend remoto, uma pipeline de aprovação ou recuperação de infraestrutura cloud. Num workshop humano, pede ao participante que interprete a evidência e justifique a decisão de continuar ou suspender.
# In the isolated workshop, consumer references source.output.
terraform plan -input=false -target=terraform_data.consumer -out=target.plan
terraform show -no-color target.plan
terraform apply -input=false target.plan
# Reconcile the complete configuration after the exceptional operation.
terraform plan -input=false -detailed-exitcode
# Treat machine-readable output as potentially sensitive.
terraform show -json target.plan
Um plano com target inclui consumer e a sua dependência source. Depois do apply bem-sucedido, um plano completo ainda propõe criar independent.
Armadilhas comuns
Tratar target como fronteira sem dependências; publicar JSON sensível em logs; interpretar unknown como vazio; aceitar apenas a contagem final.
Tópicos relacionados: Revisão de planos e aprovação · State e recuperação operacional
O plano tem âmbito e informação parcial. Lê ações, dependências e máscaras de dados e confirma o que ficou fora da execução.
Referência: JSON format, unknown values and change representation · Terraform v1.16 concepts; official documentation consulted 2026-09-30; provider and backend capabilities must be confirmed