Laboratório de Troubleshooting: Configure object replication
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações configurou uma política de replicação de objetos entre duas contas de armazenamento em regiões diferentes. A conta de origem é storageaccorigin (West US 2) e a conta de destino é storageaccdest (East US). Ambas as contas são do tipo StorageV2.
Após 48 horas da configuração, nenhum objeto foi replicado. O engenheiro responsável verifica o portal do Azure e confirma que a política de replicação aparece com status Enabled em ambas as contas.
Durante a investigação, ele coleta as seguintes informações:
# Verificação do versionamento na conta de origem
az storage account blob-service-properties show \
--account-name storageaccorigin \
--query "isVersioningEnabled"
# Saída:
true
# Verificação do versionamento na conta de destino
az storage account blob-service-properties show \
--account-name storageaccdest \
--query "isVersioningEnabled"
# Saída:
false
# Verificação do feed de alterações na conta de origem
az storage account blob-service-properties show \
--account-name storageaccorigin \
--query "changeFeed.enabled"
# Saída:
true
Adicionalmente, o engenheiro observa que a conta de destino possui uma política de ciclo de vida configurada para mover blobs para o nível Cool após 7 dias, e que o contêiner de destino foi criado manualmente antes da política de replicação ser configurada.
Qual é a causa raiz da ausência de replicação?
- A) O feed de alterações não está habilitado na conta de destino, o que impede que as alterações recebidas sejam registradas e confirmadas
- B) O versionamento de blobs está desabilitado na conta de destino, quebrando um pré-requisito obrigatório para que a replicação funcione
- C) A política de ciclo de vida configurada no destino está em conflito com a política de replicação, bloqueando a gravação de novos objetos
- D) O contêiner de destino foi criado manualmente antes da política, e a replicação exige que o contêiner seja provisionado automaticamente pelo serviço
Cenário 2 — Decisão de Ação
A equipe de engenharia identificou que a política de replicação entre storage-prod-origin e storage-dr-dest está funcionando corretamente para a maioria dos objetos, mas objetos com o prefixo logs/raw/ não estão sendo replicados. A investigação confirmou que a regra de replicação configurada contém apenas o filtro de prefixo logs/processed/, e o prefixo logs/raw/ nunca foi incluído.
O ambiente possui as seguintes restrições:
- A conta de origem está em produção ativa, recebendo gravações contínuas
- A política de replicação existente possui 8 regras já configuradas e validadas
- O time de segurança exige que qualquer alteração em políticas de replicação seja registrada com um ticket de mudança aprovado, que leva 2 horas para ser liberado
- O engenheiro possui permissão de Contributor na assinatura
Qual é a ação correta a tomar neste momento?
- A) Excluir a política de replicação existente e recriar do zero incluindo o novo prefixo, aproveitando para revisar todas as regras ao mesmo tempo
- B) Aguardar a aprovação do ticket de mudança e, após liberação, adicionar uma nova regra com o prefixo
logs/raw/à política existente - C) Adicionar imediatamente a nova regra à política existente sem aguardar o ticket, pois a alteração é aditiva e não afeta as regras já configuradas
- D) Criar uma segunda política de replicação separada contendo apenas a regra para o prefixo
logs/raw/, evitando alterar a política existente
Cenário 3 — Causa Raiz
Um arquiteto de soluções relata que objetos estão sendo replicados corretamente entre duas contas de armazenamento, mas ao tentar ler os objetos replicados no destino, a aplicação recebe o seguinte erro:
BlobAccessTierNotSupported: The specified access tier is not supported
for this blob type or account type.
O arquiteto fornece as seguintes informações sobre o ambiente:
| Propriedade | Conta de Origem | Conta de Destino |
|---|---|---|
| Tipo de conta | Block Blob Storage (Premium) | StorageV2 (Standard) |
| Nível de acesso padrão | N/A (Premium não tem tier) | Hot |
| Versionamento | Habilitado | Habilitado |
| Feed de alterações | Habilitado | N/A |
| Replicação ativa | Sim | Sim |
A aplicação que consome os dados do destino está configurada para usar o SDK do Azure Storage versão 12.x e realiza chamadas SetBlobAccessTier imediatamente após detectar um novo blob replicado, tentando movê-lo para o nível Archive.
Adicionalmente, o arquiteto menciona que o contêiner de destino tem uma política de acesso imutável configurada no modo Audit, e que a conta de destino tem o soft delete habilitado com retenção de 14 dias.
Qual é a causa raiz do erro observado?
- A) A conta de destino do tipo StorageV2 não é compatível com a replicação de objetos originados de contas Premium, e os blobs chegam em estado corrompido
- B) A política de acesso imutável no modo Audit está bloqueando a operação
SetBlobAccessTiernos blobs recém-replicados - C) Blobs replicados a partir de uma conta Premium Block Blob chegam ao destino sem um nível de acesso definido, e a operação
SetBlobAccessTierpara Archive falha porque blobs sem tier explícito no destino não podem ser movidos diretamente para Archive via essa chamada - D) O soft delete habilitado na conta de destino entra em conflito com alterações de tier em blobs replicados, gerando o erro reportado
Cenário 4 — Impacto Colateral
Durante uma auditoria de segurança, a equipe descobre que o feed de alterações na conta de origem storage-compliance-src estava armazenando o histórico completo de operações por tempo indeterminado, ocupando espaço significativo. Para corrigir isso, o administrador configura a retenção do feed de alterações para 7 dias por meio do seguinte comando:
az storage account blob-service-properties update \
--account-name storage-compliance-src \
--resource-group rg-compliance \
--enable-change-feed true \
--change-feed-retention-days 7
O comando é executado com sucesso e a retenção passa a ser aplicada imediatamente. A política de replicação de objetos vinculada a essa conta está ativa e saudável no momento da alteração.
Qual consequência secundária essa ação pode causar?
- A) O feed de alterações com retenção de 7 dias será desabilitado automaticamente após esse período, interrompendo permanentemente a replicação de objetos
- B) Objetos que foram gravados na origem há mais de 7 dias e que ainda não foram replicados por atraso no pipeline deixarão de ser replicados, pois o evento de criação correspondente terá sido removido do feed
- C) A retenção de 7 dias no feed de alterações força a replicação de objetos a operar em modo síncrono, aumentando a latência de escrita na conta de origem
- D) Blobs já replicados no destino serão excluídos automaticamente após 7 dias para manter paridade com a janela de retenção do feed de alterações na origem
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
Explique:
- A pista direta está na saída do comando:
isVersioningEnabledretornafalsena conta de destino. O versionamento de blobs é obrigatório em ambas as contas para que a replicação de objetos funcione. A ausência do versionamento no destino impede que o serviço grave as versões dos objetos recebidos, bloqueando toda a replicação silenciosamente. - A informação sobre a política de ciclo de vida e a criação manual do contêiner são irrelevantes para esse diagnóstico. Políticas de ciclo de vida não conflitam com a gravação de objetos replicados, e contêineres criados manualmente são completamente suportados pela replicação.
- A alternativa A representa um erro de diagnóstico clássico: o feed de alterações é necessário apenas na origem, não no destino. Focar no destino para esse pré-requisito é um desvio típico de quem confunde o papel de cada conta no pipeline.
- O distrator mais perigoso é o C, pois políticas de ciclo de vida são um elemento visível e tangível no cenário. Agir sobre ele desperdiçaria tempo sem resolver o problema real.
Gabarito — Cenário 2
Resposta: B
Explique:
- A causa já foi identificada no enunciado, portanto o raciocínio aqui é sobre a restrição de processo, não sobre técnica. O time de segurança exige um ticket aprovado para qualquer alteração em políticas de replicação, e esse processo leva 2 horas. Ignorar esse controle viola a política organizacional, independentemente de a mudança ser tecnicamente segura.
- A alternativa C é tecnicamente correta em termos de impacto na infraestrutura (adicionar uma regra não afeta as demais), mas ignora a restrição de governança explicitamente declarada no cenário. Essa é a armadilha central: a ação certa aplicada no contexto errado.
- A alternativa A seria destrutiva e desnecessária: excluir 8 regras validadas para recriar tudo implica risco operacional elevado e não há justificativa técnica para isso.
- A alternativa D parece uma solução de contorno inteligente, mas criar uma segunda política separada para um único prefixo adicional fragmenta desnecessariamente a gestão e ainda precisaria passar pelo mesmo processo de aprovação.
- A consequência real de escolher C seria uma violação de compliance que poderia resultar em auditoria, independentemente do sucesso técnico da operação.
Gabarito — Cenário 3
Resposta: C
Explique:
- Quando um blob é replicado a partir de uma conta Premium Block Blob Storage para uma conta Standard StorageV2, ele chega ao destino sem um nível de acesso explícito atribuído, pois contas Premium não possuem o conceito de access tier. A operação
SetBlobAccessTiertentando mover diretamente para Archive falha porque o blob não passou antes pelos níveis Hot ou Cool no destino, e a API não aceita essa transição direta nessa condição. - A informação sobre a política de acesso imutável no modo Audit é irrelevante: o modo Audit apenas registra violações sem bloqueá-las, portanto não interfere em operações de alteração de tier.
- O soft delete com 14 dias de retenção também é irrelevante para o erro observado; ele afeta apenas o comportamento de exclusão de blobs.
- A alternativa A é incorreta: StorageV2 Standard é um destino completamente suportado para replicação a partir de contas Premium.
- O distrator mais perigoso é o B, pois políticas de imutabilidade são intuitivamente associadas a restrições de escrita. Investigar por esse caminho levaria o engenheiro a abrir tickets com o time de segurança sem necessidade.
Gabarito — Cenário 4
Resposta: B
Explique:
- O feed de alterações funciona como o registro de eventos que alimenta o pipeline de replicação. Quando a retenção é definida para 7 dias, eventos com mais de 7 dias são removidos do feed. Se existirem objetos na fila de replicação com eventos de criação com mais de 7 dias (por exemplo, devido a um atraso no pipeline ou a uma janela de manutenção), esses eventos serão removidos antes de serem processados pela replicação, e os objetos correspondentes nunca serão replicados.
- A alternativa A é incorreta: configurar retenção não desabilita o feed após o período. O feed continua ativo, apenas expirando eventos antigos de forma contínua.
- A alternativa C é incorreta: a retenção do feed não altera o modo de operação da replicação de assíncrona para síncrona. São aspectos completamente independentes.
- A alternativa D é incorreta e representa um mal-entendido grave: a retenção do feed de alterações na origem não tem nenhum efeito sobre os objetos já gravados no destino. A replicação de objetos é unidirecional e não possui mecanismo de exclusão automática no destino baseado em políticas da origem.
- A consequência prática mais grave de ignorar esse impacto colateral é a perda silenciosa de dados: objetos que deveriam ter sido replicados simplesmente nunca chegarão ao destino, sem qualquer alerta ou erro visível no painel da política de replicação.
Árvore de Troubleshooting: Configure object replication
Legenda:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| 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 sintoma observado e siga as ramificações respondendo cada pergunta com base no que você consegue verificar diretamente no ambiente. As perguntas são ordenadas do pré-requisito mais fundamental para o mais específico, o que significa que responder "não" em qualquer nó azul identifica imediatamente a causa sem necessidade de continuar a investigação. Quando todas as perguntas anteriores forem "sim" e a replicação ainda não tiver ocorrido, o nó laranja de validação indica que o comportamento pode ser simplesmente o atraso assíncrono esperado do serviço.