Laboratório de Troubleshooting: Configure resource locks
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um administrador júnior reporta que não consegue deletar uma Virtual Machine chamada vm-app-prod-01, mesmo tendo a role Owner atribuída diretamente na subscription. O ambiente de produção usa três resource groups: rg-app, rg-network e rg-storage. A VM está no rg-app.
O administrador executa o seguinte comando para investigar:
az vm delete --name vm-app-prod-01 --resource-group rg-app --yes
A saída retornada é:
(ScopeLocked) The scope '/subscriptions/a1b2c3d4.../resourceGroups/rg-app/
providers/Microsoft.Compute/virtualMachines/vm-app-prod-01'
cannot perform delete operation because following scope(s) are locked:
'/subscriptions/a1b2c3d4.../resourceGroups/rg-app'.
Please remove the lock and try again.
O administrador verifica os locks diretamente na VM pelo portal e não encontra nenhum lock listado no recurso. Ele também confirma que a VM está em estado Running e que o disco OS tem 128 GB, sem snapshots recentes.
Qual é a causa raiz da falha?
A) A role Owner foi atribuída na subscription, mas não propagou corretamente para o resource group rg-app, impedindo a operação.
B) Existe um lock aplicado no resource group rg-app que está sendo herdado pela VM, mas não aparece na visualização de locks do recurso individual.
C) A VM está em estado Running e o Azure impede exclusões de VMs ativas sem o parâmetro --force.
D) O disco OS de 128 GB possui um lock implícito aplicado automaticamente pelo Azure quando não há snapshots recentes.
Cenário 2 — Decisão de Ação
A equipe de segurança identificou que um lock ReadOnly aplicado no resource group rg-dados-sensiveis está impedindo a execução de um job agendado de backup. O job utiliza a API do Azure para criar snapshots dos discos gerenciados contidos nesse resource group.
A causa foi confirmada: a operação de criação de snapshot é bloqueada pelo lock ReadOnly porque é classificada como escrita no ARM.
O ambiente possui as seguintes restrições:
- O resource group contém dados regulados por política interna de compliance
- O horário do job de backup é entre 02h00 e 03h00 UTC, e já se iniciou
- Remover o lock exige aprovação de dois membros da equipe de segurança, conforme política interna
- A aprovação do segundo membro de segurança está pendente há 20 minutos
Qual é a ação correta a tomar neste momento?
A) Remover o lock imediatamente com as credenciais disponíveis, executar o backup e reaplicar o lock, documentando a exceção posteriormente.
B) Aguardar a aprovação pendente do segundo membro conforme a política, mesmo que o job de backup falhe neste ciclo.
C) Alterar o tipo do lock de ReadOnly para Delete para permitir a criação de snapshots sem remover a proteção contra exclusões.
D) Criar os snapshots manualmente via portal, pois locks não se aplicam a operações iniciadas pelo portal, apenas por API.
Cenário 3 — Causa Raiz
Uma engenheira de infraestrutura tenta mover o resource group rg-legacy para outra subscription usando o portal do Azure. A operação falha. Ela verifica as permissões e confirma que possui a role Contributor tanto na subscription de origem quanto na de destino.
A engenheira também verifica que o rg-legacy contém 12 recursos, incluindo VMs, discos e uma conta de armazenamento. Todos os recursos estão em estado saudável. A conta de armazenamento tem replicação GRS ativada.
Ao tentar iniciar a movimentação, o portal exibe:
Move operation failed.
One or more resources in the source resource group have locks
that prevent the move operation.
Resource: /subscriptions/.../resourceGroups/rg-legacy/
providers/Microsoft.Storage/storageAccounts/stlegacyprod
Lock: lock-storage-readonly (ReadOnly)
A engenheira acredita que o problema é a replicação GRS, que tornaria a movimentação mais complexa, e abre um ticket para desativar a replicação antes de tentar novamente.
Qual é a causa raiz do problema?
A) A role Contributor não tem permissão para iniciar movimentações entre subscriptions; é necessária a role Owner em ambas.
B) A replicação GRS na conta de armazenamento impede movimentações entre subscriptions, pois cria dependências de região.
C) Um lock ReadOnly aplicado diretamente na conta de armazenamento está bloqueando a operação de movimentação, que é classificada como escrita pelo ARM.
D) O resource group possui recursos demais para uma movimentação única; o Azure limita movimentações a no máximo 10 recursos por operação.
Cenário 4 — Impacto Colateral
Durante uma janela de manutenção planejada, um administrador precisava redimensionar um conjunto de recursos dentro do resource group rg-infra-core. O resource group tinha um lock ReadOnly aplicado, que estava impedindo todas as operações de escrita.
Para resolver o problema rapidamente, o administrador removeu o lock ReadOnly do resource group e realizou o redimensionamento com sucesso.
Qual consequência secundária essa ação pode ter causado durante o intervalo em que o lock estava removido?
A) Os recursos do resource group ficaram temporariamente inacessíveis para leitura por outros usuários, pois a remoção de um ReadOnly lock causa uma interrupção momentânea no plano de gerenciamento.
B) Qualquer usuário com permissões de escrita na subscription pôde excluir, modificar ou reconfigurar qualquer recurso do resource group durante o intervalo sem o lock.
C) O Azure registrou uma violação de compliance automática e suspendeu a subscription até que o lock fosse reaplicado.
D) Os locks aplicados diretamente nos recursos filhos do resource group foram removidos automaticamente junto com o lock do resource group pai.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A mensagem de erro é a pista central e deve ser lida com atenção. Ela informa explicitamente que o escopo bloqueado é o resource group rg-app, não a VM em si. Locks aplicados em um resource group são herdados pelos recursos contidos nele, mas essa herança não aparece na visualização de locks do recurso individual no portal. O recurso filho não exibe locks herdados, apenas locks aplicados diretamente a ele.
A informação sobre o estado Running da VM e o tamanho do disco de 128 GB são propositalmente irrelevantes e foram incluídas para distrair. O Azure não impede exclusão de VMs ativas por padrão, e não existe conceito de lock implícito baseado em ausência de snapshot.
O distrator mais perigoso é A, pois simula um problema de permissão, que levaria o administrador a investigar o RBAC e perder tempo em vez de verificar os locks do resource group pai. O erro conceitual coletivo dos distratores é confundir o sintoma (operação negada) com causas de RBAC, estado do recurso ou características técnicas irrelevantes.
Gabarito — Cenário 2
Resposta: B
A causa já está identificada no enunciado. A decisão correta é determinada pelas restrições do contexto, não pela solução técnica mais rápida. A política interna exige aprovação de dois membros de segurança para remover o lock. Essa restrição é vinculante independentemente do impacto operacional. Falhar em um ciclo de backup é um impacto recuperável; violar uma política de compliance em um resource group com dados regulados pode ter consequências disciplinares e auditáveis.
A alternativa A representa a ação tecnicamente correta aplicada ignorando uma restrição crítica de processo. A alternativa C está errada porque um lock Delete não permitiria criação de snapshots, que é uma operação de escrita bloqueada apenas pelo ReadOnly. A alternativa D está errada porque locks se aplicam a todas as operações no plano de gerenciamento, independentemente da interface utilizada: portal, CLI, PowerShell ou API.
O distrator mais perigoso é A, pois parece pragmático e resolve o problema imediato, mas ignora deliberadamente um controle de segurança estabelecido para aquele ambiente específico.
Gabarito — Cenário 3
Resposta: C
A mensagem de erro exibida pelo portal entrega a causa com precisão: um lock ReadOnly está aplicado diretamente na conta de armazenamento stlegacyprod, e esse lock está bloqueando a operação de movimentação. Mover um recurso entre subscriptions é uma operação de escrita no ARM (POST), bloqueada por qualquer lock ReadOnly ativo no recurso ou em seu escopo pai.
A informação sobre replicação GRS é propositalmente irrelevante e representa exatamente o tipo de detalhe técnico plausível que pode desviar o diagnóstico. A engenheira cometeu o erro clássico de focar em uma característica do recurso ao invés de ler a mensagem de erro com atenção.
O distrator B é o mais perigoso porque levaria a uma ação desnecessária: desativar a replicação GRS não resolveria o problema, custaria tempo e potencialmente reduziria a resiliência da conta de armazenamento durante o período sem lock. O distrator D é falso: o Azure suporta até 800 recursos por operação de movimentação, tornando o limite de 12 recursos completamente irrelevante.
Gabarito — Cenário 4
Resposta: B
Locks não são um controle de autenticação nem de autorização. Eles são uma camada adicional de proteção que se sobrepõe ao RBAC. Ao remover o lock ReadOnly, o administrador restaurou o estado padrão de controle de acesso, onde qualquer usuário com permissões de escrita na subscription pode executar qualquer operação permitida por sua role nos recursos do resource group. Durante o intervalo sem o lock, nenhuma proteção adicional contra exclusão ou modificação acidental estava ativa.
A alternativa A é falsa: remover um ReadOnly lock não interrompe operações de leitura. A alternativa C é falsa: o Azure não suspende subscriptions automaticamente por remoção de locks. A alternativa D é falsa e representa uma confusão com o comportamento de herança: locks filhos são independentes e não são afetados pela remoção de locks no escopo pai.
O impacto real e relevante é que a janela sem lock é um período de risco operacional genuíno, especialmente em ambientes com múltiplos administradores ou automações que aguardam permissão para executar operações. A boa prática é minimizar esse intervalo ao máximo.
Árvore de Troubleshooting: Configure resource locks
Legenda de cores:
- Azul escuro: sintoma ou ponto de entrada do diagnóstico
- Azul médio: pergunta diagnóstica objetiva
- Vermelho: causa identificada
- Verde: ação recomendada ou resolução
- Laranja: validação ou verificação intermediária
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o comportamento bloqueado ou inesperado. Responda cada pergunta diagnóstica com base no que é observável no ambiente: a mensagem de erro, o escopo do lock, o tipo da operação e as permissões disponíveis. Cada caminho termina em uma causa identificada seguida de uma ação concreta. Se a ação não resolver o problema, retorne ao nó de validação e reinicie o percurso com as novas informações obtidas.