Questão de Engenharia de Software — Gerência de Configuração — FGV 2026
Engenharia de Software›Gerência de Configuração
Código
fg133760
Banca
FGV
Órgão
TJ-RJ
Ano
2026
Nível
Superior
Cargo
Analista Judiciário - Tecnologia da Informação - Analista de Infraestrutura de TIC
O TJRJ adota práticas GitOps, guardando sua infraestrutura como código no repositório Git repo. O código em repo gerencia o cluster Kubernetes K. A equipe de analistas do tribunal configurou em K um operador de GitOps MG que tem acesso ao repositório repo.Em um fluxo GitOps padrão, é esperado que o operador MG:
Aenfileire os efeitos das alterações detectadas em repo e aguarde o disparo de um único comando apply pelo admin;
Breconcilie o estado atual do cluster K com o estado desejado, definido em repo, sem reverter para o último estado saudável em caso de falha;
Creconcilie o estado atual do cluster K com o estado desejado, definido em repo, revertendo para o último estado saudável em caso de falha;
Dreconcilie o estado atual de repo com o estado desejado, definido em cluster K, revertendo para o último estado saudável em caso de falha;
Eenfileire os efeitos das alterações detectadas em repo e realize testes automatizados de integração com o estado atual de cluster K, notificando o resultado via service admin.
Revelar gabarito e comentário▾
GabaritoB — reconcilie o estado atual do cluster K com o estado desejado, definido em repo, sem reverter para o último estado saudável em caso de falha;
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
GitOps e Reconciliação Contínua
Gabarito: letra B. Em um fluxo GitOps padrão, o operador (MG) reconcilia continuamente o estado atual do cluster Kubernetes (K) com o estado desejado declarado no repositório Git (repo). Ele não reverte automaticamente para o último estado saudável em caso de falha; essa reversão, quando existe, é uma funcionalidade opcional de algumas ferramentas, não o comportamento padrão. O conceito central do GitOps é a abordagem declarativa, onde o estado desejado está no Git e o operador atua para convergir o cluster a esse estado.
A banca testa a compreensão do fluxo básico do GitOps, especialmente a direção da reconciliação (repositório → cluster) e a ausência de reversão automática como comportamento padrão.
Fluxo GitOps padrão: Estado desejado (Repositório Git (repo)); Operador (MG) (Ação contínua e autônoma (pull), Reconcilia cluster → estado desejado, Não reverte automaticamente, Não aguarda comando manual); Estado atual (Cluster Kubernetes (K))
Alternativa A — ❌ Incorreta
Afirma que o operador "enfileira os efeitos e aguarda o disparo de um único comando apply pelo admin". Isso descreve um modelo push, não o GitOps. No GitOps, o operador age de forma contínua e autônoma (pull), sem necessidade de comando manual para aplicar cada alteração.
Alternativa B — ✅ Correta ⟵ GABARITO
O operador reconcilia o estado atual do cluster com o estado desejado em repo, sem reverter automaticamente para o último estado saudável em caso de falha. Essa é a descrição precisa do comportamento padrão de operadores GitOps como Argo CD e Flux.
Alternativa C — ❌ Incorreta
Afirma que o operador "reverte para o último estado saudável em caso de falha". Embora algumas configurações possam implementar rollbacks automáticos, isso não é parte do fluxo GitOps padrão. O comportamento default é manter o cluster no estado atual (que pode ser o estado saudável anterior) e reportar a falha, exigindo intervenção manual ou correção no repositório.
Alternativa D — ❌ Incorreta
Inverte a direção da reconciliação: "reconcilie o estado atual de repo com o estado desejado, definido em cluster K". No GitOps, o repositório define o estado desejado, e o operador ajusta o cluster para corresponder a ele, não o contrário.
Alternativa E — ❌ Incorreta
Alega que o operador "enfileira os efeitos e realiza testes automatizados de integração, notificando o resultado". Isso se assemelha mais a um pipeline de CI/CD tradicional, não ao GitOps. O operador GitOps não enfileira nem executa testes; ele apenas reconcilia o estado declarado.
NÃO CAIA NESSA!
A banca explora a confusão sobre reversão automática. Muitos candidatos associam GitOps a rollbacks automáticos, mas o padrão é não reverter. A reversão, quando ocorre, é uma decisão de design de ferramenta específica, não do princípio GitOps.