Questão de Arquitetura de Software — Sistemas Distribuídos — FGV 2026
Arquitetura de Software›Sistemas Distribuídos
Código
fg133772
Banca
FGV
Órgão
TJ-RJ
Ano
2026
Nível
Superior
Cargo
Analista Judiciário - Tecnologia da Informação - Analista de Infraestrutura de TIC
A equipe de SRE (Site Reliability Engineering) de um órgão público está definindo a estratégia de atualização de microsserviços críticos em seu cluster Kubernetes. O requisito de negócio estabelece que novas versões da aplicação não podem ser liberadas para todos os usuários simultaneamente devido ao risco de bugs não detectados em homologação.A estratégia escolhida deve permitir o direcionamento de uma pequena porcentagem do tráfego de produção (ex: 5%) para a nova versão, enquanto os 95% restantes continuam sendo atendidos pela versão estável. Se as métricas de latência e erro da nova versão forem satisfatórias, o tráfego é gradualmente migrado até atingir 100%; caso contrário, o tráfego é revertido instantaneamente.Essa estratégia de implantação, que frequentemente exige o uso de um Ingress Controller avançado ou de um Service Mesh para gerenciar o peso do tráfego independentemente do número de réplicas de pods, é denominada:
ARolling Update;
BRecreate Strategy;
CCanary Deployment;
DShadow Deployment;
EBlue-Green Deployment.
Revelar gabarito e comentário▾
GabaritoC — Canary Deployment;
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”.
Estratégias de implantação em Kubernetes
Gabarito: letra C. A descrição da questão — direcionar uma pequena porcentagem do tráfego (ex.: 5%) para a nova versão, monitorar métricas e, se satisfatórias, migrar gradualmente até 100%, ou reverter instantaneamente em caso de problemas — corresponde exatamente à definição de Canary Deployment. Essa estratégia exige mecanismos de roteamento como Ingress Controller avançado ou Service Mesh para controlar o peso do tráfego independentemente do número de réplicas.
A questão testa o conhecimento dos diferentes padrões de implantação em ambientes de microsserviços, especialmente os que minimizam risco em produção. Vamos analisar cada alternativa:
Estratégia
Descrição
Controle granular de tráfego (%)
Reversão instantânea
Adequação ao requisito
Rolling Update
Substitui pods gradualmente, sem controle de % de tráfego por versão
Não
Não
❌
Recreate Strategy
Destrói todos os pods antigos antes de criar os novos
Não
Não
❌
Canary Deployment
Direciona % específica de tráfego (ex.: 5%) para nova versão, monitora e migra ou reverte
Sim
Sim
✅
Shadow Deployment
Envia tráfego real para nova versão, mas descarta a resposta (sem expor usuário)
Não (tráfego espelhado)
Sim (sem impacto)
❌
Blue-Green Deployment
Mantém dois ambientes completos (azul/verde) e alterna todo o tráfego de uma vez
Não (migração total)
Sim
❌
Alternativa A — ❌ Incorreta
Rolling Update atualiza gradualmente os pods, substituindo versões antigas por novas sem interrupção total do serviço. Entretanto, o tráfego é distribuído igualmente entre os pods disponíveis, sem a capacidade de direcionar uma porcentagem específica (ex.: 5%) para a nova versão de forma seletiva. A atualização contínua não oferece o controle granular de tráfego descrito.
Alternativa B — ❌ Incorreta
Recreate Strategy consiste em destruir todos os pods da versão antiga e, em seguida, criar os pods da nova versão. Há um período de indisponibilidade, e o tráfego não é dividido entre versões. É o oposto do requisito de liberação controlada e reversão instantânea.
Alternativa C — ✅ Correta ⟵ GABARITO
Canary Deployment libera a nova versão para um subconjunto pequeno de usuários (ex.: 5%), enquanto a versão estável atende os 95% restantes. Com base em métricas de latência e erros, o tráfego é aumentado gradualmente ou revertido. O uso de Ingress Controller ou Service Mesh é comum para gerenciar o peso do tráfego por porcentagem, independentemente do número de réplicas.
Alternativa D — ❌ Incorreta
Shadow Deployment envia tráfego de produção para a nova versão em paralelo, mas sem impactar o usuário (a resposta da versão shadow é descartada). Serve para testar com tráfego real sem expor o usuário a riscos, mas não direciona tráfego de usuário real para a nova versão de forma gradual.
Alternativa E — ❌ Incorreta
Blue-Green Deployment mantém dois ambientes completos (azul e verde). O tráfego é alternado instantaneamente de um para outro (ou gradualmente com balanceamento), mas a mudança costuma ser de 0% a 100% em poucos passos, e não o controle fino de 5% com reversão automática descrito.
PEGA ESSA DICA!
Para identificar a estratégia na prova, foque nas palavras-chave: (1) porcentagem pequena de tráfego inicial, (2) monitoramento de métricas, (3) migração gradual ou reversão instantânea. Isso sempre aponta para Canary Deployment. As demais estratégias têm propósitos diferentes: Rolling Update = substituição gradual de pods; Recreate = parada total; Shadow = teste sem impacto; Blue-Green = troca de ambientes completos.