Analista em Computação/Ênfase em Programação de Sistemas na Tecnologia Microsoft
Uma aplicação ASP.NET Core será entregue em Kubernetes (K8s) da Empresa de Tecnologia e Informações da Previdência (Dataprev). Busca-se imagem final pequena e monitoramento de saúde nativo do cluster. Qual prática é a mais adequada?
APublicações self-contained, que exigem a imagem Software Development Kit (SDK) em produção, pois não executam corretamente em imagens apenas de runtime, mesmo quando incluem o runtime no publish.
BMulti-stage build, que aumenta o tamanho por introduzir camadas residuais do estágio de build.
CO HEALTHCHECK do Docker substitui a livenessProbe/readinessProbe do Kubernetes, tornando desnecessária a configuração de probes no nível do cluster.
DMulti-stage build aliado a liveness Probe/readinessProbe do Kubernetes, reduzindo a imagem final e expondo sinais de saúde ao orquestrador.
EImagens SDK, que são recomendadas em produção por conterem ferramentas de diagnóstico compilação just-in-time.
Revelar gabarito e comentário▾
GabaritoD — Multi-stage build aliado a liveness Probe/readinessProbe do Kubernetes, reduzindo a imagem final e expondo sinais de saúde ao orquestrador.
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”.
Práticas para ASP.NET Core em Kubernetes
Gabarito: letra D. A combinação de multi-stage build (para reduzir o tamanho da imagem final) com a configuração de probes do Kubernetes (liveness e readiness) atende aos dois requisitos: imagem pequena e monitoramento de saúde nativo do cluster.
ASP.NET Core em Kubernetes
1Requisitos
Imagem final pequena
Monitoramento nativo do cluster
2Prática adequada
Multi-stage build
Estágio de build: compila e publica
Estágio final: só artefatos em runtime
Reduz tamanho da imagem
Probes do Kubernetes
Liveness: reinicia pod se falhar
Readiness: tráfego só quando pronto
Monitoramento nativo do cluster
3Práticas inadequadas
Imagem SDK em produção
Grande e com ferramentas desnecessárias
HEALTHCHECK do Docker
Não substitui probes do K8s
Publicação self-contained com SDK
Funciona em runtime, não exige SDK
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Publicações self-contained incluem o runtime e podem executar em imagens base de runtime, não exigindo o SDK em produção. A afirmação é falsa: elas funcionam em imagens de runtime.
Alternativa B — ❌ Incorreta
Multi-stage build visa exatamente o oposto: eliminar camadas residuais do build, resultando em imagens menores. A alternativa inverte o efeito.
Alternativa C — ❌ Incorreta
O HEALTHCHECK do Docker não substitui as probes do Kubernetes. Embora ambos verifiquem saúde, o Kubernetes utiliza suas próprias probes (liveness, readiness, startup) para gerenciar o ciclo de vida dos pods. Configurar apenas o HEALTHCHECK não atende ao monitoramento do orquestrador.
Alternativa D — ✅ Correta ⟵ GABARITO
Multi-stage build: o estágio de build compila e publica a aplicação; o estágio final copia apenas os artefatos necessários para uma imagem de runtime, reduzindo drasticamente o tamanho. As probes do Kubernetes (liveness e readiness) são nativas do cluster e permitem que o K8s monitore e gerencie o pod, reiniciando-o se necessário.
Alternativa E — ❌ Incorreta
Imagens SDK são grandes e contêm ferramentas de desenvolvimento desnecessárias em produção. A recomendação é usar imagens de runtime, que são mais enxutas e seguras.
NÃO CAIA NESSA!
A banca tenta confundir o candidato ao sugerir que o Docker HEALTHCHECK substitui as probes do Kubernetes. Lembre-se: HEALTHCHECK é um recurso do Dockerfile, mas o Kubernetes não utiliza a saúde informada pelo Docker — ele faz suas próprias verificações periódicas via kubelet. Sempre configure ambas, se necessário.