Pular para o conteúdo principal

Laboratório Técnico: Configure blob versioning

Questões​

Questão 1 — Múltipla Escolha​

Uma equipe de desenvolvimento armazena arquivos de configuração em um container do Azure Blob Storage com versionamento habilitado. Um desenvolvedor sobrescreve acidentalmente um blob chamado config.json com um conteúdo incorreto. Ao investigar, ele percebe que a versão anterior não aparece mais como a versão atual.

Qual afirmação descreve corretamente o comportamento do versionamento nesse cenário?

A) A sobrescrita exclui permanentemente a versão anterior, pois o versionamento só protege contra exclusões, não contra sobrescritas.

B) A versão anterior é automaticamente promovida à versão atual após a sobrescrita ser detectada como incorreta pelo serviço.

C) A sobrescrita cria uma nova versão atual, e a versão anterior é preservada automaticamente com seu próprio version ID.

D) O versionamento impede a sobrescrita do blob enquanto a versão anterior não for explicitamente excluída pelo usuário.

Questão 2 — Cenário Técnico​

Um administrador precisa habilitar o versionamento em uma conta de armazenamento existente. Ele executa o seguinte comando:

az storage account blob-service-properties update \
  --account-name mystorageaccount \
  --resource-group myRG \
  --enable-versioning true

Após a execução bem-sucedida, ele nota que blobs criados antes do comando não possuem versões anteriores listadas.

Qual é a explicação correta para esse comportamento?

A) O comando foi executado incorrectamente; o parâmetro correto é --versioning-enabled.

B) O versionamento só se aplica a operações realizadas após sua habilitação; o histórico anterior não é retroativo.

C) É necessário reiniciar a conta de armazenamento para que o versionamento passe a rastrear os blobs existentes.

D) Os blobs existentes precisam ser copiados para um novo container para que o versionamento comece a rastreá-los.

Questão 3 — Verdadeiro ou Falso​

Quando o versionamento de blobs está habilitado e um blob é excluído sem o uso de soft delete, a versão atual é removida, mas as versões anteriores permanecem acessíveis indefinidamente até serem explicitamente excluídas ou removidas por uma política de lifecycle management.

Questão 4 — Cenário Técnico​

Uma organização utiliza versionamento de blobs e deseja implementar uma estratégia de retenção que mantenha apenas as 3 versões mais recentes de cada blob, excluindo automaticamente as demais. O time de infraestrutura propõe a seguinte política de ciclo de vida:

{
  "rules": [
    {
      "name": "limit-versions",
      "enabled": true,
      "definition": {
        "filters": { "blobTypes": ["blockBlob"] },
        "actions": {
          "version": {
            "delete": { "daysAfterCreationGreaterThan": 0 }
          }
        }
      }
    }
  ]
}

O time percebe que a política está excluindo todas as versões anteriores, inclusive as recentes. Qual é a causa do problema?

A) A propriedade daysAfterCreationGreaterThan: 0 exclui qualquer versão que não seja a atual no momento de avaliação da política, sem respeitar uma contagem mínima de versões a preservar.

B) O campo blobTypes não suporta versionamento; é necessário usar appendBlob para controlar versões com lifecycle.

C) A ação version.delete só funciona quando combinada com a ação baseBlob.delete na mesma regra.

D) O problema está no campo enabled: true; versões só são gerenciadas por políticas definidas como enabled: false durante o período de teste.

Questão 5 — Múltipla Escolha​

Ao trabalhar com versionamento habilitado, um operador deseja restaurar uma versão anterior de um blob como a versão atual, sem excluir o histórico existente.

Qual é a abordagem correta para realizar essa operação?

A) Excluir a versão atual e aguardar que o serviço promova automaticamente a versão anterior mais recente.

B) Usar a operação de Copy Blob para copiar a versão anterior sobre o blob base, criando uma nova versão atual que reflete o conteúdo anterior.

C) Usar a operação de Undelete Blob para reverter o blob base ao estado da versão desejada.

D) Alterar manualmente o version ID da versão anterior para que o serviço a reconheça como a versão atual.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: C

Quando o versionamento está habilitado, qualquer operação de escrita que modifique o conteúdo de um blob existente (como uma sobrescrita via Put Blob ou Put Block List) automaticamente preserva o estado anterior como uma versão imutável com um version ID único baseado em timestamp. A nova escrita passa a ser a versão atual. O versionamento protege tanto contra sobrescritas quanto contra exclusões.

O principal equívoco representado pelos distratores é assumir que o versionamento funciona apenas como proteção contra exclusão (distrator A) ou que ele impede a operação de escrita (distrator D). Na prática, o versionamento não bloqueia nenhuma operação; ele registra o histórico de forma transparente.

Gabarito — Questão 2​

Resposta: B

O versionamento no Azure Blob Storage é prospectivo: ele começa a criar versões a partir do momento em que é habilitado. Blobs que existiam antes da habilitação não recebem retroativamente um histórico de versões. A primeira versão registrada para um blob preexistente só é criada na próxima operação de escrita ou exclusão que ocorrer após a habilitação.

Os distratores C e D representam equívocos operacionais comuns: o serviço não requer reinicialização e não há necessidade de migrar blobs entre containers. O distrator A é plausível para quem não lembra a sintaxe exata, mas o parâmetro utilizado no comando está correto.

Gabarito — Questão 3​

Verdadeiro

Quando um blob é excluído com versionamento habilitado mas sem soft delete, a versão atual (o blob base) é removida, tornando o blob invisível em listagens padrão. Porém, as versões anteriores permanecem no storage e continuam acessíveis por meio de chamadas que incluem o version ID. Elas persistem até que sejam excluídas explicitamente ou removidas por uma regra de lifecycle management.

Esse comportamento é relevante para planejamento de custos: versões órfãs acumulam encargos de armazenamento mesmo após a exclusão do blob base. A combinação de versionamento com lifecycle management é a prática recomendada para controlar esse acúmulo.

Gabarito — Questão 4​

Resposta: A

A ação version.delete com daysAfterCreationGreaterThan: 0 instrui o serviço a excluir qualquer versão anterior que tenha pelo menos 0 dias desde sua criação, ou seja, todas as versões anteriores imediatamente na próxima avaliação da política. O Azure Blob Storage lifecycle management não oferece nativamente uma opção do tipo "mantenha as N versões mais recentes" como parâmetro direto. Para preservar versões recentes, seria necessário usar um valor maior em daysAfterCreationGreaterThan, aceitando que versões mais antigas que X dias serão excluídas, sem garantia de contagem mínima.

Os distratores B e C representam suposições incorretas sobre restrições do serviço que não existem. O distrator D é implausível tecnicamente, mas foi incluído por representar um equívoco sobre o campo enabled.

Gabarito — Questão 5​

Resposta: B

A forma correta de promover uma versão anterior à versão atual é usar a operação Copy Blob, copiando o blob versionado (identificado pelo seu version ID) sobre o blob base. Essa operação cria uma nova versão atual com o conteúdo desejado e, ao mesmo tempo, preserva todo o histórico de versões anteriores, incluindo a versão que foi usada como origem da cópia.

O distrator A é incorreto porque a exclusão da versão atual não promove automaticamente nenhuma versão anterior; ela simplesmente remove o blob base. O distrator C confunde Undelete Blob, que é uma operação relacionada ao soft delete, não ao versionamento. O distrator D representa uma operação impossível: version IDs são imutáveis e gerados pelo serviço.