{"subject_id":"3a3cc48d0099816db7f3ebdd20c6908d","topico":"Ansible (agentless, push, YAML) × Puppet (agente, pull, DSL, Facter)","stems":["No que se refere ao Microsoft PowerShell, julgue os itens a seguir.","Julgue o item a seguir, relativo à linguagem de script Ansible, considerando que uma operação será idempotente se o resultado ao executá-la uma vez for exatamente igual ao resultado ao executá-la repetidamente sem nenhuma ação interveniente.","Julgue os itens seguintes, relativos a virtualização e orquestração de infraestrutura.","Julgue o item subsequente, relativo aos conceitos de conformidade e automação de TI: Puppet, Ansible.","A respeito de DevOps, julgue os itens subsequentes.","Considerando a figura a seguir, julgue os próximos itens, acerca dos conceitos de DevOps.","Acerca de sistemas operacionais Linux, julgue os itens que se seguem."],"questions":[{"id":"1167ef5ca0ce","number":62,"stem":0,"statement":"A estrutura de gerenciamento de DSC (desired state configuration) permite gerenciar a infraestrutura corporativa com código para ajudar a implantar configurações usando-se modelos de push ou pull.","answer":"C","source":{"slug":"MP_TO_24_SERVIDOR","ano":2024},"explanation":{"verdict_reason":"O DSC é a estrutura de gerência de configuração do PowerShell: escreve-se em código a configuração desejada da máquina, que o Local Configuration Manager aplica e mantém. Ele admite os dois modos de entrega — push, em que a configuração é empurrada para o nó, e pull, em que o nó busca periodicamente a configuração em um servidor. É o que o item afirma.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"DSC: configuração como código, entregue por push ou por pull","citation":null,"trap_note":"Push × pull é distinção de arquitetura, não propriedade fixa de cada produto: o Ansible empurra, o Puppet puxa, e o DSC faz os dois. Item que negue um dos modos ao DSC está errado."}},{"id":"5f8bfb0fcd3b","number":70,"stem":1,"statement":"Para a sua automatização no Windows, o Ansible se conecta a nós de controle, e o usuário executa comandos escritos para manipular recursos do estado desejado do sistema, sendo esses comandos projetados para serem idempotentes quanto possível.","answer":"E","source":{"slug":"CPNUJE_24","ano":2024},"explanation":{"verdict_reason":"A direção da conexão está invertida: o nó de controle é a máquina onde o Ansible roda, e é dela que partem as conexões para os nós gerenciados — no Windows, por WinRM. O Ansible não se conecta a nós de controle. O fecho do item está correto: os módulos são escritos para serem idempotentes, de modo que reexecutar não produz efeito adicional quando o estado já corresponde ao desejado.","distortion_type":"troca_de_termo","distorted_span":"se conecta a nós de controle","corrected_statement":"Para a sua automatização no Windows, o Ansible se conecta a nós gerenciados, e o usuário executa comandos escritos para manipular recursos do estado desejado do sistema, sendo esses comandos projetados para serem idempotentes quanto possível.","concept":"nó de controle × nó gerenciado","citation":"Ansible Docs — Windows Remote Management","trap_note":"Nó de controle é um só e é de onde se dispara; nós gerenciados são muitos e é para onde se empurra. Ao ler item de arquitetura, identifique quem inicia a conexão antes de julgar o resto da frase."}},{"id":"cfb98fadabaf","number":89,"stem":2,"statement":"Ao ser executado o playbook Ansible a seguir, serão classificados todos os hosts do servidor com base no sistema operacional de cada um, e, se houver um host cujo sistema operacional seja o Ubuntu, ele será automaticamente adicionado ao grupo os_Ubuntu.\n\n- name: Talk to all hosts just so we can\nlearn about them\n  hosts: all\n  tasks:\n    - name: Classify hosts depending on their\nOS distribution\n    ansible.builtin.group_by:\n    key: os_{{ ansible_facts['distribution']\n}}","answer":"C","source":{"slug":"TRT10_24","ano":2024},"explanation":{"verdict_reason":"O módulo group_by cria grupos dinâmicos durante a execução, a partir do valor da chave informada. Com key: os_{{ ansible_facts['distribution'] }}, cada host é colocado no grupo formado pelo nome da distribuição coletada nos fatos — um host Ubuntu cai no grupo os_Ubuntu. Como o play aponta para hosts: all, a classificação alcança todo o inventário.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"group_by monta grupos dinâmicos a partir dos fatos","citation":"Ansible Docs — ansible.builtin.group_by","trap_note":"Fatos são coletados antes das tarefas e alimentam condicionais e agrupamentos. Item que exija o grupo previamente escrito no inventário desconhece o grupo dinâmico, que existe só durante a execução."}},{"id":"720f4cc539da","number":90,"stem":2,"statement":"O comando Hyper-V a seguir será executado diretamente se a sessão remota do servidor remoto já estiver ativa.\n\nInvoke-Command -ScriptBlock {\n    Install-WindowsFeature -Name Hyper-V -\nIncludeManagementTools -Restart\n}","answer":"E","source":{"slug":"TRT10_24","ano":2024},"explanation":{"verdict_reason":"O Invoke-Command só executa remotamente se receber o destino: -ComputerName, para abrir a conexão, ou -Session, para reaproveitar uma sessão persistente já aberta. Tendo apenas -ScriptBlock, o bloco roda na máquina local, ainda que exista sessão remota ativa — a sessão não é escolhida sozinha. Para instalar o papel Hyper-V no servidor remoto seria preciso indicar a sessão ou o nome da máquina.","distortion_type":"relacao_causal","distorted_span":"será executado diretamente se a sessão remota do servidor remoto já estiver ativa","corrected_statement":"O comando Hyper-V a seguir será executado na máquina local, pois não indica o destino remoto pelos parâmetros -Session ou -ComputerName.","concept":"Invoke-Command sem -Session ou -ComputerName executa localmente","citation":null,"trap_note":"Condição externa anunciada no enunciado não supre parâmetro ausente no comando. Antes de aceitar o efeito remoto, procure na linha escrita o que endereça a ação ao destino."}},{"id":"d1a2e836b3b9","number":97,"stem":3,"statement":"O Ansible é uma solução de software que permite controlar um dispositivo, através de agentes nele instalados, a partir de um local diferente, sendo que a comunicação entre o servidor e o dispositivo ocorre por meio dos referidos agentes.","answer":"E","source":{"slug":"DATAPREV_23","ano":2023},"explanation":{"verdict_reason":"A marca registrada do Ansible é exatamente o contrário: ele não usa agente. O nó de controle se conecta aos nós gerenciados pelo transporte nativo de cada sistema — SSH no Linux, WinRM no Windows —, copia os módulos, executa e os remove; nada permanece instalado no destino. Quem opera com agente residente no nó é o Puppet, e o item veste o modelo do Puppet com o nome do Ansible.","distortion_type":"inversao","distorted_span":"através de agentes nele instalados","corrected_statement":"O Ansible é uma solução de software que permite controlar um dispositivo, sem agentes nele instalados, a partir de um local diferente, sendo que a comunicação entre o servidor e o dispositivo ocorre por SSH ou WinRM.","concept":"Ansible é sem agente; Puppet usa agente","citation":null,"trap_note":"Agente residente, comunicação iniciada pelo nó, catálogo puxado periodicamente do servidor: isso é Puppet. Sem agente, conexão iniciada pelo nó de controle, tarefas empurradas por SSH: isso é Ansible. A banca troca os dois modelos de nome e mantém o resto da frase."}},{"id":"1661515c2b12","number":67,"stem":4,"statement":"A ferramenta puppet permite escrever e executar um conjunto de diretivas para gerenciar a configuração de um sistema, seja o operacional, seja uma aplicação.","answer":"C","source":{"slug":"BANCO_DO_NORDESTE_22","ano":2022},"explanation":{"verdict_reason":"O Puppet é ferramenta de gerência de configuração: escrevem-se manifestos, em linguagem própria, declarando o estado desejado de pacotes, serviços, arquivos e usuários, e o agente instalado no nó aplica esse estado. O alcance vai do sistema operacional às aplicações que rodam sobre ele. O item descreve esse funcionamento sem distorção.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Puppet: manifestos declaram o estado de sistema e de aplicação","citation":null,"trap_note":"Gerência de configuração (Puppet, Ansible, Chef) cuida do que existe dentro da máquina; provisionamento (Terraform, CloudFormation) cuida de criar a máquina. Fixada essa fronteira, a maioria dos itens do tópico se decide."}},{"id":"e08131493de0","number":105,"stem":5,"statement":"A ferramenta RedHat Ansible está mais relacionada à etapa deploy do que à etapa plan.","answer":"C","source":{"slug":"BANCO_DO_NORDESTE_22","ano":2022},"explanation":{"verdict_reason":"No ciclo do DevOps, plan é a etapa de definir e priorizar o que será feito; deploy é a de levar o que foi construído aos ambientes de destino. O Ansible automatiza instalação, configuração e publicação nas máquinas, que é trabalho de entrega. Daí a associação com deploy, e não com plan.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Ansible atua na implantação, não no planejamento","citation":null,"trap_note":"Mapa de ferramenta por etapa: planejar com quadros de tarefas; codificar com Git; construir com Maven e Jenkins; testar com JUnit e Selenium; implantar com Ansible, Puppet e Kubernetes; operar e monitorar com Zabbix, Nagios e Prometheus. A banca embaralha esse mapa."}},{"id":"0e4f78db5dc7","number":66,"stem":6,"statement":"O comando a seguir é capaz de executar o comando ping em todos os hosts cadastrados para o Ansible. ansible full -x ping","answer":"E","source":{"slug":"EMAP_18","ano":2018},"explanation":{"verdict_reason":"Há duas trocas na mesma linha: o padrão que representa todo o inventário é all, não full, e o módulo a executar se indica com -m, não com -x. A forma correta de testar conectividade com todos os hosts é ansible all -m ping. Escrito como está, o comando sequer é interpretado.","distortion_type":"troca_de_termo","distorted_span":"ansible full -x ping","corrected_statement":"ansible all -m ping","concept":"comando ad hoc: ansible all -m ping","citation":null,"trap_note":"Guarde o formato do comando ad hoc: ansible seguido do padrão de hosts, depois -m com o módulo e -a com os argumentos. A banca altera o padrão de hosts ou a letra da opção e deixa o resto da linha plausível."}}]}