Questão de Engenharia de Software — Desenvolvimento de Software — FGV 2024
Engenharia de Software›Desenvolvimento de Software
Código
fg101504
Banca
FGV
Órgão
TRF - 1ª REGIÃO
Ano
2024
Nível
Superior
Cargo
Analista Judiciário - Área Apoio Especializado - Especialidade: Tecnologia da Informação
A analista Dalva administra o cluster de Kubernetes do TRF1. Dalva precisa adicionar ao Kubernetes novas condições de prontidão customizadas para o Pod A. As novas condições devem ser atendidas para o Kubernetes elevar a condição do Pod A ao status Ready.Dalva deve adicionar as novas condições de prontidão ao manifesto do Pod A, especificamente no elemento:
AlifecycleConfig;
BreadinessGates;
CcontainerStatuses;
DlifecycleConditions;
EreadinessConditions.
Revelar gabarito e comentário▾
GabaritoB — readinessGates;
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”.
Kubernetes: Readiness Gates
Gabarito: letra B. A adição de condições de prontidão customizadas ao Pod é feita no campo readinessGates do manifesto. Esse campo permite definir condições adicionais que o Pod deve atender para ser considerado Ready, além das sondas de prontidão dos containers. As demais alternativas não correspondem a campos válidos para essa finalidade.
O Kubernetes disponibiliza o campo readinessGates na especificação do Pod (spec.readinessGates), que é uma lista de PodReadinessGate. Cada gate especifica uma condição que deve ser satisfeita para que o Pod seja considerado pronto. Isso é útil para integrações com controladores externos ou para lógicas de prontidão personalizadas.
Readiness Gates (Kubernetes): O que é (Campo spec.readinessGates, Lista de PodReadinessGate, Condições customizadas de prontidão); Como funciona (Sondas dos containers, Gates adicionais, Tudo satisfeito → Pod Ready); Para que serve (Integração com controladores externos, Lógica de prontidão personalizada); Distratores comuns (readinessConditions ❌ (não existe), lifecycleConfig ❌ (não existe), containerStatuses ❌ (só leitura))
Alternativa A — ❌ Incorreta
lifecycleConfig não é um campo padrão no manifesto de Pod. O Kubernetes possui lifecycle no container para hooks como postStart e preStop, mas não lifecycleConfig para condições de prontidão.
Alternativa B — ✅ Correta ⟵ GABARITO
readinessGates é o campo correto para adicionar novas condições de prontidão customizadas no Pod. Ele permite que o administrador defina condições adicionais que, junto com as sondas de prontidão dos containers, determinam se o Pod está Ready.
Alternativa C — ❌ Incorreta
containerStatuses é um campo de status do Pod, somente leitura, que reflete o estado atual dos containers. Não é usado para configurar novas condições de prontidão.
Alternativa D — ❌ Incorreta
lifecycleConditions não existe como campo no Kubernetes. Pode haver confusão com conditions no status do Pod, mas não é um campo de configuração.
Alternativa E — ❌ Incorreta
readinessConditions não é o nome correto. O termo exato é readinessGates. A banca trocou intencionalmente o nome para testar o conhecimento específico.
NÃO CAIA NESSA!
A banca utiliza readinessConditions como distrator, que não é um campo do Kubernetes. O candidato que conhece superficialmente pode confundir com readinessProbe, mas para condições customizadas o campo é readinessGates. Lembre-se: gates, não conditions.