Na configuração de um ambiente de desenvolvimento para um novo projeto, é necessário definir variáveis de ambiente específicas a fim de garantir que a aplicação funcione corretamente em diferentes ambientes (desenvolvimento, teste e produção). Para isso, decidiu-se, utilizando o Docker, criar um contêiner e definir as variáveis de ambiente necessárias. Com base na situação hipotética apresentada, julgue o item a seguir, relativo às práticas DevOps. Na situação apresentada, é necessário adicionar uma nova dependência à aplicação e, então, modificar diretamente a imagem Docker já criada.
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoE — Errado
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”.
Docker: Imagens Imutáveis e o Ciclo de Vida do Contêiner
Gabarito: letra E (ERRADO). A afirmação está incorreta porque, no Docker, as imagens são imutáveis: não se "modifica diretamente" uma imagem já criada. Para adicionar uma nova dependência, o fluxo correto é alterar o Dockerfile, reconstruir a imagem com docker build e, então, recriar o contêiner a partir da nova imagem — nunca editar a imagem existente.
O Docker é uma plataforma de virtualização de nível de sistema operacional que empacota aplicações e suas dependências em contêineres isolados, que compartilham o kernel do host. A imagem Docker é um modelo somente-leitura que define o sistema de arquivos, as bibliotecas e as configurações do contêiner. Quando você executa docker run, o Docker cria uma camada de escrita temporária sobre a imagem — é essa camada que permite ao contêiner gravar arquivos durante sua execução. Porém, essa camada é efêmera: ao remover o contêiner, tudo que foi escrito nela se perde. A imagem original permanece intacta.
Para adicionar uma dependência, o processo correto é:
Editar o Dockerfile — adicionar a instrução que instala a dependência (por exemplo, RUN apt-get install ... ou RUN pip install ...).
Reconstruir a imagem — executar docker build -t minha-imagem . para gerar uma nova imagem com a dependência.
Recriar o contêiner — parar e remover o contêiner antigo (docker stop e docker rm) e executar docker run novamente com a nova imagem.
Essa prática é fundamental no DevOps: as imagens são versionadas e imutáveis, garantindo reprodutibilidade e consistência entre ambientes. Modificar diretamente uma imagem quebraria essa garantia e é uma prática desaconselhada.
A pegadinha da banca está em sugerir que a imagem pode ser "modificada diretamente", como se fosse um arquivo editável. Na verdade, a imagem é um artefato imutável; qualquer alteração exige a criação de uma nova imagem a partir do Dockerfile. O contêiner, por sua vez, é a instância executável da imagem — ele pode ser iniciado, parado e removido, mas não é o local para persistir alterações de configuração.
Guarde essa distinção: imagem = modelo imutável; contêiner = instância efêmera. É exatamente essa fronteira que a questão explora.
1Editar Dockerfile
2docker build (nova imagem)
3Parar/remover contêiner antigo
4docker run (novo contêiner)
LEVEL · soulevel.com.br
Item — ❌ ERRADO
A afirmação diz que "é necessário modificar diretamente a imagem Docker já criada". Isso está errado porque as imagens Docker são imutáveis por design. A forma correta de adicionar uma dependência é alterar o Dockerfile e reconstruir a imagem, gerando uma nova versão. O contêiner, por sua vez, deve ser recriado a partir dessa nova imagem. Modificar a imagem diretamente não é um procedimento suportado pelo Docker — a imagem é um artefato somente-leitura.
NÃO CAIA NESSA!
Na prova, lembre-se do ciclo: Dockerfile → build → imagem → run → contêiner. Qualquer alteração de dependência ou configuração exige refazer o build e recriar o contêiner. Se a alternativa falar em "modificar a imagem diretamente", desconfie — é pegadinha clássica.