APRENDER. PRATICAR. EVOLUIR.1. Identificar a operação antes de pedir acesso
Uma equipa fictícia de suporte vai receber uma aplicação de fundos. A pessoa que gere utilizadores no diretório precisa agora de consultar configurações de máquinas virtuais. A role Microsoft Entra usada no diretório não concede automaticamente esse acesso a recursos Azure. Regista a operação pretendida, a identidade e o âmbito. Para leitura de configuração, avalia Reader no âmbito necessário; para outras ações, identifica permissões próprias. Distingue ainda a configuração de um serviço dos dados guardados nesse serviço. Um pedido de acesso bem definido permite rever a necessidade sem distribuir Owner por conveniência. O projeto deve conseguir explicar quem aprova o acesso e como o suporte comprova que consegue executar a tarefa autorizada.
2. Interpretar roles e autenticação
Uma identidade pode iniciar sessão e não ter permissão para modificar um recurso. Autenticação e autorização respondem a perguntas diferentes. MFA acrescenta proteção à verificação de identidade; o seu registo não atribui roles. Contributor permite gerir recursos no âmbito aplicável, mas não atribuir roles Azure RBAC. Se o suporte precisa de conceder acesso a outra pessoa, envolve uma identidade com autorização própria para essa tarefa. Conditional Access permite aplicar controlos segundo sinais do acesso, como identidade, dispositivo ou localização. Nenhum destes conceitos justifica remover os restantes controlos. Na reunião de passagem, usa uma matriz simples de função, operação e âmbito para tornar as responsabilidades compreensíveis.
3. Dar identidade à aplicação
Um processo batch precisa de consultar um serviço que suporta autenticação Microsoft Entra. Uma managed identity permite obter tokens sem a equipa gerir uma palavra-passe da aplicação. Continua a ser necessário autorizar essa identidade no destino. No exercício, o token é obtido com êxito e a autorização falta; distribuir uma chave administrativa contornaria o desenho sem resolver a atribuição em falta. A aplicação deve usar a identidade prevista e o serviço deve suportar o mecanismo. Este exemplo complementa os fundamentos de identidade, sem exigir configuração detalhada de SDKs no AZ-900. Para a transição operacional, documenta a identidade, a dependência e quem pode rever o acesso quando muda a necessidade do batch.
4. Distinguir prevenção e correção
O projeto recebe uma regra que limita localizações de recursos. Uma Azure Policy com Deny pode impedir pedidos abrangidos de criação ou atualização que violem a regra. Ao avaliar recursos existentes, assinala os não conformes; não migra nem elimina esses recursos por esse simples facto. A equipa precisa de inventário, responsável e plano para tratar a situação anterior. Uma janela de correção pode exigir coordenação com negócio, operação e arquitetura. Aprovar funcionalmente uma entrega não altera o efeito técnico da policy. Nesta aula, assume que a atribuição é aplicável e está em modo de imposição; exceções, âmbitos e parâmetros devem ser analisados quando se avalia uma configuração real.
5. Separar locks e classificação por tags
CanNotDelete protege contra eliminações de gestão abrangidas, mantendo modificações autorizadas. ReadOnly acrescenta restrições de atualização e pode interferir com operações que uma equipa considera rotineiras. Confirma sempre o tipo de pedido e o plano em que atua; um lock de gestão não é uma garantia universal sobre todos os dados. Já uma tag como centro=FUNDOS classifica recursos. Aplicá-la a um grupo não a copia automaticamente para os recursos desse grupo. Para classificar recursos, aplica tags ou configura um mecanismo adequado. Não confundas essas tags reais com capacidades de herança ou agrupamento em relatórios de custos. Na entrega, verifica uma amostra de recursos e identifica quem mantém a classificação.
6. Preparar governação de um ambiente híbrido
Nem todos os servidores de uma aplicação migram na mesma fase. Azure Arc pode integrar recursos externos suportados em capacidades de gestão e governação Azure, mantendo a localização desses recursos. A existência de um resource group ou de conectividade não configura por si só esta integração. Na reunião, distingue inventário, ligação, gestão e alojamento. O gestor de projeto deve identificar o que fica local, quem mantém agentes ou extensões relevantes e como se valida a integração acordada. O objetivo do exercício é reconhecer a finalidade de Arc, sem apresentar uma instalação executada. Fecha a passagem com operações de suporte definidas, acesso aprovado e evidência adequada ao requisito, em vez de depender apenas do nome do serviço escolhido.
Uma operadora com Contributor altera a configuração da aplicação, mas não consegue conceder Reader a um colega. A ação seguinte é envolver o responsável autorizado pela gestão de acesso no âmbito necessário.
Armadilhas comuns
Confundir MFA com permissão, Contributor com gestão de acesso, Deny com migração automática ou tags de grupo com tags reais dos recursos.
Tópicos relacionados: Microsoft Entra e RBAC · Policy, locks e tags · Operação híbrida com Azure Arc
Identifica a operação e aplica o controlo correspondente: autenticação, autorização, configuração permitida, proteção de gestão e classificação têm responsabilidades próprias.
Referência: Azure roles and Microsoft Entra roles · AZ-900 skills measured July 20, 2026