Laboratório Técnico: Assign roles at different scopes
Questões
Questão 1 — Múltipla Escolha
Uma equipe de auditoria precisa visualizar todos os recursos de uma assinatura Azure, mas não deve ter permissão de leitura em nenhum grupo de gerenciamento acima dela. Um administrador atribui a função Reader diretamente na assinatura.
Qual é o comportamento esperado dessa atribuição em relação aos resource groups e recursos contidos na assinatura?
A) A função se aplica apenas à assinatura em si; resource groups e recursos exigem atribuições separadas.
B) A função se propaga para todos os resource groups e recursos contidos na assinatura por herança de escopo.
C) A função se propaga apenas para os resource groups, mas não para os recursos individuais dentro deles.
D) A função exige que o role assignment seja replicado manualmente em cada resource group para ter efeito.
Questão 2 — Cenário Técnico
Um administrador executa o seguinte comando:
az role assignment create \
--assignee "dev@contoso.com" \
--role "Contributor" \
--scope "/subscriptions/aaaa-bbbb/resourceGroups/rg-producao"
Dias depois, a equipe relata que o usuário dev@contoso.com consegue criar recursos dentro de rg-producao, mas também consegue visualizar e listar recursos em outros resource groups da mesma assinatura, sem que nenhuma outra atribuição tenha sido feita para ele.
Qual é a causa mais provável desse comportamento?
A) A função Contributor concede permissões implícitas de leitura em toda a assinatura por padrão.
B) O usuário possui uma atribuição de função em um escopo superior, como a própria assinatura ou um grupo de gerenciamento.
C) O comando az role assignment create propaga automaticamente as permissões para o escopo pai.
D) A função Contributor atribuída em um resource group herda permissões de leitura dos resource groups irmãos.
Questão 3 — Verdadeiro ou Falso
Uma atribuição da função Owner feita no escopo de um management group concede permissão para o usuário atribuir funções a outros usuários em qualquer assinatura contida nesse management group, inclusive em resource groups e recursos individuais dessas assinaturas.
Verdadeiro ou Falso?
Questão 4 — Cenário Técnico
Uma organização possui a seguinte hierarquia:
Management Group: MG-Corp
└── Subscription: Sub-Financeiro
├── Resource Group: rg-relatorios
└── Resource Group: rg-dados
O usuário ana@contoso.com possui a função Reader atribuída em MG-Corp. O administrador decide também atribuir a função Contributor a ana@contoso.com diretamente em rg-relatorios.
Qual é o conjunto efetivo de permissões de ana@contoso.com dentro de rg-relatorios?
A) Apenas Reader, pois atribuições em escopo superior sempre prevalecem sobre escopos inferiores.
B) Apenas Contributor, pois a atribuição mais específica substitui a mais ampla.
C) A combinação de Reader e Contributor, resultando nas permissões de ambas as funções aplicadas simultaneamente.
D) Nenhuma das duas, pois atribuições conflitantes em escopos diferentes se anulam mutuamente.
Questão 5 — Múltipla Escolha
Um administrador precisa garantir que um service principal tenha permissão para implantar recursos apenas dentro de um único resource group, sem qualquer acesso a outros resource groups ou à assinatura. Ele também precisa que essa restrição seja auditável e reversível.
Qual abordagem atende corretamente a esses requisitos?
A) Atribuir a função Contributor na assinatura e usar uma policy de negação para bloquear os demais resource groups.
B) Atribuir a função Contributor diretamente no resource group alvo, sem atribuições em escopos superiores.
C) Atribuir a função Owner no resource group alvo para garantir controle total e auditabilidade.
D) Atribuir a função Contributor na assinatura com uma condição ABAC que filtra por resource group.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O Azure RBAC utiliza herança de escopo descendente. Uma atribuição feita em um escopo pai se propaga automaticamente para todos os escopos filhos. Como a hierarquia é management group > subscription > resource group > resource, uma função atribuída na assinatura é herdada por todos os resource groups e por todos os recursos individuais dentro dela.
O principal erro dos distratores A, C e D está em supor que a herança é parcial ou inexistente. O Azure RBAC não exige replicação manual; a propagação é automática e completa para todos os descendentes do escopo onde a atribuição foi feita.
Gabarito — Questão 2
Resposta: B
O comando atribui Contributor apenas no escopo de rg-producao. Essa função não concede nenhuma permissão em outros resource groups nem na assinatura. O comportamento descrito, leitura em outros resource groups sem atribuição explícita, é um indicador claro de que existe uma atribuição em um escopo superior que está sendo herdada.
As alternativas A e D descrevem comportamentos que não existem no modelo RBAC do Azure. A alternativa C inverte a direção da herança: atribuições propagam para baixo na hierarquia, nunca para cima. Investigar atribuições em escopos ancestrais é o primeiro passo de diagnóstico correto neste cenário.
Gabarito — Questão 3
Verdadeiro
A função Owner inclui a ação Microsoft.Authorization/roleAssignments/write, que permite criar e remover atribuições de função. Quando concedida em um management group, essa permissão é herdada por toda a hierarquia abaixo, incluindo assinaturas, resource groups e recursos individuais.
O ponto não óbvio aqui é que a capacidade de delegar funções não está restrita ao escopo onde Owner foi atribuída: o usuário pode criar atribuições em qualquer escopo filho, o que representa um vetor significativo de escalada de privilégio se não for controlado com Microsoft Entra Privileged Identity Management (PIM) ou políticas de governança.
Gabarito — Questão 4
Resposta: C
O Azure RBAC é aditivo: as permissões efetivas de um usuário em qualquer escopo são a união de todas as funções atribuídas a ele naquele escopo e em todos os escopos ancestrais. Não existe conceito de substituição ou cancelamento entre funções no RBAC padrão.
Portanto, ana@contoso.com acumula Reader (herdado de MG-Corp) e Contributor (atribuído diretamente em rg-relatorios), resultando nas permissões combinadas de ambas dentro desse resource group. A única exceção a esse modelo aditivo são as deny assignments, que não estão presentes neste cenário.
Gabarito — Questão 5
Resposta: B
Atribuir Contributor diretamente no resource group alvo é a forma canônica de restringir o escopo de atuação de um principal. O RBAC do Azure segue o princípio do menor privilégio por design de escopo: ao atribuir no nível mais baixo necessário, nenhuma permissão é concedida em escopos irmãos ou superiores. Role assignments são registrados no log de atividades do Azure, o que atende ao requisito de auditabilidade, e podem ser removidos a qualquer momento, atendendo à reversibilidade.
A alternativa A introduz complexidade desnecessária e depende de deny assignments ou Azure Policy, que são mecanismos adicionais. A alternativa C excede o privilégio necessário ao conceder capacidade de gerenciar permissões. A alternativa D descreve o uso de condições ABAC, que são uma funcionalidade avançada para cenários específicos de atributos, não o mecanismo padrão para restrição de escopo.