O segredo para não cair nessa pegadinha da banca FCC envolve entender a diferença fundamental entre as instruções e no Dockerfile, principalmente no que diz respeito a como os argumentos são substituídos em tempo de execução.

Analisando os requisitos do enunciado:

1. O arquivo deve ser copiado para .
2. Deve ser executado por padrão quando o contêiner iniciar.
3. Ponto-chave da pegadinha: o comando padrão pode ser substituído por outro comando informado no momento da execução do contêiner.

• (Gabarito - Alternativa A): Define um comando padrão para a execução do contêiner. A grande vantagem é que, se você passar qualquer argumento na linha de comando ao rodar o contêiner (ex: ), todo o conteúdo do é completamente substituído por esse novo comando. É exatamente isso que o enunciado pedia ("podendo ser substituído por outro comando informado no momento da execução").
• (Alternativa B e E): Configura o contêiner para rodar como um executável. Os argumentos passados na linha de execução do contêiner são adicionados ao final do , e não substituídos (a menos que se use a flag ). Na alternativa B, o caminho está incorreto, pois o script foi copiado para . Na alternativa E, usa em vez de , o que é uma má prática de construção de imagens.
• (Alternativas C e D): Executa comandos durante o processo de construção (build) da imagem (como instalar pacotes ou copiar arquivos e prepará-los), e não no momento em que o contêiner é iniciado. Usar tentaria rodar o script enquanto a imagem ainda está sendo gerada na máquina de build, o que está incorreto para definir o comportamento de inicialização do contêiner.

• Quer que o comando rode por padrão, mas aceite substituição fácil via linha de comando? Use .
• Quer que o contêiner se comporte como um executável fixo onde os parâmetros passados na execução apenas complementam o comando principal? Use .