Laboratório Técnico: Configure blob lifecycle management
Questões
Questão 1 — Múltipla Escolha
Uma equipe de dados armazena arquivos de log no Azure Blob Storage com a camada de acesso Hot. Os logs com mais de 30 dias raramente são acessados, mas precisam ser retidos por 1 ano por exigência regulatória. Após 1 ano, devem ser excluídos automaticamente.
Qual conjunto de ações em uma política de ciclo de vida atende a esse requisito com o menor custo possível?
A) Mover para Cool após 30 dias, mover para Archive após 365 dias, excluir após 395 dias.
B) Mover para Cool após 30 dias, excluir após 365 dias.
C) Mover para Archive após 30 dias, excluir após 365 dias.
D) Mover para Cold após 30 dias, mover para Archive após 180 dias, excluir após 365 dias.
Questão 2 — Cenário Técnico
Um administrador configurou a seguinte política de ciclo de vida:
{
"rules": [
{
"name": "moverParaArchive",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": ["blockBlob"],
"prefixMatch": ["logs/2023"]
},
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterModificationGreaterThan": 90
}
}
}
}
}
]
}
Após 95 dias, o administrador verifica que os blobs em logs/2023/ não foram movidos para Archive. Qual é a causa mais provável?
A) A propriedade daysAfterModificationGreaterThan não é suportada para a camada Archive; o correto seria daysAfterCreationGreaterThan.
B) A conta de armazenamento está configurada com replicação GRS, o que bloqueia a movimentação automática de camadas.
C) Os blobs em questão são do tipo appendBlob, não blockBlob, e a regra não se aplica a esse tipo.
D) A política de ciclo de vida só é avaliada uma vez por semana, e o período de 95 dias ainda não foi processado.
Questão 3 — Múltipla Escolha
Ao definir regras de ciclo de vida, o administrador precisa escolher a condição de tempo correta para cada cenário. Considere as quatro condições disponíveis:
| Condição | Base do cálculo |
|---|---|
daysAfterModificationGreaterThan | Última modificação do blob |
daysAfterCreationGreaterThan | Data de criação do blob |
daysAfterLastAccessTimeGreaterThan | Último acesso registrado |
daysAfterLastTierChangeGreaterThan | Última mudança de camada |
Um pipeline deposita arquivos que nunca são modificados após a criação. O objetivo é excluir arquivos que não foram acessados nos últimos 60 dias. Qual condição é a mais adequada?
A) daysAfterModificationGreaterThan, pois os arquivos nunca são modificados e a data permanece estável.
B) daysAfterCreationGreaterThan, pois reflete o tempo real de vida do arquivo no armazenamento.
C) daysAfterLastAccessTimeGreaterThan, pois captura diretamente a ausência de acesso recente.
D) daysAfterLastTierChangeGreaterThan, pois todos os arquivos passam por uma camada inicial ao serem criados.
Questão 4 — Cenário Técnico
Uma organização usa versionamento de blobs habilitado em sua conta de armazenamento. A equipe percebe que os custos estão elevados por conta do acúmulo de versões antigas. O administrador deseja que versões anteriores sejam movidas para a camada Cool após 14 dias e excluídas após 90 dias.
Qual das configurações abaixo atende corretamente a esse objetivo?
A)
"actions": {
"baseBlob": {
"tierToCool": { "daysAfterModificationGreaterThan": 14 },
"delete": { "daysAfterModificationGreaterThan": 90 }
}
}
B)
"actions": {
"version": {
"tierToCool": { "daysAfterCreationGreaterThan": 14 },
"delete": { "daysAfterCreationGreaterThan": 90 }
}
}
C)
"actions": {
"snapshot": {
"tierToCool": { "daysAfterCreationGreaterThan": 14 },
"delete": { "daysAfterCreationGreaterThan": 90 }
}
}
D)
"actions": {
"baseBlob": {
"tierToCool": { "daysAfterCreationGreaterThan": 14 }
},
"version": {
"delete": { "daysAfterCreationGreaterThan": 90 }
}
}
Questão 5 — Verdadeiro ou Falso
Afirmação: Uma política de ciclo de vida que contém uma ação de tierToArchive pode ser aplicada a uma conta de armazenamento do tipo General Purpose v1 (GPv1), desde que o blob seja do tipo blockBlob.
Verdadeiro ou Falso?
Gabarito e Explicações
Gabarito — Questão 1
Resposta: A
A alternativa A é a única que cumpre todos os requisitos: reduz custo ao mover para Cool após 30 dias (acesso raro), minimiza ainda mais o custo ao arquivar após 365 dias e, em seguida, exclui após 395 dias (1 ano + 30 dias de Cool + Archive). A camada Archive exige um período mínimo de armazenamento de 180 dias; excluir antes disso incorre em penalidade de exclusão antecipada.
O principal erro dos distratores é ignorar a retenção regulatória de 1 ano: a alternativa B exclui na marca de 365 dias sem passar por Archive; a alternativa C arquiva cedo demais e exclui antes de completar 1 ano na camada correta. A alternativa D usa Cold, que tem requisito mínimo de 90 dias, e arquiva com 180 dias, exclui com 365, não atingindo 1 ano completo de retenção.
Gabarito — Questão 2
Resposta: C
O filtro blobTypes: ["blockBlob"] restringe a regra exclusivamente a blobs do tipo blockBlob. Se os arquivos de log foram gerados por um serviço que usa appendBlob (como diagnósticos ou pipelines de streaming), a regra simplesmente não se aplica a eles, e os blobs permanecem intocados.
Os outros distratores representam equívocos comuns: daysAfterModificationGreaterThan é sim suportado para Archive (A está errado); a replicação GRS não bloqueia políticas de ciclo de vida (B está errado); a política é executada uma vez por dia, não semanalmente (D está errado e é um equívoco frequente sobre a frequência de avaliação).
Gabarito — Questão 3
Resposta: C
A condição daysAfterLastAccessTimeGreaterThan é a única que mede diretamente a ausência de acesso, que é exatamente o critério de negócio descrito. Para que essa condição funcione, o rastreamento de último acesso deve estar habilitado na conta de armazenamento.
A alternativa A parece razoável porque a data de modificação é estável, mas ela não reflete acesso; um arquivo pode ser acessado repetidamente sem jamais ser modificado. A alternativa B baseia-se em criação, ignorando completamente o padrão de acesso. A alternativa D é tecnicamente incoerente: a mudança de camada não tem relação com acesso do usuário.
Gabarito — Questão 4
Resposta: B
Quando o versionamento de blobs está habilitado, versões anteriores são objetos distintos do blob atual. Para gerenciá-las, a política deve usar o objeto version dentro de actions, não baseBlob. A condição correta para versões é daysAfterCreationGreaterThan, que conta a partir do momento em que aquela versão foi criada.
A alternativa A aplica as ações ao baseBlob (blob atual), não às versões antigas. A alternativa C usa snapshot, que é um mecanismo diferente de versionamento manual. A alternativa D é parcialmente correta, mas divide as ações de forma incompleta: move para Cool via baseBlob (errado) e deleta via version (correto), o que resultaria em versões sendo excluídas sem nunca terem sido movidas para Cool.
Gabarito — Questão 5
Resposta: Falso
O gerenciamento de ciclo de vida do Blob Storage, incluindo a ação tierToArchive, não é suportado em contas General Purpose v1 (GPv1). Esse recurso está disponível apenas em contas General Purpose v2 (GPv2) e em contas Blob Storage dedicadas. Migrar uma conta GPv1 para GPv2 é um pré-requisito para usar políticas de ciclo de vida com movimentação de camadas. O tipo do blob (blockBlob) é uma condição necessária, mas não suficiente; o tipo da conta de armazenamento é o limitador determinante aqui.