Questão de Sistemas Operacionais — Geral — INSTITUTO AOCP 2025
Sistemas Operacionais›Geral
Código
qa701195
Banca
INSTITUTO AOCP
Órgão
TRE TO
Ano
2025
Cargo
TJ
Em um ambiente de desenvolvimento DevOps, um administrador está configurando uma pipeline CI/CD para uma aplicação conteinerizada que será implantada em um cluster Kubernetes. O objetivo é minimizar o tamanho da imagem final do Docker, aproveitando dependências pré-compiladas de uma imagem base. Qual instrução principal em um Dockerfile deve ser utilizada para implementar uma construção em múltiplos estágios (multi-stage build), garantindo que apenas os artefatos essenciais sejam incluídos na imagem final?
ARUN --mount para gerenciar dependências de rede em tempo de construção.
BFROM ... AS combinado com COPY --from para separar estágios de build e runtime.
CEXPOSE para otimizar a comunicação entre contêineres no cluster.
DCMD com testes automatizados para validar a aplicação antes da implantação.
EHEALTHCHECK para monitorar o desempenho do contêiner em produção.
Revelar gabarito e comentário▾
GabaritoB — FROM ... AS combinado com COPY --from para separar estágios de build e runtime.
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”.
Multi-stage build no Docker
Gabarito: letra B. A construção em múltiplos estágios (multi-stage build) é implementada no Dockerfile pela combinação da instrução FROM ... AS (que nomeia cada estágio) com COPY --from (que copia artefatos de um estágio anterior para o estágio final), garantindo que apenas os artefatos essenciais sejam incluídos na imagem final. Essa é a técnica padrão para reduzir o tamanho da imagem, separando o ambiente de build do ambiente de runtime.
O multi-stage build é uma funcionalidade do Docker que permite usar múltiplas instruções FROM em um mesmo Dockerfile, cada uma iniciando um novo estágio de construção. Cada estágio pode ser nomeado com a sintaxe FROM <imagem> AS <nome>, e o estágio final (o último FROM) é o que define a imagem resultante. Para copiar arquivos de um estágio anterior, utiliza-se COPY --from=<nome> <caminho_origem> <caminho_destino>. Dessa forma, é possível, por exemplo, compilar uma aplicação em um estágio com todas as ferramentas de build (como compiladores e dependências de desenvolvimento) e, no estágio final, copiar apenas o binário compilado para uma imagem base enxuta (como alpine ou distroless), descartando todo o ambiente de build.
A principal vantagem é a redução drástica do tamanho da imagem final, pois ela contém apenas o necessário para executar a aplicação, sem as ferramentas e arquivos temporários usados durante a compilação. Isso também melhora a segurança, reduzindo a superfície de ataque, e acelera o pull e o deploy da imagem. O multi-stage build é amplamente utilizado em pipelines CI/CD, especialmente em ambientes Kubernetes, onde imagens menores são preferíveis por questões de desempenho e armazenamento.
É importante distinguir o multi-stage build de outras instruções do Dockerfile. RUN --mount é usado para montar caches ou segredos durante o build, mas não separa estágios. EXPOSE apenas documenta portas, não otimiza comunicação. CMD define o comando padrão de execução, não valida testes. HEALTHCHECK configura a verificação de saúde do contêiner em execução, não o tamanho da imagem. A pegadinha da banca está em associar RUN --mount a dependências de rede, quando na verdade o multi-stage build é a técnica correta para minimizar a imagem final.
Guarde o par FROM ... AS + COPY --from como a assinatura do multi-stage build: é exatamente essa combinação que as alternativas tentam confundir com outras instruções do Dockerfile.
1FROM ... AS (nomeia estágio)
2Build com ferramentas
3COPY --from (artefato)
4Imagem final enxuta
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
RUN --mount é uma instrução avançada do Dockerfile usada para montar caches de build (como --mount=type=cache) ou segredos (--mount=type=secret) durante a construção, otimizando o processo de build, mas não separa estágios nem reduz o tamanho da imagem final. A alternativa confunde a otimização de dependências de rede com a técnica de multi-stage build.
Alternativa B — ✅ Correta ⟵ GABARITO
A combinação FROM ... AS (para nomear estágios) com COPY --from (para copiar artefatos entre estágios) é exatamente o que implementa o multi-stage build. O estágio final herda apenas os arquivos copiados, descartando o restante, o que minimiza a imagem final. É a resposta direta ao enunciado.
Alternativa C — ❌ Incorreta
EXPOSE apenas informa ao Docker que o contêiner escutará em uma porta específica em tempo de execução. Não tem relação com otimização de comunicação entre contêineres nem com o tamanho da imagem. A comunicação entre contêineres no Kubernetes é gerenciada por serviços e redes, não pela instrução EXPOSE.
Alternativa D — ❌ Incorreta
CMD define o comando padrão a ser executado quando o contêiner inicia. Não executa testes automatizados durante o build nem valida a aplicação antes da implantação. Testes em pipelines CI/CD são normalmente executados como etapas separadas, não via CMD.
Alternativa E — ❌ Incorreta
HEALTHCHECK configura um comando para verificar a saúde do contêiner em execução, permitindo que o Kubernetes reinicie contêineres com falha. Não tem relação com o tamanho da imagem nem com a construção em múltiplos estágios.
NÃO CAIA NESSA!
A banca tenta confundir o candidato associando RUN --mount a dependências de rede, quando na verdade o multi-stage build é a técnica correta para minimizar a imagem final. Lembre-se: RUN --mount é para cache/segredos no build, não para separar estágios. Com treino, você identifica essa troca de longe 💪.