Laboratório Hands-on Guiado: AZ-104 — Microsoft Azure Administrator

Cenário

A Dataflow Logística, empresa brasileira de supply chain com operações em seis estados, precisa modernizar seu ambiente de armazenamento no Azure. A empresa possui um Resource Group já provisionado com recursos básicos de rede, mas todo o armazenamento de documentos operacionais (notas fiscais, manifestos de carga, imagens de comprovantes de entrega) ainda está em servidores locais. A diretoria de TI definiu que o novo ambiente de storage deve atender a três requisitos: compartilhamento de arquivos para equipes regionais via SMB, armazenamento de blobs para documentos de longa retenção com política de ciclo de vida automatizada, e proteção contra exclusão acidental com versionamento e soft delete habilitados em todas as camadas.

O ambiente Azure inicial contém apenas a subscription ativa e uma VNet de gerenciamento. Ao final deste laboratório, a infraestrutura de armazenamento estará completamente funcional, com file shares configurados, containers de blob com tiers otimizados, políticas de ciclo de vida ativas, versionamento habilitado e mecanismos de recuperação (soft delete e snapshots) testados e validados.

Pré-requisitos

Antes de iniciar a Fase 1, crie ou confirme a existência dos seguintes recursos:

Resource Group: Crie o Resource Group que hospedará todos os recursos do lab.
- No portal, acesse Resource groups > Create
- Nome: rg-dataflow-lab
- Região: East US 2
- Clique em Review + create > Create
Storage Account (General-purpose v2): Crie a conta de armazenamento principal.
- No portal, acesse Storage accounts > Create
- Resource group: rg-dataflow-lab
- Nome: stdataflowlab (ajuste para um nome globalmente único, ex: stdataflowlab<seusiniciais>)
- Região: East US 2
- Performance: Standard
- Redundancy: LRS
- Na aba Advanced, confirme que Enable blob public access está desmarcado
- Na aba Data protection, deixe todas as opções no padrão por enquanto (serão configuradas durante o lab)
- Clique em Review + create > Create
Azure CLI ou Cloud Shell: Confirme que o Azure CLI está instalado localmente ou abra o Cloud Shell (Bash) no portal Azure.

Tabela de referência de recursos:

Recurso	Nome no lab	Região
Resource Group	rg-dataflow-lab	East US 2
Storage Account	stdataflowlab (+ sufixo único)	East US 2
File Share	fs-operacoes	East US 2
File Share (tier)	fs-arquivo-morto	East US 2
Container (Blob)	ctr-documentos	East US 2
Container (Blob)	ctr-comprovantes	East US 2

Fases do Laboratório

Fase 1 — Azure Files: File Shares e Snapshots

Nesta fase, você criará e configurará file shares no Azure Files para atender às equipes regionais da Dataflow Logística. Serão criados dois file shares com finalidades distintas, e você configurará snapshots e soft delete para proteger os dados contra exclusão acidental. Esta fase cobre os objetivos Create and configure a file share in Azure Files e Configure snapshots and soft delete for Azure Files.

O file share fs-operacoes será utilizado pelas equipes regionais para armazenar documentos operacionais acessados diariamente. Você configurará cota, protocolo e tier adequados ao uso intenso.

Via Portal

Navegue até Storage accounts > selecione stdataflowlab
No menu lateral, em Data storage, clique em File shares
Clique em + File share
Preencha o campo Name com fs-operacoes
Em Tier, selecione Transaction optimized
Clique em Next: Backup e desabilite o backup automático por enquanto
Clique em Review + create > Create
Após a criação, clique no file share fs-operacoes
Clique em Properties no menu lateral e observe a cota padrão (valor máximo do tier)
Volte a Overview, clique no botão de reticências (...) ou em Edit quota
Defina a cota como 100 GiB e salve

Via CLI

# Criar o file share com tier e cota definidos
az storage share-rm create \
  --resource-group rg-dataflow-lab \
  --storage-account stdataflowlab \
  --name fs-operacoes \
  --access-tier "TransactionOptimized" \
  --quota 100

# Verificar a criação e propriedades
az storage share-rm show \
  --resource-group rg-dataflow-lab \
  --storage-account stdataflowlab \
  --name fs-operacoes \
  --query "{name:name, quota:shareQuota, tier:accessTier}"

O file share agora está disponível com cota limitada a 100 GiB no tier Transaction Optimized, adequado para cargas de trabalho com acesso frequente e alto volume de transações.

O segundo file share, fs-arquivo-morto, armazenará documentos históricos com acesso raro. Você escolherá o tier Cool para reduzir custos e fará upload de um arquivo de teste para uso nas tarefas de snapshot.

Via Portal

Navegue até Storage accounts > stdataflowlab > File shares
Clique em + File share
Preencha Name com fs-arquivo-morto
Em Tier, selecione Cool
Clique em Review + create > Create
Abra o file share fs-operacoes
Clique em Upload
Selecione um arquivo de texto local (crie um arquivo nota-fiscal-001.txt com conteúdo qualquer)
Clique em Upload
Confirme que o arquivo aparece listado no file share

Via CLI

# Criar file share com tier Cool
az storage share-rm create \
  --resource-group rg-dataflow-lab \
  --storage-account stdataflowlab \
  --name fs-arquivo-morto \
  --access-tier "Cool" \
  --quota 50

# Criar arquivo de teste local
echo "NF 001 - Carga São Paulo - 2025-01-15 - R$ 45.000,00" > nota-fiscal-001.txt

# Obter a connection string da storage account
CONN_STR=$(az storage account show-connection-string \
  --resource-group rg-dataflow-lab \
  --name stdataflowlab \
  --query connectionString -o tsv)

# Upload do arquivo de teste
az storage file upload \
  --share-name fs-operacoes \
  --source nota-fiscal-001.txt \
  --connection-string "$CONN_STR"

# Listar arquivos no share
az storage file list \
  --share-name fs-operacoes \
  --connection-string "$CONN_STR" \
  --query "[].name" -o tsv

Agora existem dois file shares com tiers distintos. O arquivo de teste carregado será utilizado nas próximas tarefas para validar snapshots e recuperação.

Tarefa 1.3 — Habilitar soft delete para Azure Files

Antes de configurar snapshots, você habilitará o soft delete para file shares, garantindo que shares excluídos possam ser recuperados dentro de um período de retenção.

Via Portal

Navegue até Storage accounts > stdataflowlab
No menu lateral, em Data protection, clique em Data protection (ou Data management > Data protection, dependendo da versão do portal)
Na seção File shares, marque a opção Enable soft delete for file shares
Defina o período de retenção como 14 dias
Clique em Save

Via CLI

# Habilitar soft delete para file shares com retenção de 14 dias
az storage account file-service-properties update \
  --resource-group rg-dataflow-lab \
  --account-name stdataflowlab \
  --enable-delete-retention true \
  --delete-retention-days 14

# Confirmar a configuração
az storage account file-service-properties show \
  --resource-group rg-dataflow-lab \
  --account-name stdataflowlab \
  --query "shareDeleteRetentionPolicy"

O soft delete está ativo. File shares excluídos permanecerão recuperáveis por 14 dias antes de serem removidos permanentemente.

Tarefa 1.4 — Criar snapshot e validar recuperação de arquivo

Você criará um snapshot do file share fs-operacoes, simulará a perda de um arquivo e o recuperará a partir do snapshot. Esta tarefa valida o comportamento real de recuperação, não apenas a configuração.

Via Portal

Navegue até Storage accounts > stdataflowlab > File shares > fs-operacoes
No menu lateral, clique em Snapshots
Clique em + Add snapshot
Opcionalmente, adicione um comentário: Snapshot antes da simulação de perda
Clique em OK
Volte a Overview do file share
Selecione o arquivo nota-fiscal-001.txt e clique em Delete > confirme a exclusão
Verifique que o arquivo não aparece mais na listagem
Volte a Snapshots, clique no snapshot criado
Navegue até o arquivo nota-fiscal-001.txt dentro do snapshot
Clique em Restore para restaurar o arquivo ao file share ativo
Volte a Overview e confirme que o arquivo reapareceu na listagem

Via CLI

# Criar snapshot do file share
SNAPSHOT=$(az storage share snapshot \
  --name fs-operacoes \
  --connection-string "$CONN_STR" \
  --query "snapshot" -o tsv)

echo "Snapshot criado: $SNAPSHOT"

# Excluir o arquivo do share ativo
az storage file delete \
  --share-name fs-operacoes \
  --path nota-fiscal-001.txt \
  --connection-string "$CONN_STR"

# Confirmar que o arquivo não existe mais
az storage file list \
  --share-name fs-operacoes \
  --connection-string "$CONN_STR" \
  --query "[].name" -o tsv
# Output esperado: vazio ou sem o arquivo nota-fiscal-001.txt

# Listar arquivos no snapshot (confirmar que lá o arquivo ainda existe)
az storage file list \
  --share-name fs-operacoes \
  --snapshot "$SNAPSHOT" \
  --connection-string "$CONN_STR" \
  --query "[].name" -o tsv
# Output esperado: nota-fiscal-001.txt

# Baixar o arquivo do snapshot
az storage file download \
  --share-name fs-operacoes \
  --path nota-fiscal-001.txt \
  --snapshot "$SNAPSHOT" \
  --dest ./nota-fiscal-001-recovered.txt \
  --connection-string "$CONN_STR"

# Fazer upload de volta ao share ativo
az storage file upload \
  --share-name fs-operacoes \
  --source ./nota-fiscal-001-recovered.txt \
  --path nota-fiscal-001.txt \
  --connection-string "$CONN_STR"

# Confirmar a recuperação
az storage file list \
  --share-name fs-operacoes \
  --connection-string "$CONN_STR" \
  --query "[].name" -o tsv

O snapshot preservou o estado do file share no momento da captura. Mesmo após a exclusão do arquivo no share ativo, foi possível recuperá-lo integralmente a partir do snapshot.

Agora você validará o soft delete excluindo o file share fs-arquivo-morto e recuperando-o dentro do período de retenção.

Via Portal

Navegue até Storage accounts > stdataflowlab > File shares
Localize fs-arquivo-morto na lista
Clique no ícone de reticências (...) ao lado do share e selecione Delete
Confirme a exclusão digitando o nome do share
Após a exclusão, observe que o share desaparece da listagem padrão
Na parte superior da lista de file shares, ative o toggle Show deleted shares
Localize fs-arquivo-morto com status Deleted
Clique no ícone de reticências (...) e selecione Undelete
Confirme a recuperação e verifique que o share volta ao status ativo

Via CLI

# Excluir o file share
az storage share-rm delete \
  --resource-group rg-dataflow-lab \
  --storage-account stdataflowlab \
  --name fs-arquivo-morto \
  --yes

# Listar shares incluindo os excluídos via soft delete
az storage share-rm list \
  --resource-group rg-dataflow-lab \
  --storage-account stdataflowlab \
  --include-deleted \
  --query "[?deleted==\`true\`].{name:name, deleted:deleted, version:version}" -o table

# Restaurar o file share (usar a versão retornada no comando anterior)
az storage share-rm restore \
  --resource-group rg-dataflow-lab \
  --storage-account stdataflowlab \
  --name fs-arquivo-morto \
  --deleted-version "<versão retornada no passo anterior>"

# Confirmar que o share está ativo novamente
az storage share-rm list \
  --resource-group rg-dataflow-lab \
  --storage-account stdataflowlab \
  --query "[].{name:name, tier:accessTier}" -o table

O soft delete funcionou conforme esperado. O file share excluído foi recuperado com todas as suas propriedades originais, incluindo o tier Cool e a cota previamente configurada.

Fase 2 — Blob Storage: Containers, Tiers e Upload

Nesta fase, você criará containers no Azure Blob Storage para armazenar documentos e comprovantes da Dataflow Logística. Configurará diferentes access tiers nos blobs e validará as transições de tier. Esta fase cobre os objetivos Create and configure a container in Azure Blob Storage e Configure storage tiers. Utiliza a mesma Storage Account stdataflowlab criada nos pré-requisitos.

Tarefa 2.1 — Criar containers com diferentes níveis de acesso

Você criará dois containers: ctr-documentos para documentos operacionais correntes e ctr-comprovantes para comprovantes de entrega com acesso restrito.

Via Portal

Navegue até Storage accounts > stdataflowlab
No menu lateral, em Data storage, clique em Containers
Clique em + Container
Preencha Name com ctr-documentos
Em Anonymous access level, selecione Private (no anonymous access)
Clique em Create
Repita o processo para o segundo container:
- Name: ctr-comprovantes
- Anonymous access level: Private (no anonymous access)
Clique em Create

Via CLI

# Criar container para documentos operacionais
az storage container create \
  --name ctr-documentos \
  --account-name stdataflowlab \
  --auth-mode login \
  --public-access off

# Criar container para comprovantes
az storage container create \
  --name ctr-comprovantes \
  --account-name stdataflowlab \
  --auth-mode login \
  --public-access off

# Listar containers criados
az storage container list \
  --account-name stdataflowlab \
  --auth-mode login \
  --query "[].{name:name, publicAccess:properties.publicAccess}" -o table

Ambos os containers estão criados com acesso anônimo desabilitado, atendendo à política de segurança da Dataflow.

Tarefa 2.2 — Fazer upload de blobs com tiers diferentes

Você fará upload de arquivos nos containers configurando tiers distintos (Hot, Cool e Archive) para simular diferentes padrões de acesso da empresa.

Via Portal

Navegue até Containers > ctr-documentos
Clique em Upload
Selecione um arquivo de texto (crie manifesto-carga-2025.txt com conteúdo qualquer)
Expanda Advanced
Em Access tier, selecione Hot
Clique em Upload
Repita o upload com um segundo arquivo (relatorio-trimestral.txt), selecionando tier Cool
Navegue até Containers > ctr-comprovantes
Faça upload de um terceiro arquivo (comprovante-entrega-antigo.txt) com tier Archive
Após o upload, clique no blob comprovante-entrega-antigo.txt e observe nas propriedades que o Access tier exibe Archive

Via CLI

# Criar arquivos de teste
echo "Manifesto de carga - Rota SP-RJ - 2025" > manifesto-carga-2025.txt
echo "Relatório trimestral de operações Q1 2025" > relatorio-trimestral.txt
echo "Comprovante de entrega - NF 00042 - 2020" > comprovante-entrega-antigo.txt

# Upload com tier Hot
az storage blob upload \
  --container-name ctr-documentos \
  --name manifesto-carga-2025.txt \
  --file manifesto-carga-2025.txt \
  --tier Hot \
  --account-name stdataflowlab \
  --auth-mode login

# Upload com tier Cool
az storage blob upload \
  --container-name ctr-documentos \
  --name relatorio-trimestral.txt \
  --file relatorio-trimestral.txt \
  --tier Cool \
  --account-name stdataflowlab \
  --auth-mode login

# Upload com tier Archive
az storage blob upload \
  --container-name ctr-comprovantes \
  --name comprovante-entrega-antigo.txt \
  --file comprovante-entrega-antigo.txt \
  --tier Archive \
  --account-name stdataflowlab \
  --auth-mode login

# Verificar os tiers de cada blob
az storage blob list \
  --container-name ctr-documentos \
  --account-name stdataflowlab \
  --auth-mode login \
  --query "[].{name:name, tier:properties.blobTier}" -o table

az storage blob list \
  --container-name ctr-comprovantes \
  --account-name stdataflowlab \
  --auth-mode login \
  --query "[].{name:name, tier:properties.blobTier}" -o table

Os três blobs estão armazenados em tiers diferentes, refletindo o padrão de acesso de cada tipo de documento.

Tarefa 2.3 — Alterar tier de um blob e observar o comportamento de reidratação

Você alterará o tier de um blob de Archive para Hot para simular um cenário em que um documento histórico precisa ser acessado com urgência. Observará o processo de reidratação e entenderá por que o blob não fica imediatamente disponível.

Via Portal

Navegue até Containers > ctr-comprovantes
Clique no blob comprovante-entrega-antigo.txt
Observe que o Access tier está como Archive
Tente clicar em Download: o portal exibirá um erro ou aviso indicando que o blob está no tier Archive e precisa ser reidratado
Clique em Change tier
Selecione Hot
Em Rehydrate priority, selecione Standard
Clique em Save
Volte às propriedades do blob e observe que o Archive status agora exibe rehydrate-pending-to-hot
O blob permanecerá neste estado por várias horas. Registre o horário atual para referência

Via CLI

# Verificar tier atual
az storage blob show \
  --container-name ctr-comprovantes \
  --name comprovante-entrega-antigo.txt \
  --account-name stdataflowlab \
  --auth-mode login \
  --query "{tier:properties.blobTier, archiveStatus:properties.archiveStatus}"

# Tentar fazer download (falhará com blob no tier Archive)
az storage blob download \
  --container-name ctr-comprovantes \
  --name comprovante-entrega-antigo.txt \
  --file ./download-test.txt \
  --account-name stdataflowlab \
  --auth-mode login 2>&1 || echo "Erro esperado: blob em tier Archive não pode ser lido diretamente"

# Alterar tier para Hot (inicia reidratação)
az storage blob set-tier \
  --container-name ctr-comprovantes \
  --name comprovante-entrega-antigo.txt \
  --tier Hot \
  --account-name stdataflowlab \
  --auth-mode login

# Verificar o status de reidratação
az storage blob show \
  --container-name ctr-comprovantes \
  --name comprovante-entrega-antigo.txt \
  --account-name stdataflowlab \
  --auth-mode login \
  --query "{tier:properties.blobTier, archiveStatus:properties.archiveStatus}"
# Output esperado: archiveStatus = "rehydrate-pending-to-hot"

A mudança de tier de Archive para Hot não é instantânea. O blob entra em estado de reidratação e pode levar até 15 horas (prioridade Standard) para ficar acessível. Este comportamento é crítico para o planejamento de acesso a dados arquivados.

Fase 3 — Proteção de Dados: Soft Delete, Versionamento e Recuperação de Blobs

Nesta fase, você habilitará as funcionalidades de proteção de dados para blobs e containers na Storage Account stdataflowlab criada nos pré-requisitos. Os containers e blobs criados na Fase 2 serão utilizados para testar exclusão e recuperação. Esta fase cobre os objetivos Configure soft delete for blobs and containers e Configure blob versioning.

Tarefa 3.1 — Verificar o estado atual de proteção antes de habilitar

Antes de habilitar qualquer funcionalidade de proteção, você verificará o estado atual das configurações de data protection na storage account. Esta verificação garante que você reconheça o estado "desabilitado" antes de realizar a transição para "habilitado".

Via Portal

Navegue até Storage accounts > stdataflowlab
No menu lateral, em Data management, clique em Data protection
Na seção Recovery, observe as opções:
- Enable soft delete for blobs: verifique se está desmarcado
- Enable soft delete for containers: verifique se está desmarcado
Na seção Tracking, observe:
- Enable versioning for blobs: verifique se está desmarcado
Registre mentalmente ou anote o estado de cada opção antes de prosseguir

Via CLI

# Verificar propriedades de soft delete para blobs
az storage account blob-service-properties show \
  --resource-group rg-dataflow-lab \
  --account-name stdataflowlab \
  --query "{blobSoftDelete:deleteRetentionPolicy.enabled, blobRetentionDays:deleteRetentionPolicy.days, containerSoftDelete:containerDeleteRetentionPolicy.enabled, containerRetentionDays:containerDeleteRetentionPolicy.days, versioning:isVersioningEnabled}"
# Output esperado: todos os valores como false ou null

Confirmado que nenhuma funcionalidade de proteção está habilitada. Os próximos passos farão a transição do estado desabilitado para habilitado.

Tarefa 3.2 — Habilitar soft delete para blobs e containers

Você habilitará o soft delete tanto para blobs individuais quanto para containers, definindo períodos de retenção distintos para cada um.

Via Portal

Navegue até Storage accounts > stdataflowlab > Data protection
Na seção Recovery:
- Marque Enable soft delete for blobs
- Defina o período de retenção como 30 dias
- Marque Enable soft delete for containers
- Defina o período de retenção como 7 dias
Clique em Save
Aguarde a confirmação de que as configurações foram salvas

Via CLI

# Habilitar soft delete para blobs (30 dias)
az storage account blob-service-properties update \
  --resource-group rg-dataflow-lab \
  --account-name stdataflowlab \
  --enable-delete-retention true \
  --delete-retention-days 30

# Habilitar soft delete para containers (7 dias)
az storage account blob-service-properties update \
  --resource-group rg-dataflow-lab \
  --account-name stdataflowlab \
  --enable-container-delete-retention true \
  --container-delete-retention-days 7

# Confirmar as configurações
az storage account blob-service-properties show \
  --resource-group rg-dataflow-lab \
  --account-name stdataflowlab \
  --query "{blobSoftDelete:deleteRetentionPolicy.enabled, blobDays:deleteRetentionPolicy.days, containerSoftDelete:containerDeleteRetentionPolicy.enabled, containerDays:containerDeleteRetentionPolicy.days}"

O soft delete agora protege blobs por 30 dias e containers por 7 dias. Blobs e containers excluídos serão marcados como soft-deleted e poderão ser recuperados dentro desses períodos.

Tarefa 3.3 — Habilitar blob versioning

Você habilitará o versionamento de blobs para manter automaticamente versões anteriores de cada blob quando ele for modificado ou sobrescrito.

Via Portal

Navegue até Storage accounts > stdataflowlab > Data protection
Na seção Tracking, marque Enable versioning for blobs
Clique em Save

Via CLI

# Habilitar versionamento
az storage account blob-service-properties update \
  --resource-group rg-dataflow-lab \
  --account-name stdataflowlab \
  --enable-versioning true

# Confirmar
az storage account blob-service-properties show \
  --resource-group rg-dataflow-lab \
  --account-name stdataflowlab \
  --query "isVersioningEnabled"
# Output esperado: true

O versionamento está ativo. A partir de agora, toda sobrescrita ou modificação de um blob gerará automaticamente uma versão anterior preservada.

Tarefa 3.4 — Testar versionamento sobrescrevendo um blob e acessando versões anteriores

Você sobrescreverá o blob manifesto-carga-2025.txt no container ctr-documentos e verificará que a versão anterior foi preservada automaticamente.

Via Portal

Navegue até Containers > ctr-documentos
Observe o blob manifesto-carga-2025.txt existente
Clique em Upload
Selecione um novo arquivo local chamado manifesto-carga-2025.txt com conteúdo diferente (ex: adicione "VERSAO ATUALIZADA" ao conteúdo)
Marque a opção Overwrite if files already exist
Clique em Upload
Clique no blob manifesto-carga-2025.txt
Na aba Versions, observe que agora existem pelo menos duas versões listadas
Clique na versão anterior (a que não é a Current version)
Faça o download e verifique que contém o conteúdo original

Via CLI

# Criar nova versão do arquivo com conteúdo diferente
echo "Manifesto de carga - Rota SP-RJ - 2025 - VERSAO ATUALIZADA COM NOVOS DADOS" > manifesto-carga-2025.txt

# Sobrescrever o blob
az storage blob upload \
  --container-name ctr-documentos \
  --name manifesto-carga-2025.txt \
  --file manifesto-carga-2025.txt \
  --overwrite \
  --account-name stdataflowlab \
  --auth-mode login

# Listar todas as versões do blob
az storage blob list \
  --container-name ctr-documentos \
  --account-name stdataflowlab \
  --auth-mode login \
  --include v \
  --query "[?name=='manifesto-carga-2025.txt'].{name:name, versionId:versionId, isCurrentVersion:isCurrentVersion}" -o table

# Fazer download da versão anterior (usar o versionId retornado)
# Substitua <VERSION_ID> pelo valor obtido no comando anterior
az storage blob download \
  --container-name ctr-documentos \
  --name manifesto-carga-2025.txt \
  --version-id "<VERSION_ID>" \
  --file ./manifesto-versao-anterior.txt \
  --account-name stdataflowlab \
  --auth-mode login

# Verificar o conteúdo da versão anterior
cat ./manifesto-versao-anterior.txt

O versionamento preservou automaticamente a versão anterior do blob. Ambas as versões coexistem, e a versão anterior pode ser baixada ou promovida a versão atual a qualquer momento.

Tarefa 3.5 — Testar soft delete excluindo e recuperando um blob

Você excluirá o blob relatorio-trimestral.txt do container ctr-documentos e o recuperará usando soft delete.

Via Portal

Navegue até Containers > ctr-documentos
Selecione o blob relatorio-trimestral.txt
Clique em Delete > confirme a exclusão
O blob desaparecerá da listagem padrão
Na parte superior da listagem de blobs, clique em Show deleted blobs (ative o toggle)
Localize relatorio-trimestral.txt com indicação de estado Deleted
Clique no blob excluído e selecione Undelete
Desative o toggle Show deleted blobs e confirme que o blob reapareceu na listagem ativa

Via CLI

# Excluir o blob
az storage blob delete \
  --container-name ctr-documentos \
  --name relatorio-trimestral.txt \
  --account-name stdataflowlab \
  --auth-mode login

# Listar blobs incluindo os soft-deleted
az storage blob list \
  --container-name ctr-documentos \
  --account-name stdataflowlab \
  --auth-mode login \
  --include d \
  --query "[?name=='relatorio-trimestral.txt'].{name:name, deleted:deleted}" -o table

# Recuperar o blob
az storage blob undelete \
  --container-name ctr-documentos \
  --name relatorio-trimestral.txt \
  --account-name stdataflowlab \
  --auth-mode login

# Confirmar recuperação
az storage blob show \
  --container-name ctr-documentos \
  --name relatorio-trimestral.txt \
  --account-name stdataflowlab \
  --auth-mode login \
  --query "{name:name, deleted:deleted, tier:properties.blobTier}"

O blob foi excluído e recuperado com sucesso. O soft delete manteve o blob em estado recuperável durante o período de retenção de 30 dias configurado anteriormente.

Tarefa 3.6 — Testar soft delete de container

Você excluirá o container ctr-comprovantes e o recuperará, validando o soft delete no nível de container.

Via Portal

Navegue até Storage accounts > stdataflowlab > Containers
Clique no ícone de reticências (...) ao lado de ctr-comprovantes
Selecione Delete > confirme
Ative o toggle Show deleted containers na parte superior da lista
Localize ctr-comprovantes com status Deleted
Clique no ícone de reticências (...) e selecione Undelete
Verifique que o container e seus blobs foram restaurados

Via CLI

# Excluir o container
az storage container delete \
  --name ctr-comprovantes \
  --account-name stdataflowlab \
  --auth-mode login

# Listar containers incluindo os excluídos
az storage container list \
  --account-name stdataflowlab \
  --auth-mode login \
  --include-deleted \
  --query "[?deleted==\`true\`].{name:name, version:version}" -o table

# Restaurar o container (usar a versão retornada)
az storage container restore \
  --name ctr-comprovantes \
  --deleted-version "<versão do comando anterior>" \
  --account-name stdataflowlab \
  --auth-mode login

# Confirmar restauração e listar blobs
az storage blob list \
  --container-name ctr-comprovantes \
  --account-name stdataflowlab \
  --auth-mode login \
  --query "[].name" -o tsv

O container e todos os seus blobs foram recuperados. O soft delete de containers oferece proteção contra exclusão acidental no nível mais alto da hierarquia de armazenamento.

Fase 4 — Lifecycle Management: Políticas de Ciclo de Vida

Nesta fase, você configurará políticas de lifecycle management para automatizar a movimentação de blobs entre tiers e a exclusão de dados antigos. Utilizará os containers ctr-documentos e ctr-comprovantes criados na Fase 2 e protegidos na Fase 3. Esta fase cobre o objetivo Configure blob lifecycle management.

Tarefa 4.1 — Criar uma política de lifecycle management com múltiplas regras

Você criará uma política com duas regras: uma que mova blobs do tier Hot para Cool após 30 dias e outra que mova blobs para Archive após 180 dias. As regras serão aplicadas ao container ctr-documentos.

Via Portal

Navegue até Storage accounts > stdataflowlab
No menu lateral, em Data management, clique em Lifecycle management
Clique em + Add a rule
Configure a primeira regra:
- Rule name: mover-para-cool-30d
- Rule scope: Limit blobs with filters
- Marque Block blobs em blob type
- Em Blob subtype, marque Base blobs
- Clique em Next
Na aba Base blobs:
- Selecione a condição Last modified > More than (days ago) > digite 30
- Selecione a ação Move to cool storage
- Clique em Next
Na aba Filter set:
- Em Prefix match, adicione ctr-documentos/
- Clique em Add
Clique em + Add a rule para a segunda regra:
- Rule name: mover-para-archive-180d
- Rule scope: Limit blobs with filters
- Marque Block blobs
- Em Blob subtype, marque Base blobs
Na aba Base blobs:
- Condição: Last modified > More than (days ago) > 180
- Ação: Move to archive storage
Na aba Filter set:
- Prefix match: ctr-documentos/
Clique em Add

Via CLI

# Criar arquivo JSON com a política de lifecycle
cat > lifecycle-policy.json << 'EOF'
{
  "rules": [
    {
      "enabled": true,
      "name": "mover-para-cool-30d",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["ctr-documentos/"]
        }
      }
    },
    {
      "enabled": true,
      "name": "mover-para-archive-180d",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 180
            }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["ctr-documentos/"]
        }
      }
    }
  ]
}
EOF

# Aplicar a política
az storage account management-policy create \
  --resource-group rg-dataflow-lab \
  --account-name stdataflowlab \
  --policy @lifecycle-policy.json

# Verificar a política criada
az storage account management-policy show \
  --resource-group rg-dataflow-lab \
  --account-name stdataflowlab \
  --query "policy.rules[].{name:name, enabled:enabled}" -o table

A política de lifecycle está ativa com duas regras. Blobs no container ctr-documentos serão automaticamente movidos de Hot para Cool após 30 dias e de Cool para Archive após 180 dias de inatividade.

Tarefa 4.2 — Adicionar regra de exclusão automática e regra para snapshots e versões

Você expandirá a política adicionando uma regra que exclua blobs no tier Archive após 365 dias e outra que gerencie snapshots e versões antigas.

Via Portal

Navegue até Lifecycle management da storage account
Clique em + Add a rule
Configure a regra de exclusão:
- Rule name: excluir-archive-365d
- Rule scope: Limit blobs with filters
- Marque Block blobs
- Em Blob subtype, marque Base blobs
Na aba Base blobs:
- Condição: Last modified > More than (days ago) > 365
- Ação: Delete the blob
Na aba Filter set:
- Prefix match: ctr-comprovantes/
Clique em Add
Clique em + Add a rule novamente:
- Rule name: limpar-versoes-antigas
- Rule scope: Limit blobs with filters
- Marque Block blobs
- Em Blob subtype, marque Snapshots e Versions
Na aba Snapshot:
- Condição: Snapshot created > More than (days ago) > 90
- Ação: Delete the snapshot
Na aba Version:
- Condição: Version created > More than (days ago) > 90
- Ação: Delete the version
Na aba Filter set, não adicione prefixo (aplica-se a toda a storage account)
Clique em Add

Via CLI

# Atualizar a política adicionando as novas regras
cat > lifecycle-policy-full.json << 'EOF'
{
  "rules": [
    {
      "enabled": true,
      "name": "mover-para-cool-30d",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["ctr-documentos/"]
        }
      }
    },
    {
      "enabled": true,
      "name": "mover-para-archive-180d",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 180
            }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["ctr-documentos/"]
        }
      }
    },
    {
      "enabled": true,
      "name": "excluir-archive-365d",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "delete": {
              "daysAfterModificationGreaterThan": 365
            }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["ctr-comprovantes/"]
        }
      }
    },
    {
      "enabled": true,
      "name": "limpar-versoes-antigas",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "snapshot": {
            "delete": {
              "daysAfterCreationGreaterThan": 90
            }
          },
          "version": {
            "delete": {
              "daysAfterCreationGreaterThan": 90
            }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"]
        }
      }
    }
  ]
}
EOF

# Atualizar a política (substitui a anterior)
az storage account management-policy create \
  --resource-group rg-dataflow-lab \
  --account-name stdataflowlab \
  --policy @lifecycle-policy-full.json

# Listar todas as regras
az storage account management-policy show \
  --resource-group rg-dataflow-lab \
  --account-name stdataflowlab \
  --query "policy.rules[].{name:name, enabled:enabled, type:type}" -o table

A política de lifecycle agora contém quatro regras que cobrem movimentação entre tiers, exclusão automática de blobs antigos e limpeza de snapshots e versões com mais de 90 dias.

Tarefa 4.3 — Simular erro de configuração: regra com conflito de ações

Nesta tarefa, você tentará criar uma regra com configuração conflitante (mover para Cool e deletar com o mesmo prazo) para entender como o Azure lida com conflitos de lifecycle e como corrigir.

Via Portal

Navegue até Lifecycle management
Clique em + Add a rule
Rule name: regra-conflito-teste
Marque Block blobs e Base blobs
Na aba Base blobs, tente configurar:
- Condição: Last modified > More than (days ago) > 30
- Ação: Move to cool storage
- Adicione outra ação: Delete the blob com o mesmo valor de 30 dias
Observe que o portal impede a configuração ou exibe um aviso sobre o conflito (a ação de delete tem precedência sobre a movimentação quando ambas possuem o mesmo número de dias)
Cancele a criação da regra sem salvar
Reflita sobre a lógica de precedência: se o prazo de delete for menor ou igual ao prazo de movimentação de tier, o blob será excluído antes de ser movido, tornando a regra de movimentação inútil

Via CLI

# Tentar criar uma política com regra conflitante (para fins didáticos)
cat > lifecycle-conflito.json << 'EOF'
{
  "rules": [
    {
      "enabled": true,
      "name": "regra-conflito-teste",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            },
            "delete": {
              "daysAfterModificationGreaterThan": 30
            }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"]
        }
      }
    }
  ]
}
EOF

# Este comando pode ser aceito pelo Azure, mas a ação de delete
# tem precedência, tornando o tierToCool sem efeito.
# NÃO aplique esta política à storage account de produção.
# Em vez disso, apenas analise o JSON e entenda o conflito.
echo "ATENÇÃO: Não aplique esta política. Ela serve apenas para ilustrar o conflito."
echo "O Azure aplica a ação mais destrutiva (delete) quando os prazos são iguais."

Este exercício demonstra a importância de planejar os prazos de lifecycle de forma escalonada: movimentação de tier sempre com prazos menores que os de exclusão, garantindo que o blob passe por todos os tiers antes de ser removido.

Validação Final

Verifique os seguintes critérios para confirmar que o laboratório foi executado corretamente:

File shares e tiers (Fase 1): Navegue até Storage accounts > stdataflowlab > File shares e confirme que existem dois shares ativos: fs-operacoes com tier Transaction optimized e cota de 100 GiB, e fs-arquivo-morto com tier Cool. Via CLI, execute az storage share-rm list --resource-group rg-dataflow-lab --storage-account stdataflowlab --query "[].{name:name, tier:accessTier, quota:shareQuota}" -o table e valide os valores.
Snapshots existentes (Fase 1): Navegue até File shares > fs-operacoes > Snapshots e confirme que ao menos um snapshot existe. O arquivo nota-fiscal-001.txt deve estar presente tanto no share ativo quanto no snapshot.
Blob versioning funcional (Fase 3): Navegue até Containers > ctr-documentos > clique no blob manifesto-carga-2025.txt > aba Versions. Confirme que existem ao menos duas versões. Faça download de ambas e verifique que os conteúdos são diferentes, comprovando que o versionamento preservou o dado original.
Comportamento observável de reidratação (Fase 2): Navegue até Containers > ctr-comprovantes > blob comprovante-entrega-antigo.txt. Verifique o campo Archive status. Se a reidratação ainda estiver em andamento, o status será rehydrate-pending-to-hot. Se já tiver concluído, o tier será Hot e o download será bem-sucedido. Execute o download do blob: se ele completar com sucesso, a reidratação foi concluída; se retornar erro, a reidratação ainda está pendente.
Lifecycle management ativo (Fase 4): Execute az storage account management-policy show --resource-group rg-dataflow-lab --account-name stdataflowlab --query "policy.rules[].{name:name, enabled:enabled}" -o table e confirme que as quatro regras (mover-para-cool-30d, mover-para-archive-180d, excluir-archive-365d, limpar-versoes-antigas) estão listadas com status true.

Cleanup do Ambiente

Para evitar cobranças desnecessárias, remova todos os recursos criados neste laboratório na seguinte ordem:

Via Portal

Navegue até Storage accounts > stdataflowlab
Em Lifecycle management, exclua todas as regras de lifecycle criadas
Em File shares, exclua os snapshots do share fs-operacoes
Exclua os file shares fs-operacoes e fs-arquivo-morto
Em Containers, exclua os containers ctr-documentos e ctr-comprovantes
Navegue até Resource groups > rg-dataflow-lab
Clique em Delete resource group
Digite o nome rg-dataflow-lab para confirmar
Clique em Delete
Aguarde a notificação de conclusão. Navegue até Resource groups e confirme que rg-dataflow-lab não aparece mais na lista

Via CLI

# A exclusão do resource group remove todos os recursos filhos automaticamente
az group delete \
  --name rg-dataflow-lab \
  --yes \
  --no-wait

# Verificar o status da exclusão (pode levar alguns minutos)
az group show \
  --name rg-dataflow-lab \
  --query "properties.provisioningState" 2>&1 || echo "Resource group excluído com sucesso"

Após a confirmação de que o resource group foi removido, nenhum recurso do laboratório permanecerá ativo na subscription.

Cenário​

Pré-requisitos​

Fases do Laboratório​

Fase 1 — Azure Files: File Shares e Snapshots​

Tarefa 1.1 — Criar e configurar o file share principal​

Via Portal​

Via CLI​

Tarefa 1.2 — Criar o file share de arquivo morto e fazer upload de teste​

Via Portal​

Via CLI​

Tarefa 1.3 — Habilitar soft delete para Azure Files​

Via Portal​

Via CLI​

Tarefa 1.4 — Criar snapshot e validar recuperação de arquivo​

Via Portal​

Via CLI​

Tarefa 1.5 — Testar soft delete excluindo e recuperando um file share​

Via Portal​

Via CLI​

Fase 2 — Blob Storage: Containers, Tiers e Upload​

Tarefa 2.1 — Criar containers com diferentes níveis de acesso​

Via Portal​

Via CLI​

Tarefa 2.2 — Fazer upload de blobs com tiers diferentes​

Via Portal​

Via CLI​

Tarefa 2.3 — Alterar tier de um blob e observar o comportamento de reidratação​

Via Portal​

Via CLI​

Fase 3 — Proteção de Dados: Soft Delete, Versionamento e Recuperação de Blobs​

Tarefa 3.1 — Verificar o estado atual de proteção antes de habilitar​

Via Portal​

Via CLI​

Tarefa 3.2 — Habilitar soft delete para blobs e containers​

Via Portal​

Via CLI​

Tarefa 3.3 — Habilitar blob versioning​

Via Portal​

Via CLI​

Tarefa 3.4 — Testar versionamento sobrescrevendo um blob e acessando versões anteriores​

Via Portal​

Via CLI​

Tarefa 3.5 — Testar soft delete excluindo e recuperando um blob​

Via Portal​

Via CLI​

Tarefa 3.6 — Testar soft delete de container​

Via Portal​

Via CLI​

Fase 4 — Lifecycle Management: Políticas de Ciclo de Vida​

Tarefa 4.1 — Criar uma política de lifecycle management com múltiplas regras​

Via Portal​

Via CLI​

Tarefa 4.2 — Adicionar regra de exclusão automática e regra para snapshots e versões​

Via Portal​

Via CLI​

Tarefa 4.3 — Simular erro de configuração: regra com conflito de ações​

Via Portal​

Via CLI​

Validação Final​

Cleanup do Ambiente​

Via Portal​

Via CLI​

Cenário

Pré-requisitos

Fases do Laboratório

Fase 1 — Azure Files: File Shares e Snapshots

Tarefa 1.1 — Criar e configurar o file share principal

Via Portal

Via CLI

Tarefa 1.2 — Criar o file share de arquivo morto e fazer upload de teste

Via Portal

Via CLI

Tarefa 1.3 — Habilitar soft delete para Azure Files

Via Portal

Via CLI

Tarefa 1.4 — Criar snapshot e validar recuperação de arquivo

Via Portal

Via CLI

Tarefa 1.5 — Testar soft delete excluindo e recuperando um file share

Via Portal

Via CLI

Fase 2 — Blob Storage: Containers, Tiers e Upload

Tarefa 2.1 — Criar containers com diferentes níveis de acesso

Via Portal

Via CLI

Tarefa 2.2 — Fazer upload de blobs com tiers diferentes

Via Portal

Via CLI

Tarefa 2.3 — Alterar tier de um blob e observar o comportamento de reidratação

Via Portal

Via CLI

Fase 3 — Proteção de Dados: Soft Delete, Versionamento e Recuperação de Blobs

Tarefa 3.1 — Verificar o estado atual de proteção antes de habilitar

Via Portal

Via CLI

Tarefa 3.2 — Habilitar soft delete para blobs e containers

Via Portal

Via CLI

Tarefa 3.3 — Habilitar blob versioning

Via Portal

Via CLI

Tarefa 3.4 — Testar versionamento sobrescrevendo um blob e acessando versões anteriores

Via Portal

Via CLI

Tarefa 3.5 — Testar soft delete excluindo e recuperando um blob

Via Portal

Via CLI

Tarefa 3.6 — Testar soft delete de container

Via Portal

Via CLI

Fase 4 — Lifecycle Management: Políticas de Ciclo de Vida

Tarefa 4.1 — Criar uma política de lifecycle management com múltiplas regras

Via Portal

Via CLI

Tarefa 4.2 — Adicionar regra de exclusão automática e regra para snapshots e versões

Via Portal

Via CLI

Tarefa 4.3 — Simular erro de configuração: regra com conflito de ações

Via Portal

Via CLI

Validação Final

Cleanup do Ambiente

Via Portal

Via CLI