Questão de Sistemas Operacionais — Geral — INSTITUTO AOCP 2026

Ansible: automação de configuração sem agente

Gabarito: letra D. O Ansible é uma ferramenta de gerenciamento de configuração agentless (sem agente): conecta-se aos hosts gerenciados via SSH e executa playbooks escritos em YAML, que descrevem o estado desejado de forma idempotente — ou seja, podem ser aplicados repetidamente sem causar efeitos colaterais indesejados. É exatamente isso que a alternativa D descreve, e é o que resolve o problema do instituto federal de padronizar NTP, agente de monitoramento e firewall nos 15 campi.

O Ansible é uma ferramenta de Infrastructure as Code (IaC) e Configuration Management que segue o paradigma declarativo: em vez de escrever um script imperativo com passos sequenciais, você declara o estado final desejado do sistema e a ferramenta se encarrega de levar o host a esse estado. No cenário do enunciado, o analista escreveria um playbook declarando que o serviço NTP deve estar ativo e configurado, que o agente de monitoramento deve estar instalado e que as regras de firewall devem ser as padrão — e o Ansible aplicaria isso em todos os servidores dos campi.

A arquitetura do Ansible é centralizada em um nó de controle (control node), que é a máquina onde o Ansible está instalado e de onde os playbooks são executados. Os hosts gerenciados (managed hosts) não precisam de nenhum software especial instalado — apenas de um servidor SSH ativo e de Python (que já vem por padrão na maioria das distribuições Linux). O nó de controle se conecta via SSH, copia os módulos necessários, executa as tarefas e remove os artefatos temporários. Isso é uma grande vantagem em relação a ferramentas como Puppet e Chef, que exigem agentes instalados nos hosts.

A idempotência é a propriedade mais importante para o gerenciamento de configuração: uma operação é idempotente se, ao ser executada múltiplas vezes, produz o mesmo resultado sem efeitos colaterais. No Ansible, os módulos são projetados para verificar o estado atual antes de agir — por exemplo, o módulo service só reinicia o serviço se ele estiver fora do estado desejado, e o módulo copy só copia o arquivo se o conteúdo for diferente. Isso garante que, se um servidor já está configurado corretamente, a execução do playbook não altera nada (dizemos que o host está in state ou converged).

A pegadinha desta questão é que a banca explora o desconhecimento da arquitetura agentless do Ansible. Muitos candidatos, acostumados com ferramentas como Puppet, Chef ou Zabbix, assumem que toda ferramenta de gerenciamento exige um agente instalado. O Ansible quebra esse paradigma ao usar SSH como transporte padrão — e é justamente essa característica que a alternativa D destaca. Além disso, a banca também testa o conhecimento de que playbooks são arquivos YAML (não binários compilados) e que a ferramenta serve tanto para nuvem quanto para ambientes on-premises.

Guarde a tríade que define o Ansible: agentless (SSH) + YAML + idempotência. É exatamente nesses três pilares que as alternativas se dividem — cada uma das erradas ataca um desses pilares.

Alternativa A — ❌ Incorreta

Afirma que o Ansible requer um agente proprietário em cada servidor. Isso é o oposto da arquitetura real: o Ansible é agentless, conectando-se via SSH sem instalar nenhum software nos hosts gerenciados. A alternativa descreve o modelo de ferramentas como Puppet ou Chef, que usam agentes — mas não o Ansible.

Alternativa B — ❌ Incorreta

Afirma que os playbooks são arquivos binários compilados. Na verdade, playbooks são arquivos de texto em formato YAML (YAML Ain't Markup Language), legíveis por humanos e versionáveis em Git. Não há compilação nem ferramenta específica da Ansible Inc. para gerá-los — qualquer editor de texto serve.

Alternativa C — ❌ Incorreta

Afirma que o Ansible é indicado apenas para nuvem pública e não para ambientes on-premises. Isso é falso: o Ansible é amplamente usado para gerenciar servidores físicos e virtuais em datacenters locais, além de provisionar infraestrutura em nuvem. A ferramenta é agnóstica de ambiente — o que importa é o acesso SSH.

Alternativa D — ✅ Correta ⟵ GABARITO

Descreve com precisão o funcionamento do Ansible: conexão via SSH (sem agente), playbooks em YAML e idempotência (aplicação múltipla sem efeitos colaterais). É exatamente a arquitetura da ferramenta e resolve o cenário do instituto federal.

Alternativa E — ❌ Incorreta

Afirma que cada playbook deve ser escrito em uma linguagem diferente conforme o SO. Na verdade, os playbooks são sempre em YAML, independentemente do sistema operacional gerenciado. O que muda é o módulo utilizado (ex.: apt para Debian/Ubuntu, yum para RHEL/CentOS, win_service para Windows), mas a estrutura do playbook é a mesma.

Gabarito: letra D