Os sistemas operacionais que o CompTIA A+ cobra no Core 2, por que scripting deixou de ser opcional para quem trabalha com suporte, e o que gestão de dispositivos significa quando a empresa cresce além do que você consegue tratar manualmente.
Era a segunda-feira mais longa da carreira de um técnico que eu conheci.
A empresa havia tomado a decisão de migrar para o Active Directory — centralizar autenticação, aplicar políticas via GPO, mapear drives de rede automaticamente. Era uma mudança necessária. O problema é que ninguém havia mapeado o ambiente antes de começar.
A descoberta aconteceu no meio da migração: 47 máquinas rodando Windows 10 Home. Windows Home não entra em domínio. Não há configuração, não há GPO, não há upgrade de políticas que resolva isso — você precisa trocar de edição. Custo de licenciamento que não estava no orçamento, prazo que não estava no planejamento, e um gerente de TI explicando para o diretor por que a migração havia parado no meio.
A causa raiz não foi falta de orçamento. Foi falta de inventário. E inventário começa com uma pergunta simples: qual sistema operacional está rodando em cada máquina, em qual versão, com qual edição?
Essa pergunta — e a capacidade de respondê-la para centenas de máquinas ao mesmo tempo — é o ponto de partida do Core 2 do CompTIA A+.
Bem-vindo ao Core 2 — O que Muda Aqui
Se você chegou até este post vindo da série Core 1 (220-1201), você passou por hardware, redes, dispositivos móveis, virtualização e troubleshooting de componentes. Você sabe o que está dentro da máquina e como a rede funciona.
O Core 2 (220-1202) começa onde o Core 1 termina: com o sistema operacional. A partir daqui, o foco muda de hardware e conectividade para administração, segurança e procedimentos operacionais. São quatro domínios:
- 1.0 Operating Systems (28%) — sistemas operacionais, instalação, configuração, linha de comando, Linux, macOS, cloud
- 2.0 Security (28%) — segurança física e lógica, malware, políticas, Active Directory, hardening
- 3.0 Software Troubleshooting (23%) — troubleshooting de SO, aplicações, malware, dispositivos móveis
- 4.0 Operational Procedures (21%) — documentação, change management, backup, segurança ambiental, privacidade
Este post cobre o Objetivo 1.1 do Core 2: entender os tipos de sistemas operacionais, seus propósitos, sistemas de arquivos, ciclo de vida dos fornecedores e considerações de compatibilidade. E porque nenhum técnico vive apenas em um único SO, já introduzo aqui o contexto de scripting e gestão que transforma esse conhecimento em capacidade operacional real.
O Mapa dos Sistemas Operacionais
Workstation OSs — Os Quatro que o Exame Cobra
Windows é o SO de workstation mais presente no ambiente corporativo. Domina o mercado de desktop e notebook empresarial. É gerenciado centralmente via Active Directory e Group Policy em ambientes de médio e grande porte. O CompTIA cobra Windows 10 e Windows 11 — o próximo post aprofunda as edições (Home, Pro, Enterprise, Pro for Workstations) e por que a escolha de edição determina o que você pode ou não fazer na rede.
Linux existe em praticamente todos os servidores e em boa parte dos dispositivos IoT, appliances de rede, firewalls e sistemas embarcados. No desktop corporativo, a presença é menor — mas técnicos de suporte se deparam com estações Linux em ambientes de engenharia, desenvolvimento e cibersegurança. O CompTIA cobra comandos básicos, sistema de arquivos, gerenciamento de pacotes e configurações comuns. Coberto em profundidade no Objetivo 1.7 desta série.
macOS é o SO da Apple para desktops e notebooks. Comum em empresas de criação, design, publicidade, desenvolvimento de software e ambientes onde a integração com outros dispositivos Apple é um requisito. Em ambientes corporativos mistos, exige atenção ao MDM e à compatibilidade com serviços de diretório (Active Directory via LDAP). Coberto no Objetivo 1.6.
ChromeOS é o SO baseado em Linux e centrado no navegador Chrome, desenvolvido pelo Google. Roda em Chromebooks. Extremamente comum em educação, onde o modelo de gerenciamento centralizado via Google Admin Console e o custo de hardware baixo o tornam atraente. No ambiente corporativo, é usado em funções de acesso a aplicações web. A gestão é quase inteiramente via nuvem — não há instalação de software local tradicional.
Mobile OSs — Onde o Suporte Acontece no Campo
iOS e iPadOS são os sistemas operacionais da Apple para iPhone e iPad. Ecossistema fechado, com distribuição de aplicativos exclusivamente via App Store. O gerenciamento corporativo acontece via MDM (Mobile Device Management) — configuração de perfis, políticas de segurança, controle de aplicativos, wipe remoto. Se você leu o Post 03 desta série, esse território já é familiar.
Android é o SO móvel da Google, com maior participação de mercado global. Ecossistema mais aberto — permite sideloading (instalação de apps fora da loja) — o que cria tanto mais flexibilidade quanto mais vetores de risco em ambientes corporativos. Também gerenciado via MDM, com suporte a Android Enterprise para segregação entre perfil pessoal e corporativo em dispositivos BYOD.
Sistemas de Arquivos — A Camada que Ninguém Vê até Quebrar
Todo SO organiza dados em disco usando um sistema de arquivos. A escolha do sistema de arquivos determina o que é possível em termos de tamanho máximo de arquivo, permissões, criptografia, journaling (capacidade de recuperação após falha) e compatibilidade entre sistemas.
┌─────────────────────────────────────────────────────────────────────────────┐│ SISTEMAS DE ARQUIVOS — REFERÊNCIA RÁPIDA │├──────────┬───────────────────────────────────┬────────────────────────────┤│ FS │ Ambiente principal │ Destaque │├──────────┼───────────────────────────────────┼────────────────────────────┤│ NTFS │ Windows (workstation e servidor) │ Permissões, EFS, journaling││ ReFS │ Windows Server, Storage Spaces │ Resiliência, grandes vols. ││ FAT32 │ Dispositivos removíveis, USB │ Compatibilidade universal ││ exFAT │ SD cards, pendrives modernos │ FAT32 sem limite de 4GB ││ ext4 │ Linux (padrão) │ Journaling, permissões POSIX││ XFS │ Linux (grandes volumes) │ Alta performance, I/O pesado││ APFS │ macOS, iOS (SSD) │ Snapshots nativos, criptog. │└──────────┴───────────────────────────────────┴────────────────────────────┘
NTFS (New Technology File System) é o sistema padrão do Windows. Suporta permissões granulares de arquivo e pasta, criptografia via EFS (Encrypting File System), journaling para recuperação após falha, e arquivos maiores que 4 GB. Qualquer máquina Windows em ambiente corporativo usa NTFS como sistema primário.
ReFS (Resilient File System) é o sucessor do NTFS no contexto de servidor. Projetado para volumes muito grandes e para integração com Storage Spaces (RAID via software do Windows Server). Não suporta todas as funcionalidades do NTFS (como boot direto) mas oferece maior resiliência contra corrupção de dados.
FAT32 é o sistema antigo do Windows que ainda é relevante por uma razão: compatibilidade universal. Um pendrive formatado em FAT32 é reconhecido por Windows, macOS e Linux sem drivers adicionais. A limitação crítica: arquivos individuais não podem exceder 4 GB.
exFAT foi criado para resolver exatamente esse limite. É o FAT32 moderno, sem o limite de 4 GB por arquivo, amplamente compatível. É o sistema padrão que o Windows usa ao formatar cartões SD e pendrives de maior capacidade.
ext4 é o sistema de arquivos padrão das principais distribuições Linux (Ubuntu, Debian, CentOS). Suporta journaling, permissões POSIX (que são a base da segurança de arquivos no Linux), e volumes de até 1 exabyte. Um técnico de suporte precisa reconhecer ext4 quando trabalhar com partições Linux.
XFS é preferido em ambientes Linux de alto desempenho — servidores de banco de dados, sistemas de armazenamento, aplicações com I/O intensivo. Red Hat Enterprise Linux usa XFS como padrão desde a versão 7.
APFS (Apple File System) é o sistema atual da Apple, introduzido em 2017 para substituir o HFS+. Projetado para SSDs: suporta snapshots nativos (base do Time Machine moderno), criptografia nativa, clonagem de arquivos sem duplicação de dados. É incompatível com Windows sem software de terceiros.
Ciclo de Vida dos Fornecedores — A Data que Você Não Pode Ignorar
Todo sistema operacional tem um ciclo de suporte. Quando o suporte encerra, o SO deixa de receber atualizações de segurança. Isso não é apenas uma recomendação técnica — é um risco de compliance, um vetor de ataque, e, em ambientes regulados, uma violação de política.
End-of-life (EOL) é a data em que o fornecedor encerra todo o suporte ao produto. Após o EOL, vulnerabilidades descobertas não recebem patches. Máquinas com SOs em EOL em redes corporativas são um problema ativo, não apenas um item de backlog.
Update limitations afetam versões específicas de um SO que ainda não atingiram EOL completo mas já não recebem determinados tipos de atualização — como feature updates, que trazem funcionalidades novas mas não apenas correções de segurança. O Windows 10 é um exemplo: diferentes build versions (21H2, 22H2) têm datas de EOL distintas, e a versão 22H2 atingiu end-of-life em outubro de 2025.
O que o técnico precisa fazer na prática: manter um inventário atualizado com a versão de SO de cada máquina e comparar periodicamente com as datas de suporte publicadas pelos fornecedores. Sem esse inventário, você não sabe o que está exposto.
Compatibilidade entre Sistemas Operacionais
Em ambientes heterogêneos — e a maioria dos ambientes reais é heterogênea — a compatibilidade entre SOs é uma fonte constante de chamados.
Problemas comuns de compatibilidade:
Sistemas de arquivos — um disco formatado em APFS é opaco para o Windows sem software de terceiros. Um disco NTFS é somente leitura no macOS por padrão (escrever requer software adicional). Um disco ext4 não é reconhecido nativamente pelo Windows nem pelo macOS sem drivers específicos.
Permissões — o modelo de permissões NTFS (Windows) e POSIX (Linux/macOS) são diferentes. Arquivos criados num sistema podem ter permissões incompatíveis ao serem acessados no outro. Em ambientes com servidores de arquivo Samba (Linux servindo SMB para Windows), essa é uma fonte frequente de falhas de acesso.
Aplicações — um executável .exe não roda em Linux nem em macOS nativamente. Uma aplicação .dmg é exclusiva do macOS. A questão de compatibilidade de aplicativos entre SOs é um dos fatores que determina qual SO uma organização pode adotar para suas estações — e quanto de camada de emulação ou virtualização ela precisará manter.
Scripting — Por que Deixou de Ser Opcional
Se você gerencia dez máquinas, você consegue trabalhar manualmente. Se você gerencia cem, você começa a sofrer. Se você gerencia mil, você ou aprende scripting ou contrata mais técnicos — e às vezes ambos.
Scripting é a capacidade de escrever instruções que o sistema operacional executa em sequência, de forma automatizável e repetível. O técnico que sabe script não apenas resolve um problema — ele resolve o problema em 500 máquinas ao mesmo tempo.
CMD — A Linha de Comando Original do Windows
O Prompt de Comando (cmd.exe) é o interpretador de linha de comando original do Windows. Existe desde o DOS. Suporta comandos como ipconfig, ping, netstat, tasklist, net use, chkdsk — a maioria do que você usou nos posts de troubleshooting deste série foi executável via CMD.
Limitação crítica: CMD é um interpretador de comandos, não uma linguagem de script robusta. Ele suporta scripts batch (.bat, .cmd), mas esses scripts têm limitações severas de estrutura, manipulação de erros e integração com o sistema operacional moderno.
PowerShell — O Substituto e o Padrão Corporativo
PowerShell foi lançado pela Microsoft em 2006 e se tornou o padrão de automação em ambientes Windows. A diferença fundamental em relação ao CMD: PowerShell trabalha com objetos, não com texto.
Quando você executa Get-Process no PowerShell, não recebe uma string de texto — recebe uma lista de objetos, cada um com propriedades como Name, Id, CPU, WorkingSet. Isso significa que você pode filtrar, ordenar, exportar e manipular esses dados de forma muito mais precisa do que parsing de texto.
A lógica de nomenclatura usa verbos padronizados:
Get- → recupera informação (Get-Process, Get-Service, Get-ADUser)Set- → altera configuração (Set-Service, Set-ADUser)New- → cria objeto (New-Item, New-LocalUser)Remove- → remove objeto (Remove-Item, Remove-LocalUser)Start- → inicia algo (Start-Service, Start-Process)Stop- → encerra algo (Stop-Service, Stop-Process)
Scripts PowerShell têm extensão .ps1. Em ambientes corporativos, a política de execução de scripts (ExecutionPolicy) controla quais scripts podem rodar — por padrão, o Windows bloqueia execução de scripts não assinados. Isso é uma decisão de segurança, não um defeito.
PowerShell é multiplataforma desde a versão 7 (PowerShell Core), rodando em Windows, Linux e macOS.
Bash — A Língua do Linux (e do macOS, e dos Servidores)
Bash (Bourne Again Shell) é o shell padrão na maioria das distribuições Linux e foi o shell padrão do macOS até 2019 (quando foi substituído pelo Zsh). Scripts bash têm extensão .sh.
Em ambientes corporativos, bash é a ferramenta para automação em servidores Linux, sistemas de CI/CD, DevOps e qualquer infraestrutura baseada em Unix. O técnico de suporte que trabalha em ambiente misto precisa reconhecer e executar scripts bash básicos, entender permissões de execução (chmod +x script.sh), e saber onde os logs ficam (/var/log/).
A regra prática: em Windows, use PowerShell. Em Linux/macOS, use bash. Em ambientes que precisam das duas plataformas, PowerShell 7+ oferece cobertura cruzada.
Gestão de Dispositivos — Da Máquina Individual ao Parque Inteiro
Device Manager — O Painel de Controle do Hardware
O Gerenciador de Dispositivos (devmgmt.msc) é a interface no Windows que exibe todos os dispositivos de hardware reconhecidos pelo sistema e o status de seus drivers. É o ponto de partida para qualquer problema de hardware no SO.
Acesso rápido: Win + X → Device Manager Run → devmgmt.msc MMC → Add Snap-in → Device Manager
O que você lê no Gerenciador de Dispositivos:
- Ícone normal — dispositivo funcionando corretamente com driver instalado
- Triângulo amarelo (!) — dispositivo com problema: driver ausente, corrompido ou incompatível
- X vermelho — dispositivo desabilitado manualmente
- Seta para baixo — dispositivo desabilitado (diferente do X vermelho: foi desabilitado por configuração, não por erro)
O triângulo amarelo é o sinal mais comum em campo. Causas frequentes: driver desatualizado após update do Windows, driver incompatível com uma nova versão do hardware, dispositivo USB não reconhecido, ou adaptador de rede com driver ausente após reinstalação do SO.
Os Três Modelos de Gestão
Standalone / Grupo de Trabalho (Workgroup) Cada máquina gerencia seus próprios usuários e políticas localmente. Funciona bem em ambientes pequenos (até ~10 máquinas). Sem um ponto central de controle — cada máquina tem sua própria lista de usuários locais, suas próprias senhas, suas próprias configurações. Escala mal.
Active Directory / Domínio As máquinas são “ingressadas” em um domínio gerenciado por um servidor que roda o Active Directory Domain Services (AD DS). Um administrador define políticas que se aplicam a todas as máquinas e usuários do domínio via Group Policy (GPO). Um único conjunto de credenciais permite ao usuário fazer login em qualquer máquina do domínio. Este é o modelo padrão em ambientes corporativos de médio e grande porte.
MDM (Mobile Device Management) Para dispositivos móveis e, cada vez mais, para notebooks que não estão permanentemente na rede corporativa, o gerenciamento acontece via MDM. A ferramenta MDM se comunica com o dispositivo via Internet, aplicando políticas, distribuindo aplicativos, e podendo executar wipe remoto independente de onde o dispositivo esteja. Windows, macOS, iOS e Android suportam MDM.
A tendência moderna — acelerada pelo trabalho remoto — é combinar AD DS para máquinas dentro da rede com MDM para dispositivos remotos, via soluções como o Microsoft Intune.
Mapa Mental — Core 2, Domínio 1.0
CORE 2 — OPERATING SYSTEMS (28%)│├── 1.1 OS Types & Purposes [ESTE POST]│ ├── Workstation: Windows, Linux, macOS, ChromeOS│ ├── Mobile: iOS, iPadOS, Android│ ├── Filesystems: NTFS, ReFS, FAT32, exFAT, ext4, XFS, APFS│ └── Lifecycle: EOL, update limitations, compatibility│├── 1.2 OS Installation & Upgrades [POST 22]│ ├── Boot methods, clean install, upgrade, image deployment│ └── Partitioning: GPT vs MBR│├── 1.3 Windows Editions [POST 23]│ ├── Win 10: Home, Pro, Pro for Workstations, Enterprise│ └── Win 11: Home, Pro, Enterprise│├── 1.4 Windows Features & Tools [POST 24]│ ├── Task Manager, MMC snap-ins (Event Viewer, Disk Mgmt...)│ └── msinfo32, resmon, msconfig, regedit│├── 1.5 Windows Command-Line Tools [POST 25]│ ├── Navigation: cd, dir│ ├── Network: ipconfig, ping, netstat, tracert│ └── OS mgmt: gpupdate, sfc, chkdsk, diskpart│├── 1.6 Windows Settings [POST 26]│ ├── Control Panel vs Settings│ └── Power, Networking, Accounts, Update & Security│├── 1.7 Linux Desktop [POST 27]│ ├── Commands: ls, chmod, grep, ps, top...│ └── Config files: /etc/passwd, /etc/fstab, /etc/hosts│├── 1.8 Application Installation [POST 28]│ └── System requirements, distribution, impact│└── 1.9 Cloud Productivity Tools [POST 29] └── Email, Storage, Collaboration, Identity sync
Bypass Consciente
Este post cobre o Objetivo 1.1 do Core 2 (220-1202) e introduz conceitos de scripting e gestão que serão aprofundados nos objetivos 1.4, 1.5 e nos domínios de Segurança e Procedimentos Operacionais.
O que foi intencionalmente deixado de fora:
- Detalhes de instalação de SO — clean install, particionamento GPT vs MBR, zero-touch deployment — são o Objetivo 1.2 e aparecem no Post 22.
- Windows editions em detalhe (BitLocker, RDP, RAM limits, gpedit) — Objetivo 1.3, Post 23.
- Comandos individuais de linha de comando — Objetivo 1.5, Post 25.
- Active Directory em profundidade (OUs, objetos, security groups, folder redirection) — aparece no Domínio 2.0 (Segurança), quando o AD é tratado no contexto correto.
- PowerShell scripting em profundidade — scripts
.ps1, módulos.psm1, ExecutionPolicy, pipeline avançado — está fora do escopo do exame A+ mas é a sua próxima fronteira de aprendizado.
Para os objetivos oficiais do 220-1202 V15, consulte diretamente: 👉 https://www.comptia.org/certifications/a — download do PDF de objetivos
Provocação
O exame A+ cobra a diferença entre NTFS e FAT32. Mas aqui vai a pergunta que o exame não faz — e que aparece em todo ambiente corporativo real:
Uma máquina Windows lê um pendrive formatado em exFAT sem problema. Mas o técnico de segurança da empresa pediu que todos os pendrives do departamento financeiro fossem formatados em NTFS. Por quê?
A resposta não está neste post. Está na documentação de permissões NTFS e no conceito de ACLs por arquivo — algo que o FAT32 e o exFAT simplesmente não suportam. Se você entender por que um sistema de arquivos sem permissões é um risco em dados sensíveis, você entendeu algo que muitos técnicos que eu conheço ainda não entenderam.
Próximo Post
Core 2 · Objetivo 1.2 — Instalação e Upgrade de Sistemas Operacionais
Saber o que é um SO é o primeiro passo. Saber como instalar um do zero — ou migrar uma máquina sem perder dados, configurações e licenças — é onde o trabalho real começa.
O Post 22 cobre boot methods (USB, rede, partição de recuperação), tipos de instalação (clean install, upgrade, image deployment, zero-touch), particionamento GPT vs MBR, e os critérios práticos para decidir quando fazer upgrade no lugar e quando reinstalar do zero.
Se você já teve que justificar para um gestor por que uma reinstalação era necessária — ou por que não era — esse post vai te dar o argumento técnico correto.