Laboratório de Troubleshooting: Create an Azure Backup vault
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um administrador relata que, ao tentar configurar uma política de backup para um Azure Disk gerenciado, o portal do Azure não exibe o vault recém-criado na lista de vaults disponíveis para associação. O administrador confirma que o vault existe, está visível no grupo de recursos e não apresenta nenhum alerta de integridade.
O ambiente possui as seguintes características:
| Atributo | Valor |
|---|---|
| Tipo do vault | Recovery Services vault |
| Região do vault | Brazil South |
| Região do Azure Disk | Brazil South |
| Redundância configurada | LRS |
| Grupo de recursos | rg-backup-prod |
| Permissão do administrador | Contributor no grupo de recursos |
O administrador verificou as permissões do próprio usuário e confirmou que possui acesso de Contributor ao grupo de recursos. A redundância LRS foi escolhida por decisão da equipe de arquitetura para reduzir custos, e essa configuração foi aprovada. Nenhuma política de bloqueio de recursos está ativa no grupo de recursos.
Qual é a causa raiz pela qual o vault não aparece como opção disponível para proteger o Azure Disk?
A) A permissão Contributor não é suficiente para associar datasources a um vault; é necessária a função Backup Contributor.
B) O vault criado é do tipo Recovery Services vault, que não suporta Azure Disks como datasource; apenas o Backup vault suporta esse tipo de carga de trabalho.
C) A redundância LRS impede a associação de datasources do tipo Azure Disk, pois esse tipo de carga de trabalho exige no mínimo ZRS.
D) O vault e o Azure Disk estão em grupos de recursos diferentes, o que bloqueia a associação por padrão.
Cenário 2 — Decisão de Ação
A equipe de operações identificou que um Backup vault de produção está com a opção de Soft Delete desabilitada. Um analista de segurança abriu um chamado urgente solicitando a habilitação imediata do recurso, argumentando que sem ele qualquer exclusão acidental de uma instância de backup se torna permanente e irrecuperável.
O contexto operacional atual é o seguinte:
- O vault protege atualmente 47 instâncias de backup ativas de blobs do Azure
- Há um job de backup em execução no momento para 3 dessas instâncias
- A habilitação do Soft Delete não exige janela de manutenção e não interrompe jobs em andamento
- A equipe de segurança possui prazo de auditoria em 2 horas e precisa registrar a conformidade
- O administrador possui permissão de Owner no vault
Qual é a ação correta a tomar neste momento?
A) Aguardar a conclusão dos 3 jobs em andamento antes de habilitar o Soft Delete, pois modificar configurações do vault durante jobs ativos pode corromper os pontos de recuperação.
B) Habilitar o Soft Delete imediatamente, pois a operação não interrompe jobs em andamento e resolve a vulnerabilidade sem impacto operacional.
C) Criar um novo Backup vault com Soft Delete habilitado e migrar as 47 instâncias para ele antes do prazo da auditoria.
D) Abrir um chamado com o suporte da Microsoft para habilitar o Soft Delete remotamente, pois essa configuração não pode ser alterada após a criação do vault.
Cenário 3 — Causa Raiz
Um administrador criou um Backup vault e configurou com sucesso uma política de backup para um Azure Database for PostgreSQL Flexible Server. No entanto, ao verificar o painel de jobs no dia seguinte, observa a seguinte saída:
Job Name: BackupJob-pg-flexserver-prod
Datasource: pg-flexserver-prod (PostgreSQL Flexible Server)
Status: Failed
Error Code: UserErrorMissingRequiredPermissions
Error Message: The backup extension does not have the required permissions
to access the datasource. Ensure the vault's managed identity
has been granted the necessary roles on the datasource.
Start Time: 2025-11-14T03:00:00Z
Duration: 00:02:17
Policy Applied: policy-pg-daily
O administrador verifica e confirma que:
- A política
policy-pg-dailyestá corretamente configurada com retenção de 30 dias - O servidor PostgreSQL está em execução e acessível
- O vault está na mesma região do servidor
- O grupo de recursos do servidor tem um lock do tipo Read-Only aplicado por outra equipe
- O vault foi criado com a opção de identidade gerenciada habilitada
Qual é a causa raiz da falha no job de backup?
A) O lock de Read-Only no grupo de recursos do servidor impede que o serviço de backup acesse os dados para leitura.
B) A identidade gerenciada do vault não recebeu as roles necessárias no recurso do servidor PostgreSQL para que o serviço de backup possa executar a operação.
C) A política policy-pg-daily foi aplicada antes de o vault concluir o processo de registro interno do datasource, gerando conflito de estado.
D) O agendamento do job às 03:00Z coincide com a janela de manutenção padrão do PostgreSQL Flexible Server, que suspende conexões externas temporariamente.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o relato de que backups de Azure Blobs protegidos por um Backup vault pararam de ser executados. Nenhuma mensagem de erro explícita foi registrada no painel de jobs, apenas o status NotStarted para os últimos 3 agendamentos consecutivos.
Os passos de investigação disponíveis são:
- Passo P: Verificar se a política de backup associada ao datasource está ativa e se o agendamento configurado é válido
- Passo Q: Confirmar se a conta de armazenamento que hospeda os blobs está acessível e não foi excluída ou movida de região
- Passo R: Verificar os logs de atividade do vault para identificar se houve alguma alteração de configuração recente
- Passo S: Confirmar se o vault está no estado operacional esperado e se não há alertas de integridade pendentes
- Passo T: Verificar se a identidade gerenciada do vault ainda possui as permissões necessárias na conta de armazenamento
Qual sequência de investigação segue a lógica correta de diagnóstico progressivo, partindo do mais abrangente para o mais específico?
A) S, R, P, T, Q
B) P, T, Q, S, R
C) T, Q, P, R, S
D) Q, P, S, T, R
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O Recovery Services vault e o Backup vault não suportam os mesmos tipos de datasource. O Azure Disk é protegido exclusivamente pelo Backup vault. Quando o administrador criou um Recovery Services vault, esse vault simplesmente não aparece como opção válida na interface de configuração de backup para Azure Disks, porque o portal filtra os vaults por compatibilidade com o tipo de datasource.
A pista no enunciado é o tipo do vault: a tabela indica claramente Recovery Services vault, não Backup vault. Esse detalhe é suficiente para identificar a causa.
As informações sobre permissão de Contributor, redundância LRS e ausência de locks são propositalmente irrelevantes. Nenhuma delas tem relação com a ausência do vault na lista de seleção.
O distrator mais perigoso é a alternativa A, pois a questão de permissões é um problema real em outros contextos. Um administrador que fosse investigar as permissões em vez de verificar o tipo do vault perderia tempo e chegaria a uma conclusão errada, possivelmente recriando o vault com as mesmas permissões e o mesmo tipo incorreto.
Gabarito — Cenário 2
Resposta: B
A habilitação do Soft Delete em um Backup vault é uma operação não destrutiva que pode ser realizada a qualquer momento, inclusive com jobs em andamento, sem risco de corrupção de dados ou interrupção de operações ativas. O enunciado declara explicitamente que a habilitação do Soft Delete não exige janela de manutenção e não interrompe jobs em andamento. Essa informação elimina o único argumento técnico que sustentaria a alternativa A.
A alternativa C seria válida em um cenário onde a configuração não pudesse ser alterada após a criação, mas o enunciado não estabelece essa restrição. Migrar 47 instâncias para um novo vault em menos de 2 horas seria operacionalmente inviável e introduziria riscos desnecessários.
A alternativa D é incorreta porque a configuração de Soft Delete pode ser alterada pelo administrador diretamente no portal, sem intervenção do suporte da Microsoft.
O distrator mais perigoso é a alternativa A: aguardar os jobs antes de aplicar uma mudança de configuração parece prudente, mas neste caso representa uma cautela desnecessária que atrasaria a resolução de uma vulnerabilidade real sem nenhum benefício técnico.
Gabarito — Cenário 3
Resposta: B
O código de erro UserErrorMissingRequiredPermissions e a mensagem the vault's managed identity has been granted the necessary roles on the datasource identificam precisamente que a identidade gerenciada do vault não possui as roles necessárias para acessar o servidor PostgreSQL. Habilitar a identidade gerenciada no vault é apenas o primeiro passo; as roles devem ser atribuídas explicitamente no recurso alvo para que o serviço de backup possa operar.
A informação sobre o lock de Read-Only é a informação irrelevante incluída propositalmente. Locks do tipo Read-Only aplicados ao grupo de recursos do servidor não impedem que serviços do Azure com permissões corretas acessem os dados do recurso para leitura via APIs de backup. O lock restringe operações de escrita e exclusão no plano de controle, não o acesso de serviços autorizados no plano de dados.
O distrator mais perigoso é a alternativa A. Um administrador que associe o lock ao erro de permissão pode concluir erroneamente que precisa remover o lock, o que poderia gerar um conflito organizacional com a equipe que o aplicou, e ainda assim não resolveria o problema real.
Gabarito — Cenário 4
Resposta: A
A sequência correta é S, R, P, T, Q, que segue a lógica de diagnóstico do mais abrangente para o mais específico:
- S confirma que o vault está operacional antes de qualquer outra investigação. Se o vault estiver com alertas de integridade, todos os outros passos são irrelevantes.
- R verifica os logs de atividade para identificar se houve uma mudança de configuração que pudesse ter causado a interrupção dos jobs.
- P verifica se a política está ativa e com agendamento válido, pois uma política desativada ou corrompida explicaria o status
NotStarted. - T verifica as permissões da identidade gerenciada na conta de armazenamento, que é uma causa comum para falhas silenciosas.
- Q confirma a acessibilidade da conta de armazenamento, que seria o último recurso de investigação antes de escalar o caso.
A sequência B começa pelo mais específico (política) antes de confirmar se o vault está operacional, o que é um erro de método. A sequência C começa pelas permissões sem antes validar o estado do vault ou da política. A sequência D começa pela conta de armazenamento, que é o ativo mais distante do vault no fluxo de diagnóstico e o menos provável de ser verificado primeiro.
Árvore de Troubleshooting: Create an Azure Backup vault
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| 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 identificando o sintoma observado, como vault ausente na lista, job não iniciado ou job com falha. Siga as perguntas de cada ramificação respondendo com o que é observável no ambiente, sem presumir a causa. Cada resposta elimina um conjunto de hipóteses e direciona para uma verificação mais específica. O percurso termina em uma ação recomendada apenas após o diagnóstico ter eliminado as causas alternativas, evitando correções aplicadas no lugar errado.