Laboratório Técnico: Manage Built-in Azure Roles
Questões
Questão 1 — Múltipla Escolha
Uma equipe de desenvolvimento precisa ler e listar recursos em uma assinatura do Azure, mas não pode modificar nenhum recurso nem gerenciar acessos. O administrador considera atribuir uma das seguintes roles.
Qual role built-in atende exatamente a esse requisito sem conceder permissões além do necessário?
A) Contributor
B) Reader
C) Owner
D) User Access Administrator
Questão 2 — Cenário Técnico
Um administrador executa o seguinte comando para verificar as permissões de um usuário:
az role assignment list --assignee user@contoso.com --all
O retorno mostra que o usuário tem a role Contributor atribuída no escopo da assinatura. No entanto, ao tentar deletar um recurso em um resource group específico, o usuário recebe erro de autorização.
Qual é a causa mais provável desse comportamento?
A) A role Contributor não inclui permissão de deleção de recursos por padrão
B) Existe um deny assignment aplicado no escopo do resource group que bloqueia a ação
C) A role Contributor atribuída na assinatura não se propaga para resource groups filhos
D) O token de autenticação do usuário expirou e precisa ser renovado
Questão 3 — Verdadeiro ou Falso
A role Owner concede todas as permissões sobre os recursos do escopo atribuído, incluindo a capacidade de atribuir roles a outros usuários, e essa combinação de permissões não pode ser restringida por nenhum mecanismo nativo do Azure RBAC.
Verdadeiro ou Falso?
Questão 4 — Cenário Técnico
Uma organização precisa que um serviço externo gerencie atribuições de acesso dentro de um resource group específico, mas sem ter permissão para criar, modificar ou deletar recursos nesse group.
O administrador considera as seguintes roles built-in:
| Role | Gerencia atribuições de role? | Modifica recursos? |
|---|---|---|
| Owner | Sim | Sim |
| Contributor | Não | Sim |
| User Access Administrator | Sim | Não |
| Reader | Não | Não |
Qual role deve ser atribuída para atender ao requisito com o menor privilégio possível?
A) Owner, com escopo restrito ao resource group
B) Contributor, pois permite gerenciar membros do grupo
C) User Access Administrator, com escopo restrito ao resource group
D) Reader combinada com Contributor no mesmo escopo
Questão 5 — Múltipla Escolha
Ao atribuir uma role built-in no Azure, o escopo de atribuição mais amplo disponível na hierarquia padrão de recursos é:
A) Resource Group
B) Subscription
C) Management Group
D) Tenant Root Group
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
A role Reader concede permissões exclusivamente de leitura (*/read) sobre todos os recursos no escopo atribuído, sem nenhuma capacidade de escrita, deleção ou gerenciamento de acesso. É a escolha que aplica o princípio do menor privilégio para esse cenário.
O principal equívoco representado pelos distratores é a confusão entre roles que incluem leitura como subconjunto de permissões mais amplas. Contributor permite leitura e escrita, mas não gerenciamento de acesso. Owner inclui tudo, inclusive gerenciamento de acesso. User Access Administrator foca em gerenciar atribuições de roles, não em ler recursos de forma geral. Escolher Contributor, por exemplo, expõe recursos a modificações acidentais ou intencionais, violando o requisito de somente leitura.
Gabarito — Questão 2
Resposta: B
O Azure RBAC suporta deny assignments, que bloqueiam explicitamente ações específicas independentemente das roles atribuídas. Um deny assignment aplicado no resource group prevalece sobre a role Contributor herdada da assinatura, pois permissões de negação têm precedência sobre permissões de concessão na avaliação do Azure RBAC.
A alternativa C representa um equívoco frequente: roles atribuídas em escopos pai são herdadas por escopos filhos, portanto Contributor na assinatura se aplica sim ao resource group. A alternativa A é incorreta porque Contributor inclui */write e */delete (exceto sobre roles e políticas). A alternativa D é tecnicamente possível em qualquer cenário, mas não é a causa mais provável descrita no enunciado e não explica um erro persistente de autorização.
Gabarito — Questão 3
Resposta: Falso
A afirmação é falsa. Embora Owner conceda permissões completas incluindo gerenciamento de acesso, esse conjunto de permissões pode ser restringido por mecanismos nativos do Azure, como deny assignments e Azure Policy. Deny assignments podem bloquear ações específicas mesmo para um Owner no escopo afetado. Além disso, no contexto do Microsoft Entra PIM, a ativação da role Owner pode ser condicionada a aprovações e janelas de tempo, limitando seu exercício na prática.
O erro conceitual que a afirmação induz é tratar Owner como um privilégio absoluto e irrestrito, quando na realidade o modelo de autorização do Azure tem camadas que podem sobrepor-se às atribuições de role.
Gabarito — Questão 4
Resposta: C
A role User Access Administrator concede exclusivamente a permissão Microsoft.Authorization/*/write, que permite criar e gerenciar atribuições de roles, sem incluir permissões para criar, modificar ou deletar recursos do plano de dados ou de controle fora do escopo de autorização. Atribuída no escopo do resource group, limita sua atuação a esse contexto específico.
Owner atenderia o requisito funcional, mas viola o princípio do menor privilégio ao incluir permissões sobre recursos. Contributor não gerencia atribuições de roles, portanto não atende ao requisito funcional. Combinar Reader com Contributor não faz sentido porque Contributor já inclui as permissões de Reader, e nenhuma das duas gerencia atribuições.
Gabarito — Questão 5
Resposta: C
O escopo mais amplo na hierarquia de recursos do Azure disponível para atribuição de roles é o Management Group. A hierarquia, do mais amplo ao mais restrito, é: Management Group > Subscription > Resource Group > Resource.
A alternativa D, Tenant Root Group, é tecnicamente o Management Group raiz do tenant e representa o topo absoluto da hierarquia, mas não é um tipo de escopo distinto nas opções de atribuição de roles: ele é um Management Group como qualquer outro. A confusão entre Subscription e Management Group é o equívoco mais comum nessa questão, pois muitos ambientes pequenos não utilizam Management Groups, levando à percepção incorreta de que a assinatura é o escopo máximo.