Pular para o conteúdo principal

Questão de Programação — .Net — FUNDATEC 2025

Programação.Net
Código
qg475004
Banca
FUNDATEC
Órgão
PROCERGS
Ano
2025
Nível
Superior
Cargo
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?
  1. 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.
  2. BMulti-stage build, que aumenta o tamanho por introduzir camadas residuais do estágio de build.
  3. CO HEALTHCHECK do Docker substitui a livenessProbe/readinessProbe do Kubernetes, tornando desnecessária a configuração de probes no nível do cluster.
  4. DMulti-stage build aliado a liveness Probe/readinessProbe do Kubernetes, reduzindo a imagem final e expondo sinais de saúde ao orquestrador.
  5. 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.

Gabarito: letra D.

Link permanente: /questoes/qg475004