Guia de estudo organizado pelos quatro domínios oficiais da prova. Cada domínio segue o mesmo fluxo previsível — conceito, critério de decisão, hands-on no tenant e pegadinhas — para facilitar foco, revisão e treino com questões de cenário.
A estrutura segue os quatro domínios cobrados na prova. Cada domínio é autossuficiente: você pode estudar na ordem ou pular direto para o que precisa revisar.
Implementar e gerenciar identidades
20–25%Implementar autenticação e acesso
25–30%Planejar e implementar workload identities
20–25%Planejar e automatizar governance
20–25%A SC-300 cobra muito mais cenário do que definição isolada: normalmente a questão traz uma restrição, uma licença, um tipo de usuário, uma condição de acesso ou um requisito de menor privilégio. Para cada domínio, siga sempre a mesma ordem:
Dica para foco: estude um domínio por vez e marque o checklist abaixo conforme avança. O progresso fica salvo no seu navegador, então você pode parar e voltar sem perder o ritmo.
Marque o que você consegue explicar e executar sem consultar o material. O que ficar desmarcado é exatamente o que revisar na véspera.
Tenant, usuários, grupos, licenças, device registration, RBAC com least privilege, identidades externas e identidade híbrida.
Este domínio é sobre as pessoas e coisas que existem no seu Microsoft Entra: usuários, grupos, dispositivos. Tudo mora dentro de um "contêiner" chamado tenant.
É o "prédio" da sua empresa no mundo Microsoft — um espaço isolado e só seu, onde ficam todos os usuários, grupos, dispositivos, apps e regras. Quando a prova fala em "o locatário" ou "o tenant", é desse prédio que ela está falando.
Cada empresa costuma ter um tenant, com um endereço inicial tipo suaempresa.onmicrosoft.com, ao qual você depois adiciona o domínio próprio (suaempresa.com).
Nem todo usuário é igual. Há duas perguntas: de onde a conta veio? e que tipo de gente ela é (de casa ou visita)?
Cloud-only: nasceu direto na nuvem, só existe lá. Sincronizada: nasceu no servidor da empresa (AD local) e foi "copiada" pra nuvem. Convidada/externa: é de outra empresa, foi convidada pra colaborar.
Conta sincronizada tem a "fonte da verdade" no AD local — você edita os dados lá, não na nuvem (senão a próxima sincronização sobrescreve).
Pense em "morador" vs "visita". Member = funcionário da casa, acesso amplo. Guest = convidado (geralmente B2B), acesso restrito por padrão.
Um grupo dinâmico com a regra userType -eq "Member" deixa todos os convidados de fora. Para pegar absolutamente todos, use uma regra ampla como user.objectId -ne null.
Todo funcionário passa por três fases: entra (Joiner), muda de cargo/área (Mover) e sai (Leaver). Criar a conta direito significa preencher bem os atributos (cargo, departamento, gestor, país…), porque eles "alimentam" automaticamente grupos, licenças e relatórios depois.
O cargo vai no campo Job title (não no nome). E o Usage location é obrigatório pra licenciar — sem ele, a licença falha.
Grupos parecem simples, mas a prova explora combinações. Pense em duas perguntas independentes: que tipo de grupo é? e como entra gente nele?
Security group: serve pra dar acesso, licença e aplicar regras — é o "cavalo de batalha" do IAM. Microsoft 365 group: faz isso e ainda traz caixa de e-mail compartilhada, SharePoint e Teams (é colaborativo).
Pra acesso/licença pura, escolha Security group.
Assigned: você adiciona e tira gente na mão. Dynamic: uma regra decide automaticamente quem entra, com base em atributos.
Grupo dinâmico é ou de usuários ou de dispositivos — nunca os dois misturados.
Se você quer dar um cargo de administrador a um grupo inteiro (em vez de pessoa por pessoa), o grupo precisa ser marcado como "role-assignable" na criação. Essa marca é permanente.
Grupo role-assignable não pode ser dinâmico — só Assigned (manual). Faz sentido: ninguém deve virar admin automático só por bater com uma regra. E só Global Admin ou Privileged Role Admin gerenciam esses grupos.
| Quero... | Configuração |
|---|---|
| Dar acesso/licença a um grupo fixo de pessoas | Security group, Assigned |
| Agrupar automaticamente por atributo (ex.: todo o dep. de Claims) | Security group, Dynamic user |
| Atribuir uma função de admin a um grupo | Security group role-assignable (só Assigned) |
| Colaboração com caixa, SharePoint e Teams | Microsoft 365 group |
A regra é uma "frase de condição" que decide quem entra no grupo. Os pedacinhos: -eq (igual a), -ne (diferente de), -contains (contém), -startsWith (começa com), -match (bate com um padrão). Você junta condições com and / or.
// Todos os Claim Handlers ativos de Portugal
(user.country -eq "PT") and (user.jobTitle -eq "Claim Handler") and (user.accountEnabled -eq true)
// Departamento que começa com "Sales"
(user.department -startsWith "Sales")
// Absolutamente todos, incluindo convidados
(user.objectId -ne null)Achar que userType -eq "Member" pega "todo mundo" — deixa os convidados de fora.
Você dá a licença ao grupo, e todo membro recebe automaticamente. Quem entra ganha a licença, quem sai perde. Muito mais escalável que atribuir uma a uma.
O grupo precisa ser de usuários (não de dispositivos), e cada usuário precisa do Usage location definido — senão a licença falha pra ele.
É uma forma de dar a alguém poder de admin sobre só um pedaço da empresa, não o prédio inteiro. Pense numa "gaveta" com os usuários de uma filial: você dá ao Service Desk o poder de resetar senha só dentro daquela gaveta.
Service Desk de Portugal precisa resetar senha só de portugueses → cria a AU-Portugal, coloca os usuários lá, e dá Helpdesk Administrator escopado a essa AU.
A função limita o que pode fazer · a AU limita onde · o PIM (D4) limita por quanto tempo.
Um aparelho precisa ter "identidade" no Entra pra participar de SSO e Conditional Access. Há três estados — a diferença é de quem é o aparelho e como você loga nele.
O aparelho pessoal (BYOD). Você loga no Windows com sua conta pessoal e só "adiciona" a conta da empresa pra acessar e-mail, etc. A empresa tem controle leve.
Seu celular ou notebook de casa acessando o e-mail corporativo.
O aparelho corporativo moderno, 100% nuvem. Você loga no Windows com a conta da empresa (Entra), e ele é gerenciado por Intune/Autopilot. Sem servidor local na jogada.
Notebook novo da empresa configurado por Autopilot.
O aparelho corporativo de uma empresa que ainda usa servidor local (AD DS). Ele é ingressado no domínio local e registrado na nuvem ao mesmo tempo — a "ponte" entre os dois mundos.
Empresa com GPOs e AD local que está migrando aos poucos pra nuvem.
Pra usar suaempresa.com em vez do .onmicrosoft.com, a ordem é contraintuitiva e cai em prova: 1) adiciona o domínio no Entra → ele te dá um código DNS → 2) cria esse registro no seu provedor de DNS → 3) verifica.
Nunca verificar antes de criar o DNS. E o .onmicrosoft.com original nunca é removido.
Dar um cargo a alguém no Entra é como montar a frase: "Fulana pode fazer [função] sobre [escopo] durante [tempo]." Em qualquer questão de cenário, identifique esses pedaços: quem recebe, o que pode fazer, onde vale e por quanto tempo.
São três "mundos" de permissão diferentes. Entra roles mandam no diretório (usuários, MFA, grupos, apps, Conditional Access). Azure RBAC manda nos recursos (VM, storage, Key Vault, subscription). PIM é sobre tempo: dar acesso só quando precisa, com aprovação.
Fala de usuário/MFA/grupo/app → Entra role · fala de VM/storage/cofre → Azure RBAC · fala de "temporário/aprovação/just-in-time" → PIM.
As funções que mais aparecem na prova, com o cuidado de cada uma. Use esta tabela como consulta rápida — não precisa decorar tudo:
| Função | O que permite | Cuidado de prova |
|---|---|---|
| Global Administrator | Controle total do tenant. | Quase nunca é a resposta quando se pede menor privilégio. |
| Privileged Role Administrator | Gerencia role assignments e PIM. | Extremamente sensível: pode conceder privilégio a outros. |
| User Administrator | Gerencia usuários/grupos e reseta senha de não-admins. | Não é ideal para gerenciar MFA — use Authentication Administrator. |
| Helpdesk Administrator | Reseta senhas de não-admins e invalida refresh tokens. | Não deve ser tenant-wide se o time atende só uma região. |
| Authentication Administrator | Gerencia métodos de auth de usuários comuns (MFA, TAP). | Não gerencia métodos de administradores. |
| Privileged Authentication Administrator | Gerencia métodos de auth de comuns e admins. | Mais poderosa; use com PIM. |
| Conditional Access Administrator | Cria e gerencia políticas CA. | Pode bloquear o tenant; proteja com MFA forte e PIM. |
| Global Reader | Leitura ampla do tenant. | Boa alternativa a Global Admin quando só precisa visualizar. |
| Application Administrator | App registrations, enterprise apps, SSO e App Proxy. | Mais alcance que Cloud Application Administrator em App Proxy. |
Quando nenhuma função pronta tem exatamente o que você precisa, você monta a sua. Ex.: alguém que só pode rotacionar credenciais de apps, sem mexer em mais nada.
Atribua a um grupo e, se der, deixe como eligible via PIM.
O maior erro aqui é misturar duas perguntas independentes: "como os usuários chegam à nuvem?" (sincronização) e "onde a senha é conferida?" (autenticação). São coisas separadas.
Connect Sync: o motor "completo", instalado num servidor — faz cenários complexos, mas é mais pesado. Cloud Sync: agentes leves, configurado na nuvem — mais simples, ótimo pra múltiplas florestas e fusões.
Connect Sync não é "sempre melhor" — é mais completo, porém mais pesado. Cloud Sync é mais simples, mas não cobre tudo.
Parte 2 — Autenticação (onde a senha é conferida). São três métodos. Vale entender o mecanismo, não só o nome:
O servidor local manda pra nuvem um "resumo embaralhado" da senha (não a senha de verdade). Quando você loga, é a nuvem que confere. Como a conferência é na nuvem, funciona mesmo se o servidor local cair.
Por ter esses resumos, a nuvem consegue avisar se sua senha vazou em algum ataque (detecção de credenciais vazadas). É o método mais simples e recomendado.
Nada de senha vai pra nuvem. Quando você loga, a nuvem pergunta a um agente no servidor local "essa senha está certa?" e espera a resposta na hora.
Depende dos agentes locais — se caírem (sem ter vários de backup), o login para. E a detecção de vazamento não funciona com PTA puro.
A nuvem terceiriza o login inteiro para outro sistema (o AD FS). É a opção mais complexa e pesada de manter.
Só quando há um requisito específico que exige (ex.: smartcard de terceiros). A tendência é migrar de AD FS para PHS.
Não é um método sozinho — é um "acompanhante" do PHS ou PTA que evita digitar a senha de novo em máquinas corporativas na rede. Usa Kerberos e cria a conta AZUREADSSOACC.
Aparece em 3 lugares: Seamless SSO, App Proxy com KCD (D3) e Entra Kerberos pra file shares.
| Se o cenário pede... | Resposta provável |
|---|---|
| Simplicidade, resiliência e recomendação moderna | PHS + Seamless SSO + Conditional Access |
| Login funcionar mesmo com servidor local fora do ar | PHS (conferência na nuvem) |
| Senha conferida localmente em tempo real | PTA (com vários agentes para backup) |
| Detecção de credenciais vazadas | PHS (depende dos resumos sincronizados) |
| Dependência de IdP externo / smartcard de terceiros | Federation (AD FS) ou CBA |
| Migrar de AD FS para a nuvem com piloto | PHS + staged rollout + grupo piloto |
Quando você precisa trabalhar com gente de fora, há quatro modelos. A pergunta-chave: o que exatamente você precisa fazer com essa pessoa externa?
Você convida alguém de fora e ele vira um convidado (guest) no seu prédio. Aí você dá a ele acesso ao seu SharePoint, Teams, etc.
"Dar a um fornecedor acesso a recursos meus."
Uma "ponte de confiança" entre duas empresas sem criar conta de convidado. O uso clássico são os canais compartilhados (shared channels) do Teams.
"Colaborar via Teams shared channels sem criar contas de convidado."
Um modelo separado, pra identidades de clientes finais — gente que usa um app público ou loja online. Não é pra colaboração entre empresas.
Se o cenário fala de "clientes/consumidores", é B2C — não use pra parceiro de negócio.
Copia e mantém usuários de uma empresa na outra, automaticamente. Clássico de fusão/aquisição: os usuários de uma empresa precisam existir como membros na outra, e isso se atualiza sozinho.
Direct Connect = colaboração sem criar conta · Cross-tenant sync = cria e mantém as contas no destino.
External collaboration settings = regras básicas (quem pode convidar, quais domínios são bloqueados). Cross-tenant access settings = regras por parceiro, incluindo confiar no MFA/device que o convidado já fez na empresa dele (pra não pedir de novo).
AU-Portugal, atribua Helpdesk Administrator escopado e teste reset de senha.| Se o cenário fala sobre... | Pense primeiro em... | Erro comum |
|---|---|---|
| Autenticar na nuvem mesmo com AD local indisponível | PHS (validação ocorre no Entra) | Escolher PTA, que depende dos agentes locais |
| Migrar de AD FS para cloud com piloto | PHS + staged rollout + grupo piloto | Migrar todo o tenant de uma vez |
| Impedir convites para um domínio específico | Collaboration restrictions → deny list | Bloquear todo B2B ou mexer na visualização do guest |
| Atribuir licenças por grupo | Grupos com usuários (security/M365, assigned/dynamic user) | Usar grupo dinâmico de dispositivos |
| Adicionar domínio customizado | Adicionar → criar DNS → verificar | Verificar antes do DNS ou remover o .onmicrosoft.com |
| Grupo dinâmico com todos os usuários, incluindo guests | Regra ampla: user.objectId -ne null | Usar só userType -eq "Member", que exclui guests |
| Colaboração entre tenants sem objeto guest | B2B Direct Connect | Confundir com B2B Collaboration |
| Sincronizar usuários entre tenants em M&A | Cross-tenant synchronization | Usar Teams shared channels como se sincronizasse identidades |
userType = Member exclui os convidados. Para incluir todos os usuários, use uma condição ampla baseada em objeto existente.userType -eq "Member" exclui os guests. Uma condição ampla que casa com qualquer objeto de usuário existente inclui membros e convidados.MFA, passwordless, SSPR, Password Protection, Conditional Access, Identity Protection, controles de sessão e Global Secure Access.
Se o D1 era "quem existe", o D2 é "como a pessoa prova que é ela mesma e em que condições ela entra". Dois grandes temas: os métodos de login e o Conditional Access (o porteiro inteligente).
Nem todo "segundo fator" é igual de seguro. Pense numa escada, do mais fraco ao mais forte:
A Authentication Methods Policy é onde você liga/desliga quais formas de login a empresa aceita. Do mais fraco ao mais forte: SMS/voz/OTP (funciona, mas pode ser interceptado) → Authenticator com number matching (forte, você digita o número que aparece na tela) → passwordless / phishing-resistant (FIDO2, Windows Hello, certificado — os mais seguros).
São métodos que não dá pra roubar por engano porque estão presos ao seu aparelho ou a um certificado — não tem código pra alguém te enganar a digitar. Ex.: FIDO2/passkey, Windows Hello, CBA (certificado).
Cenário fala de admin, acesso privilegiado ou dado super sensível? → exija phishing-resistant MFA via authentication strength.
Uma "senha temporária de uso único" que o admin gera pra te ajudar a começar — tipo um crachá de visitante até você fazer o crachá definitivo. Serve pra registrar seu primeiro método forte (FIDO2, Authenticator).
Onboarding de funcionário novo · recuperação quando a pessoa perdeu o celular com o Authenticator.
Bypass permanente de MFA, nem como "remendo" pra Conditional Access mal configurado.
Deixa o usuário resetar a própria senha sozinho (sem ligar pro TI), respondendo a métodos de verificação. Em ambiente híbrido, o password writeback grava a senha nova de volta no servidor local.
Uma "lista de senhas proibidas". Bloqueia senhas óbvias e termos que você define (nome da empresa, do produto). Agentes no servidor local aplicam isso também nos resets feitos lá.
Tem gente usando "Contoso2026!". Só forçar MFA não resolve a raiz — Password Protection com termos banidos impede senhas previsíveis no próximo reset.
O Conditional Access é um porteiro que olha sinais ("quem é, de onde vem, que aparelho, qual risco") e decide o que exigir: SE tais condições, ENTÃO peça MFA / exija aparelho confiável / bloqueie. Ele não faz o login — ele decide se o login precisa de mais garantias.
Users (quem é afetado) · Target resources (o que protege) · Conditions (em que circunstâncias: local, aparelho, risco) · Grant controls (o que exigir: MFA, aparelho compliant) · Session controls (o que limitar depois de entrar: frequência de login, etc.).
Se várias políticas se aplicam ao mesmo login, a pessoa tem que cumprir todas. E se qualquer uma delas disser "Block", o bloqueio ganha — "exigir MFA" não anula um "bloquear".
Teste em report-only antes de ligar, e deixe as contas break-glass de fora de toda política.
Duas contas de emergência fora de todas as políticas de CA, com senha forte guardada offline e muito monitoradas. Servem pra você recuperar o controle se uma política bloquear todo mundo por engano.
Define quais métodos contam como MFA. Pra admin, exija phishing-resistant.
Protege uma ação específica dentro de uma app (ex.: ver um dado sensível), sem exigir o controle extra na app inteira.
Exige esse "contexto" extra pra operações administrativas críticas, como mudar uma política sensível.
O Entra calcula dois tipos de "risco" diferentes — e a resposta certa muda conforme o tipo.
"Esta tentativa de login agora parece estranha?" — ex.: vindo de um país incomum, de um IP suspeito. É sobre o momento do login.
Risco médio → pedir MFA · risco alto → bloquear ou exigir MFA forte.
"Esta conta pode estar comprometida?" — ex.: a senha dela apareceu num vazamento. É sobre a identidade, não sobre um login específico.
Risco alto → exigir troca de senha segura (secure password change).
Normalmente um acesso vale por um tempo. O Continuous Access Evaluation corta o acesso quase na hora quando algo crítico acontece (conta desativada, senha mudada, risco subiu) — sem esperar o token expirar.
"Cola" o token ao aparelho, pra um token roubado não funcionar em outra máquina. Já o sign-in frequency só decide de quanto em quanto tempo pedir login de novo — e não substitui o CAE.
É a forma da Microsoft de proteger o acesso à rede baseado em identidade. Em vez de mandar todo o tráfego pra um ponto central ou abrir a rede toda com VPN, o GSA filtra e controla cada conexão na nuvem, perto do usuário, olhando quem é e em que situação está.
O Entra ID P1 é a base, mas os produtos Internet Access e Private Access são licenciados pela Microsoft Entra Suite. "Licença de menor custo que entrega Private + Internet Access" → Entra Suite (não P1, não P2, não Workload ID).
Um "filtro de internet inteligente" (SWG) que sabe quem é o usuário: bloqueia sites/ameaças no tráfego pra internet e SaaS. Substitui o proxy de terceiros.
O ZTNA: dá acesso a uma app interna específica sem abrir a rede inteira. Substitui a VPN tradicional.
O GSA separa o tráfego em três "canos": Microsoft traffic (Exchange, SharePoint, Teams), Internet (sites/SaaS em geral) e Private Access (apps internas).
O Conditional Access "universal" cobre os túneis Internet e Microsoft. O Private Access NÃO é coberto por ele — cada app privada precisa ser protegida individualmente (mirando a Enterprise Application dela).
Um programinha leve no computador que captura o tráfego e manda pros túneis. A política de CA do GSA só é realmente aplicada com o client.
Sem programa: um túnel IPsec sai do roteador da filial direto pro GSA, levando o tráfego do site todo. Mas atenção: sem o client, a política de CA não é aplicada.
Numa política de CA, exige que a pessoa esteja conectada pelo GSA da empresa. Substitui aquelas listas de IP de saída e o "vai e volta" da VPN. (Não cobre apps de Private Access.)
Faz os logs mostrarem o IP real do usuário, não o IP do serviço GSA. Só vale pra tráfego Microsoft e exige o "signaling" ligado.
Impede a pessoa de usar as credenciais em outros tenants não autorizados (anti-vazamento), marcando o tráfego em qualquer navegador/sistema.
Pra usar Compliant Network, Source IP restoration e CA universal, você liga uma vez o GSA signaling for Conditional Access (em Settings → Session management → Adaptive Access).
Precisa de Global Secure Access Administrator, mais Conditional Access Administrator (pra políticas) ou Security Administrator (pra tenant restrictions).
Aplicações, Enterprise Apps, App Registrations, permissions e consent, roles de aplicação, Application Proxy, managed identities (system vs user-assigned), Key Vault, workload identity federation e Microsoft Defender for Cloud Apps.
Este domínio trata de como aplicações e serviços automatizados recebem identidade no Entra — como uma app prova quem é, o que pode fazer, e como acessa recursos sem um humano clicando. Tudo gira em torno de três objetos. Entenda-os e o resto encaixa.
Os três parecem coisas separadas no portal, mas são três faces do mesmo conceito. A analogia que ajuda: planta → casa → tela de gestão da casa.
A planta da casa. É a definição global e única da app, criada no tenant de origem. Guarda o Application (client) ID, redirect URIs, credenciais (certificados/secrets), API permissions e app roles. Existe uma só por aplicação.
Você registra a "App de Faturas" — isso cria a planta dela no seu tenant.
A casa construída a partir da planta. É a identidade de segurança local da app dentro de um tenant: é ele que recebe permissões, aparece nas atribuições de função e autentica. Uma app usada em 3 tenants tem 1 App Registration e 3 Service Principals.
Ao registrar a app (ou ao dar consent a ela em outro tenant), o Entra cria automaticamente o service principal correspondente.
A tela de gestão da casa. É o nome que o portal dá ao service principal quando você o administra: aqui você configura SSO, atribui usuários/grupos, liga provisioning, aplica Conditional Access e vê os sign-in logs.
Para configurar SSO SAML do Salesforce, você abre a Enterprise Application dele.
Antes de comparar os dois tipos, vale entender o que é uma "permissão" aqui — porque sem isso os nomes tipo Mail.Read não fazem sentido.
Uma app (ex.: um aplicativo de e-mail) não pode simplesmente entrar nos seus dados da Microsoft. Ela precisa de uma autorização específica para cada coisa que quer fazer. Essa autorização é a "permissão". Pense num crachá com etiquetas: cada etiqueta libera uma porta.
Mail.Read?É o nome de uma dessas etiquetas. A Microsoft batiza cada permissão no formato Recurso.Ação. Então Mail.Read = "pode ler e-mails". Outros exemplos: Mail.Send = "pode enviar e-mails", Files.ReadWrite = "pode ler e editar arquivos", User.Read = "pode ver o perfil do usuário". É só uma convenção de nomes — não tem mistério.
Essas permissões pertencem ao Microsoft Graph — a "porta de entrada" única para os dados do Microsoft 365 (e-mail, calendário, arquivos, usuários). Quando uma app quer acessar seu e-mail, ela pede a permissão Mail.Read ao Graph.
Agora a pergunta que separa os dois tipos: tem um usuário logado na hora em que a app age, ou ela trabalha sozinha?
A app age "emprestando" a identidade de um usuário que está logado. Como se você desse seu crachá pra app usar enquanto está do seu lado. Por isso ela nunca consegue mais do que você mesmo conseguiria.
Você abre o app do Outlook no celular e faz login. O app recebe Mail.Read delegado — então ele lê a sua caixa de entrada, porque é você que está ali logado. Ele não consegue ler a caixa de um colega, porque você também não consegue.
Frases como "em nome do usuário", "on-behalf-of" ou "app interativa".
A app age por conta própria, sem ninguém logado — ela tem o próprio crachá. Como não há um usuário para "limitar o alcance", esse crachá costuma ser muito mais poderoso, e por isso precisa da aprovação de um administrador.
Um robô que roda toda madrugada, sem ninguém na frente do computador, fazendo backup dos e-mails de todos os funcionários. Ninguém está logado, então ele usa Mail.Read como application permission — e consegue ler a caixa da empresa inteira.
Frases como "daemon", "serviço de fundo", "job agendado", "tarefa automática", "sem usuário interativo".
.default (um detalhe técnico)"Scope" é só a forma como a app diz ao Graph quais etiquetas ela quer no momento de pedir o acesso (o token). O .default é um atalho que significa: "me dá tudo que já foi aprovado pra mim, não preciso listar uma por uma".
Você não pode misturar o atalho (.default) com um nome de etiqueta específico (Mail.Read) no mesmo pedido — isso dá erro.
.default sozinho ⇒ app sozinha (application) · nome direto como Mail.Read ⇒ com usuário (delegated) · os dois juntos ⇒ erro.
Algumas permissões são tão poderosas que um usuário comum não pode liberá-las sozinho — só um admin. Esse fluxo deixa o usuário pedir aprovação de forma organizada, em vez de ficar mandando e-mail pro TI.
Você quer usar uma ferramenta nova que pede acesso aos arquivos da equipe. Aparece um botão "solicitar aprovação"; o pedido vai pro admin, que aprova ou recusa. Antes de aprovar, ele confere se o fabricante da app é verificado (publisher verification).
Com "usuários podem registrar apps" desligado, é preciso delegar a uma função específica. Global Admin quase nunca é a resposta certa.
A menor função que permite criar app registrations mesmo com o self-service desligado.
Dev precisa registrar apps, mas nada além disso → Application Developer.
Administra todas as apps, enterprise apps, SSO, consent e o Application Proxy.
Administrar apps de ponta a ponta, incluindo publicação on-prem via App Proxy.
Igual à anterior, menos o Application Proxy (que toca infraestrutura on-premises).
Administrar apps em nuvem sem precisar mexer em App Proxy.
O método de SSO depende de como a app fala. Os que mais caem:
SSO clássico para SaaS enterprise e apps legadas com federação.
Salesforce com SSO — configure Identifier, Reply URL, certificado e claims/NameID.
Para apps modernas, APIs e integração por token.
Redirect URI errado e permissões Graph mal configuradas.
Password-based: app sem federação, via cofre de credenciais (menos ideal). Header-based: app legacy atrás de proxy. KCD: App Proxy para app on-prem que usa Kerberos (exige SPN e delegação no AD DS).
Publica apps web on-premises sem abrir inbound no firewall. O Private Network Connector faz conexão outbound, e o Entra pode exigir pre-authentication com Conditional Access antes do tráfego chegar à app.
Publicar uma intranet IIS antiga para acesso externo seguro, com MFA via CA.
Pre-authentication autentica no Entra antes da app; passthrough publica sem pré-auth (use com cuidado). Para apps Windows/IWA, use KCD.
O problema que ela resolve: uma app precisa acessar outro serviço (um cofre de senhas, um storage), mas para isso teria que guardar uma senha em algum lugar — e senha guardada vaza.
É uma identidade que o próprio Azure cria e cuida para um recurso (uma VM, uma function, etc.). Pense num crachá automático: o Azure entrega o crachá pra app, troca ele sozinho quando vence, e você nunca precisa carregar nem guardar uma senha. A app simplesmente "é reconhecida".
Sem ela, você colocaria uma senha dentro do código do app. Se alguém vê o código, vê a senha. Com a managed identity, não existe senha pra vazar — o Azure resolve a autenticação nos bastidores.
Existem dois tipos, e escolher o certo é cobrado na prova (foi uma das suas questões). A diferença é só uma: a identidade pertence a um recurso ou pode ser compartilhada?
O crachá é grudado num único recurso. Nasce com ele e é jogado fora quando o recurso é deletado. É um casamento exclusivo: aquela VM tem aquela identidade, e ponto.
Quando só um recurso precisa da identidade e não há motivo pra compartilhar.
O crachá é um objeto independente que você cria sozinho e pode emprestar pra vários recursos ao mesmo tempo. Ele continua existindo mesmo que os recursos sumam.
"Duas VMs rodam o mesmo app, precisam da mesma identidade, e quero o mínimo de configuração de acesso (RBAC)." → user-assigned. Como é uma identidade só compartilhada, você dá a permissão uma vez. Se fossem duas system-assigned (uma por VM), você teria que dar a permissão duas vezes.
Às vezes a prova não pergunta o conceito — pergunta o comando exato. Não precisa decorar a sintaxe inteira; basta reconhecer o que cada um faz.
az vm identity assign = "ligar uma identidade numa VM" (system por padrão; vira user se você acrescenta --identities). az identity create = "criar uma identidade user-assigned solta". Update-AzVM (PowerShell) = "modificar a VM", inclusive para remover a identidade.
Set-AzVM não remove identidade · Set-ADUser é do AD on-premises (nada a ver) · Set-ServicePrincipal mexe em outra coisa, não na identidade da VM.
# Ligar identidade system-assigned numa VM
az vm identity assign -g meuRG -n minhaVm
# Ligar uma identidade user-assigned já existente
az vm identity assign -g meuRG -n minhaVm --identities minhaIdentidade
# Criar uma identidade user-assigned solta
az identity create -g meuRG -n minhaIdentidade
# Remover identidades de uma VM (PowerShell)
Update-AzVM -ResourceGroupName meuRG -VM $vm -IdentityType NoneO Key Vault é o "cofre" do Azure onde se guardam senhas, chaves e certificados. Veja como uma app pega um segredo de lá sem nunca guardar uma senha.
1) Você liga a managed identity no app. 2) No cofre, você diz "essa identidade pode ler segredos" (uma permissão chamada Key Vault Secrets User). 3) O app pede o segredo e o Azure reconhece o crachá automaticamente. Nenhuma senha foi escrita em lugar nenhum.
Existem dois "RBACs" diferentes (vimos no D1): as Entra roles mandam no diretório (usuários, apps, grupos); o Azure RBAC manda nos recursos (VM, storage, cofre). Dar acesso a um segredo do cofre é Azure RBAC, não Entra role.
Managed identity é ótima pra coisas dentro do Azure. Mas e um robô do GitHub ou um pipeline de automação que vive fora? Em vez de guardar uma senha nele, você cria um acordo de confiança: "eu confio no crachá que o GitHub já emite". Aí o crachá externo é trocado por um crachá do Entra na hora. Zero senhas guardadas.
"CI/CD / pipeline / GitHub Actions precisa autenticar no Entra sem armazenar credencial" → Workload Identity Federation.
Esse é o objetivo 3.4 da prova e caiu bastante no seu teste. A ideia central é simples, mesmo que o nome assuste.
É um "segurança de portaria" para apps em nuvem (o nome técnico é CASB). Ele enxerga quais aplicativos de nuvem as pessoas da empresa estão usando — inclusive os que ninguém autorizou (o chamado Shadow IT, o "TI das sombras") — e dá controle sobre eles.
"Quais apps de nuvem meu pessoal usa de verdade?" · "Essa app é confiável?" · "Consigo impedir que baixem arquivos sigilosos nela?"
É a parte que descobre as apps. Você dá a ele os registros de tráfego da rede (de um firewall, por exemplo), e ele compara com um catálogo de mais de 31.000 apps conhecidas, mostrando o que está em uso, quanto, por quem e o quão arriscado é.
Você sobe um log do firewall e nada aparece, mesmo tendo havido tráfego. Motivo: o formato daquele firewall ainda não é "entendido" pelo sistema. Solução: escolher a fonte de dados como "Outra", o que envia o log para criarem o leitor (parser) dele. (Conectar o Microsoft 365 não tem nada a ver com ler log de firewall.)
Cada app ganha uma nota de 0 a 10, calculada a partir de 90+ fatores agrupados em quatro categorias. A prova cobrou exatamente quais são essas quatro:
General (dados básicos da empresa: domínio, idade, popularidade) · Security (MFA, criptografia, classificação de dados) · Compliance (certificações como HIPAA, ISO 27001, SOC 2) · Legal (privacidade e proteção de dados, ex.: GDPR).
Depois de descobrir, você carimba cada app: sanctioned (aprovada), unsanctioned (bloqueada) ou sem carimbo (em análise). E para controlar o que acontece dentro de uma app já liberada, há dois tipos de política.
Access policy = decide se deixa entrar ou não (com base em usuário, device, local). Session policy = entra junto na sessão e controla ações em tempo real — tipo impedir o download de um arquivo, mas deixar visualizar.
"Impedir download em dispositivo não gerenciado, mas permitir leitura" → session policy (via Conditional Access App Control). Não é política de compliance de device, nem app protection do Intune.
az identity create, anexe-a a duas VMs e dê uma única atribuição RBAC no storage.| Se o cenário fala sobre... | Pense em... | Erro comum |
|---|---|---|
| App rodando sem usuário (daemon/job) | Application permission, service principal ou managed identity | Usar delegated permission |
| Token com todas as permissões de aplicação consentidas | scope .default | Misturar .default com nome de permissão na mesma requisição |
| Objeto criado ao registrar uma app | Service principal (entidade de serviço) | Responder managed identity ou conta de usuário |
| Criar app registrations com self-service desligado (menor privilégio) | Application Developer | Atribuir Global Administrator |
| Vários recursos compartilhando a mesma identidade, minimizando RBAC | Managed identity user-assigned | Usar system-assigned (uma por recurso) |
| Remover managed identities de uma VM (PowerShell) | Update-AzVM ... -IdentityType None | Usar Set-AzVM, Set-ADUser ou Set-ServicePrincipal |
| VM precisa ler dados de um storage | Habilitar Identidade na VM + RBAC no storage | Mexer em Controlo de acesso (IAM) da própria VM |
| Acessar Key Vault sem segredo | Managed Identity + Azure RBAC (Key Vault Secrets User) | Guardar client secret no código |
| Publicar app on-prem sem inbound firewall | Application Proxy com connector outbound | Expor a app diretamente na internet |
| CI/CD autenticar no Entra sem segredo | Workload Identity Federation | Armazenar secret no pipeline |
| Descobrir Shadow IT a partir de logs de tráfego | Cloud Discovery (Defender for Cloud Apps) | Confundir com conector do Microsoft 365 |
| Log de firewall não gera apps no relatório | Selecionar fonte de dados "Outra" (parser) | Subir outro log ou criar conector M365 |
| Impedir download em device não gerenciado, permitindo acesso | Session policy via Conditional Access App Control | Usar device compliance policy ou app protection do Intune |
| Quatro categorias do risk score | General, Security, Compliance, Legal | Trocar "General" por "Privacidade" |
az vm identity assign atribui a identidade (system-assigned por padrão). az identity create cria uma identidade user-assigned autônoma, que é coisa diferente.Update-AzVM modifica a VM e permite remover as identidades gerenciadas. Set-ADUser é do AD on-prem, Set-ServicePrincipal mexe em SP e Set-AzVM não remove identidade..default. Misturar .default com um nome de permissão (opção C) causa erro porque combina consent estático e dinâmico. Mail.Read sozinho é para permissões delegadas.PIM, Access Reviews, Entitlement Management, Access Packages, Lifecycle Workflows, logs, KQL, Zero Trust e Terms of Use.
Governança de identidade é a "faxina e o controle" do acesso: evita gente com permissão demais, convidados que nunca saem e admins poderosos o tempo todo. A regra de ouro: todo acesso deve ter dono, motivo, prazo, aprovação e revisão.
Em vez de alguém andar com o "cargo de admin" o tempo todo (perigoso se a conta for hackeada), a pessoa fica elegível e só ativa o cargo na hora que precisa — como pegar uma chave emprestada na portaria e devolver depois. A ativação pode exigir MFA, justificativa, ticket, aprovação e tem prazo pra expirar.
Eligible = pode ativar quando precisar (o ideal pra acesso ocasional) · Active = está com o poder agora · Permanent = sem prazo (evite pra cargos altos) · Time-bound = com início e fim definidos.
O mesmo conceito de "ativar temporariamente", mas aplicado a entrar num grupo (ou ser dono dele) — útil quando o grupo dá acesso a recursos ou app roles.
Se o grupo é role-assignable (lembra do D1?), virar membro dele pode significar receber privilégio de admin.
"Essa pessoa ainda precisa desse acesso?" De tempos em tempos, o sistema pergunta a alguém (o gestor, o dono da app, ou a própria pessoa) se cada acesso ainda faz sentido — e remove o que ninguém confirma.
Convidados de um projeto → review recorrente que remove automático quem não responde · Admins elegíveis no PIM → review de cargos privilegiados · Grupo de uma app → review com o dono da app (ele sabe quem ainda precisa).
Pense num "cardápio de acessos". Você monta pacotes prontos que as pessoas podem pedir, com aprovação e prazo automáticos — sem o TI ter que adicionar cada um na mão.
Catalog = a despensa de recursos · Resources = os itens (grupos, Teams, apps, sites) · Access Package = o "combo" que a pessoa pede · Policy = as regras (quem pode pedir, aprovação, duração, revisão).
Parceiros externos cadastrados que podem pedir os pacotes de acesso — governança para colaboração B2B.
Automatizam o ciclo de vida (entrada/mudança/saída) com base em datas de RH (ex.: employeeHireDate): mandam e-mail de boas-vindas, adicionam a grupos, removem licenças, desativam a conta na saída.
Sign-in logs respondem "quem tentou entrar, de onde, em qual app, e deu certo?". Audit logs respondem "quem mudou o quê no diretório?". A maioria das investigações começa escolhendo um desses dois.
SigninLogs (logins de usuários) · AuditLogs (mudanças admin) · ServicePrincipalSignInLogs e ManagedIdentitySignInLogs (logins de apps/identidades) · AADProvisioningLogs (provisionamento).
Sozinho, o portal guarda os logs por pouco tempo. Ligando o Diagnostic Settings, você manda tudo pra um Log Analytics Workspace — aí pode consultar com a linguagem KQL, criar alertas e gráficos (workbooks).
Não precisa decorar KQL, mas reconhecer a estrutura ajuda: você nomeia a tabela e vai "filtrando" com |.
// Falhas de login nos últimos 7 dias
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType != 0
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, ResultDescription
| order by TimeGenerated desc// Logins bloqueados por Conditional Access
SigninLogs
| where TimeGenerated > ago(14d)
| where ConditionalAccessStatus == "failure"
| project TimeGenerated, UserPrincipalName, AppDisplayName, ConditionalAccessStatus"Nunca confie de cara" — sempre cheque identidade, local, aparelho, risco e método antes de liberar.
"Só o mínimo necessário" — RBAC enxuto, PIM, access packages, prazos e revisões.
"Aja como se já tivesse sido invadido" — logs, alertas, CAE, token protection e segmentação.
Exige que a pessoa aceite um termo (uso aceitável, confidencialidade) antes de acessar — aplicado pelo Conditional Access e registrado pra auditoria. Útil pra acesso de convidados e compliance regional.
| Se o cenário fala sobre... | Pense em... | Erro comum |
|---|---|---|
| Reduzir privilégio permanente / elevação temporária | PIM (eligible + ativação) | Manter role permanente ativa |
| Confirmar se acesso ainda é necessário | Access Reviews | Confiar só em remoção manual |
| Acesso self-service governado por 90 dias | Entitlement Management / access package | Adicionar ao grupo na mão |
| Automatizar onboarding/offboarding por atributo | Lifecycle Workflows | Processo manual de JML |
| Consultar logs com KQL e criar alertas | Diagnostic Settings → Log Analytics | Depender da retenção padrão do portal |
Consulta rápida antes dos quizzes e na revisão final. A prova mistura siglas parecidas para testar se você reconhece o recurso e o cenário corretos.
Use depois de estudar cada domínio. O ideal é uma rodada mista, revisar as erradas e repetir só os domínios com menor pontuação.
Complementa os quizzes deste guia e pode ser usado como simulado completo, revisão por domínio ou treino de erros.
Use para validar detalhes técnicos e acompanhar mudanças da certificação.