Fundamentação Teórica: Create and Configure a Container in Azure Blob Storage

1. Intuição Inicial

Imagine que uma Storage Account é um armazém. Dentro desse armazém, você não joga caixas aleatoriamente no chão: você organiza o espaço em seções ou corredores, cada um com sua própria etiqueta e regras de acesso. No Azure Blob Storage, essas seções são chamadas de containers.

Um container é a unidade de organização dentro do Blob Storage. Ele agrupa blobs (arquivos) relacionados e é o nível onde você define configurações de acesso, políticas de ciclo de vida e regras de replicação.

Todo blob no Azure Blob Storage existe obrigatoriamente dentro de um container. Não existe blob "solto" numa Storage Account.

2. Contexto

2.1 Hierarquia do Blob Storage

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

2.2 Por que containers existem

O Blob Storage é um namespace plano: não existe hierarquia de diretórios real como num sistema de arquivos. Um container é a única camada de organização real. Tudo abaixo dele (o que parece ser subpastas) é na verdade um prefixo no nome do blob.

Por exemplo, um blob com o nome relatorios/2025/janeiro/vendas.xlsx não está dentro de pastas reais. O nome inteiro é o identificador do blob, e a barra / é apenas um caractere convencional usado para simular hierarquia.

2.3 O que você configura no container

O container é o nível onde se definem:

Nível de acesso público (quem pode acessar sem autenticação)
Políticas de acesso armazenado (Stored Access Policies para SAS tokens)
Encryption Scope padrão (chave de criptografia específica)
Immutability Policies (WORM: Write Once Read Many)
Metadados do container (pares chave-valor personalizados)

3. Construção dos Conceitos

3.1 Tipos de blob

Antes de entender containers em profundidade, é preciso conhecer o que eles armazenam. O Azure Blob Storage tem três tipos de blob, e cada container pode conter qualquer combinação deles:

Block Blob:

Blob de propósito geral para arquivos não estruturados
Dividido em blocos de até 4.000 MiB cada
Tamanho máximo: 190,7 TiB
Usos: imagens, vídeos, documentos, backups, datasets

Append Blob:

Otimizado para operações de adição (append) ao final
Não permite modificar blocos existentes
Tamanho máximo: 195 GiB
Usos: logs, dados de telemetria, streams de eventos

Page Blob:

Organizado em páginas de 512 bytes
Permite leitura e escrita aleatória eficiente
Tamanho máximo: 8 TiB
Usos: discos de VMs não gerenciados (VHDs)

Comportamento não óbvio: Você não escolhe o tipo de blob ao criar o container. O tipo é definido no momento de criar/fazer upload de cada blob individualmente. Um único container pode ter os três tipos coexistindo.

3.2 Nível de acesso público do container

Este é um dos conceitos mais importantes e mais mal compreendidos do Blob Storage. Existem três níveis:

Private (padrão):

Nenhum acesso anônimo
Todo acesso requer autenticação (chave, SAS, Azure AD)
Recomendado para todos os dados que não são intencionalmente públicos

Blob:

Blobs individuais podem ser acessados anonimamente se você conhecer a URL completa
Não é possível listar os blobs do container de forma anônima
Útil quando você quer que URLs específicas sejam públicas sem expor o inventário

Container:

Acesso anônimo total: qualquer pessoa pode listar todos os blobs e acessar qualquer blob
Nunca usar para dados sensíveis
Útil apenas para conteúdo verdadeiramente público (assets de websites públicos)

Nível	Leitura de blob com URL	Listagem de blobs	Uso
Private	Não (requer auth)	Não	Padrão para todos os dados
Blob	Sim (URL conhecida)	Não	Links de download público
Container	Sim	Sim	Assets completamente públicos

Ponto crítico de segurança: Desde 2023, o Azure adicionou uma configuração no nível da Storage Account chamada "Allow Blob Anonymous Access" que controla se o acesso público pode ser habilitado em qualquer container da conta. Se essa configuração estiver false (recomendado para produção), nenhum container da conta pode ter acesso público, independentemente da configuração individual do container.

3.3 Diretórios virtuais e prefixos

Como mencionado, o Blob Storage não tem diretórios reais. O que parece ser uma pasta é um prefixo no nome do blob:

Blob real: relatorios/2025/janeiro/vendas.xlsx
Container: dados
URL completa: https://myaccount.blob.core.windows.net/dados/relatorios/2025/janeiro/vendas.xlsx

A API de listagem permite filtrar blobs por prefixo usando o parâmetro prefix, o que simula a navegação por "pastas". O Storage Explorer e o portal renderizam esses prefixos como pastas visualmente.

Quando você cria uma "pasta" no portal ou no Storage Explorer, o que acontece na prática é que um blob vazio (um placeholder) com o nome pasta/ é criado. Algumas operações removem esse placeholder automaticamente.

3.4 Immutability Policies (WORM)

Containers podem ser configurados com políticas de imutabilidade que impedem modificação ou exclusão de blobs por um período definido. Existem dois tipos:

Time-based Retention Policy:

Define um período de retenção (em dias) durante o qual blobs não podem ser deletados nem modificados
Após o período, blobs podem ser deletados normalmente
Pode ser aplicada no nível do container ou do blob individual

Legal Hold:

Bloqueio sem prazo definido
Removido apenas quando o hold é explicitamente liberado
Usado para processos jurídicos e auditorias

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Comportamento crítico: Uma vez que uma Time-based Retention Policy é bloqueada (Locked), o período de retenção não pode ser reduzido, apenas aumentado. Isso é intencional para conformidade regulatória (FINRA, SEC, CFTC). Teste sempre em ambiente de não-produção antes de bloquear.

3.5 Stored Access Policies

Uma Stored Access Policy é uma política de acesso armazenada no nível do container que pode ser referenciada por múltiplos SAS tokens. A vantagem é que você pode revogar ou modificar o acesso de todos os SAS tokens que referenciam uma policy simplesmente atualizando ou deletando a policy, sem precisar invalidar cada token individualmente.

4. Visão Estrutural

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

5. Funcionamento na Prática

5.1 Nomenclatura de containers

As regras de nomenclatura são estritas e falhas aqui causam erros difíceis de diagnosticar:

3 a 63 caracteres
Apenas letras minúsculas, números e hífens
Deve começar com letra ou número
Não pode ter hífens consecutivos
O nome $root é um container especial reservado (o "root container")
O nome $web é reservado para hospedagem estática de sites

5.2 O container `$web` e hospedagem estática

Quando você habilita Static Website em uma Storage Account, o Azure cria automaticamente um container especial chamado $web. Arquivos colocados nesse container são servidos diretamente como um site estático via um endpoint separado:

https://myaccount.z13.web.core.windows.net

Este endpoint é diferente do endpoint de blob normal. Ele serve arquivos como um servidor web, incluindo um arquivo de índice (index.html) e uma página de erro 404 personalizável.

5.3 Leases em containers e blobs

Um lease é um bloqueio temporário que pode ser aplicado a um container ou blob. Enquanto o lease está ativo:

Lease em container: Somente o detentor do lease pode deletar o container
Lease em blob: Somente o detentor do lease pode modificar ou deletar o blob

Estados de lease:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Leases são usados por ferramentas como AzCopy e Storage Explorer durante transferências para garantir que outros processos não modifiquem o blob enquanto a operação está em andamento.

5.4 Versioning e Snapshots no contexto do container

Quando Blob Versioning está habilitado na Storage Account (configuração no nível da conta, não do container):

Cada modificação em um blob cria uma nova versão automaticamente
A versão atual é a mais recente
Versões anteriores são somente leitura
Versões são armazenadas no mesmo container do blob original

Quando você cria um Snapshot manualmente:

É uma cópia somente leitura do blob em um momento específico
Identificado pela data e hora de criação
Armazenado no mesmo container
URL tem o sufixo ?snapshot=2025-01-15T10:30:00.0000000Z

6. Formas de Implementação

6.1 Portal Azure

Quando usar: Criação pontual, exploração, configuração de acesso público, aplicação de policies.

No portal: Storage Account > Containers > + Container

Você define:

Nome do container
Nível de acesso público (se Allow Anonymous Access estiver habilitado na conta)
Encryption Scope padrão (opcional)

Limitação: Não suporta criação em massa nem configuração de Immutability Policy diretamente na criação (é uma etapa separada).

6.2 Azure CLI

Criando um container:

# Container simples (privado, padrão)
az storage container create \
  --account-name myaccount \
  --name images \
  --auth-mode login

# Container com acesso público no nível de blob
az storage container create \
  --account-name myaccount \
  --name public-assets \
  --public-access blob \
  --auth-mode login

# Container com Encryption Scope padrão
az storage container create \
  --account-name myaccount \
  --name finance-data \
  --default-encryption-scope FinanceScope \
  --prevent-encryption-scope-override true \
  --auth-mode login

Listando containers:

az storage container list \
  --account-name myaccount \
  --auth-mode login \
  --output table

Configurando metadados:

az storage container metadata update \
  --account-name myaccount \
  --name images \
  --metadata department=marketing environment=production \
  --auth-mode login

Aplicando Stored Access Policy:

az storage container policy create \
  --account-name myaccount \
  --container-name images \
  --name ReadOnlyPolicy \
  --permissions r \
  --expiry 2025-12-31 \
  --auth-mode login

Configurando Time-based Retention Policy:

# Criar policy (estado unlocked)
az storage container immutability-policy create \
  --account-name myaccount \
  --resource-group myRG \
  --container-name compliance-data \
  --period 365

# Bloquear a policy (irreversível para redução)
az storage container immutability-policy lock \
  --account-name myaccount \
  --resource-group myRG \
  --container-name compliance-data \
  --if-match "<etag-da-policy>"

6.3 Azure PowerShell

# Criar contexto
$ctx = New-AzStorageContext `
  -StorageAccountName "myaccount" `
  -UseConnectedAccount

# Criar container privado
New-AzStorageContainer `
  -Name "images" `
  -Context $ctx

# Criar container com acesso público
New-AzStorageContainer `
  -Name "public-assets" `
  -Context $ctx `
  -Permission Blob

# Fazer upload de arquivo para container
Set-AzStorageBlobContent `
  -Container "images" `
  -File "/local/path/photo.jpg" `
  -Blob "products/photo.jpg" `
  -Context $ctx `
  -StandardBlobTier Hot

# Listar blobs com prefixo (simular navegação por pasta)
Get-AzStorageBlob `
  -Container "images" `
  -Prefix "products/" `
  -Context $ctx

6.4 Bicep

// Container privado
resource container 'Microsoft.Storage/storageAccounts/blobServices/containers@2023-01-01' = {
  name: '${storageAccount.name}/default/images'
  properties: {
    publicAccess: 'None'
    defaultEncryptionScope: 'FinanceScope'
    denyEncryptionScopeOverride: true
    metadata: {
      department: 'marketing'
      environment: 'production'
    }
  }
}

// Container com Immutability Policy (unlocked)
resource complianceContainer 'Microsoft.Storage/storageAccounts/blobServices/containers@2023-01-01' = {
  name: '${storageAccount.name}/default/compliance-data'
  properties: {
    publicAccess: 'None'
    immutableStorageWithVersioning: {
      enabled: true
    }
  }
}

6.5 REST API

Para cenários onde nem CLI nem SDK estão disponíveis:

# Criar container via REST API com SAS token
curl -X PUT \
  "https://myaccount.blob.core.windows.net/mycontainer?restype=container&<SAS-TOKEN>" \
  -H "x-ms-version: 2023-01-03" \
  -H "x-ms-blob-public-access: blob" \
  -H "Content-Length: 0"

7. Controle e Segurança

7.1 Controle de acesso em camadas

O acesso a um container e seus blobs é determinado por uma avaliação em cadeia:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

7.2 Roles RBAC relevantes para containers

Role	O que permite
Storage Blob Data Owner	Leitura, escrita, exclusão e controle de ACLs (ADLS Gen2)
Storage Blob Data Contributor	Leitura, escrita e exclusão de blobs
Storage Blob Data Reader	Somente leitura de blobs
Storage Blob Delegator	Pode gerar User Delegation SAS tokens

Distinção importante: Storage Account Contributor é uma role de plano de controle (gerenciar a conta, suas configurações). Ela não concede acesso aos dados dos blobs. Para acesso aos dados, as roles Storage Blob Data * são necessárias.

7.3 Soft Delete de containers e blobs

Soft Delete de blobs: Quando habilitado na Storage Account, blobs deletados ficam em estado "soft-deleted" por um período configurável (1 a 365 dias) antes de serem permanentemente removidos. Durante esse período, podem ser restaurados.

Soft Delete de containers: Similar, mas para containers inteiros. Um container deletado fica "soft-deleted" e pode ser restaurado com todos os seus blobs.

# Habilitar soft delete de containers
az storage account blob-service-properties update \
  --account-name myaccount \
  --resource-group myRG \
  --container-delete-retention-days 30 \
  --enable-container-delete-retention true

# Habilitar soft delete de blobs
az storage account blob-service-properties update \
  --account-name myaccount \
  --resource-group myRG \
  --delete-retention-days 7 \
  --enable-delete-retention true

# Listar containers soft-deleted
az storage container list \
  --account-name myaccount \
  --include-deleted \
  --auth-mode login

# Restaurar container soft-deleted
az storage container restore \
  --account-name myaccount \
  --deleted-container-name images \
  --deleted-container-version <version-id> \
  --auth-mode login

8. Tomada de Decisão

8.1 Nível de acesso público do container

Situação	Nível de acesso	Motivo
Dados de clientes, financeiros, pessoais	Private	Nenhum dado sensível deve ser público
Assets de website público (CSS, JS, imagens)	Blob ou Container	Acesso público necessário
Links de download temporários	Private + SAS	Controle com expiração
CDN servindo conteúdo	Blob	CDN autentica, usuário final não precisa
Conformidade regulatória	Private + Immutability	Proteção total contra modificação
Logs de auditoria de longo prazo	Private + Archive tier	Baixo custo, acesso raro

8.2 Organização de containers

Abordagem	Quando usar	Trade-off
Um container por tipo de dado (images, videos, docs)	Dados homogêneos com mesmas configurações	Simples, mas sem isolamento de segurança entre dados
Um container por aplicação	Múltiplas aplicações na mesma conta	Bom isolamento por app
Um container por departamento	Diferentes equipes com dados sensíveis	Permite RBAC granular por container
Um container por ambiente (prod, dev, test)	Ciclos de vida e políticas diferentes	Mais containers, mas políticas distintas
Container único com prefixos	Volume enorme de blobs com mesmo padrão	Menor overhead, mas sem isolamento

8.3 Immutability: Locked vs Unlocked

Situação	Policy estado	Motivo
Conformidade regulatória SEC Rule 17a-4	Locked	Regulação exige imutabilidade irreversível
Teste de política antes de produção	Unlocked	Permite ajustes e cancelamento
Dados jurídicos em processo ativo	Legal Hold	Sem prazo definido, liberação explícita
Backups com retenção garantida	Locked com período definido	Proteção contra ransomware

9. Boas Práticas

Desabilite "Allow Blob Anonymous Access" no nível da Storage Account em ambientes de produção, a menos que acesso público seja explicitamente necessário. Isso impede que qualquer container da conta seja acidentalmente configurado como público.
Use prefixos consistentes para organizar blobs dentro de containers: <ano>/<mês>/<dia>/arquivo para logs, <categoria>/<subcategoria>/arquivo para assets.
Habilite Soft Delete para containers e blobs com pelo menos 7 dias de retenção em produção. O custo adicional é mínimo comparado ao risco de perda de dados.
Separe dados por ciclo de vida em containers diferentes. Dados que devem ir para Archive após 90 dias ficam melhor em um container dedicado com lifecycle policy apontando para esse container.
Use Stored Access Policies em vez de SAS tokens ad-hoc quando precisar de múltiplos tokens com as mesmas permissões. Facilita a revogação centralizada.
Aplique metadados aos containers com environment, team, project e cost-center para facilitar governança e rastreabilidade de custos.
Para containers de conformidade, use Immutability Policy no estado Unlocked primeiro, teste em não-produção e só bloqueie (Lock) quando tiver certeza absoluta do período de retenção.
Nunca use chaves de acesso da Storage Account diretamente em aplicações. Prefira User Delegation SAS (gerado com credenciais Azure AD) ou RBAC.

10. Erros Comuns

Erro	Por que acontece	Como evitar
Container público expõe dados sensíveis	Configuração de acesso do container não verificada	Auditar via Azure Policy: "Storage account public access should be disallowed"
Não consegue deletar container com Immutability	Policy ativa com retention period não expirado	Verificar estado da policy antes de tentar deletar
"Blob not found" em container público	Nível de acesso "Blob" mas tentativa de listar sem autenticação	Nível "Blob" não permite listagem anônima, apenas acesso por URL
Soft delete não restaura blobs	Soft delete habilitado após os blobs já terem sido deletados	Habilitar soft delete antes de qualquer operação crítica
Containers não aparecem no portal após deleção	Soft delete de container ativado, container está em estado deleted	Usar `az storage container list --include-deleted`
SAS token para container não consegue listar blobs	Permissão `l` (list) não incluída no SAS	Incluir `l` nas permissões do SAS quando listagem é necessária
Naming error na criação	Letras maiúsculas ou underscores no nome	Usar apenas minúsculas, números e hífens
Lifecycle policy não move blobs para Archive	Container não tem a camada Archive disponível (conta Premium)	Archive só está disponível em Standard GPv2

11. Operação e Manutenção

11.1 Políticas de ciclo de vida (Lifecycle Management)

Definidas no nível da Storage Account mas aplicadas por container via filtros:

{
  "rules": [
    {
      "name": "images-lifecycle",
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["images/"]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 180 },
            "delete": { "daysAfterModificationGreaterThan": 730 }
          },
          "snapshot": {
            "delete": { "daysAfterCreationGreaterThan": 90 }
          }
        }
      }
    }
  ]
}

Via CLI:

az storage account management-policy create \
  --account-name myaccount \
  --resource-group myRG \
  --policy @lifecycle-policy.json

11.2 Monitoramento de containers

Métricas relevantes no Azure Monitor:

Métrica	O que indica
BlobCount	Número de blobs por container (filtrar por `ContainerName`)
BlobCapacity	Capacidade utilizada em bytes por container
Transactions	Número de operações (pode indicar uso anômalo)
SuccessE2ELatency	Latência das operações

Configure alertas para detectar crescimento inesperado de BlobCapacity em containers com cotas esperadas.

11.3 Limites importantes

Recurso	Limite
Containers por Storage Account	Ilimitado
Blobs por container	Ilimitado
Tamanho máximo de um Block Blob	190,7 TiB
Tamanho máximo de um Append Blob	195 GiB
Tamanho máximo de um Page Blob	8 TiB
Snapshots por blob	Ilimitado (prática: gerenciar lifecycle)
Stored Access Policies por container	5

12. Integração e Automação

12.1 Event Grid: reagindo a eventos do container

Containers emitem eventos para o Azure Event Grid:

Microsoft.Storage.BlobCreated
Microsoft.Storage.BlobDeleted
Microsoft.Storage.BlobRenamed (apenas ADLS Gen2)

Isso permite construir pipelines serverless:

az eventgrid event-subscription create \
  --name blob-created-trigger \
  --source-resource-id <storage-account-id> \
  --endpoint <azure-function-url> \
  --included-event-types Microsoft.Storage.BlobCreated \
  --subject-begins-with /blobServices/default/containers/images/

O filtro --subject-begins-with garante que apenas eventos do container images disparem a função.

12.2 Azure Policy para governança de containers

Políticas built-in relevantes:

# Garantir que acesso público seja bloqueado
az policy assignment create \
  --name "deny-blob-public-access" \
  --policy "d9844e8a-1437-4aeb-a32c-0761373107d4" \
  --scope "/subscriptions/<sub-id>"

# Auditar containers sem soft delete habilitado
az policy assignment create \
  --name "audit-soft-delete" \
  --policy "1a87f16b-6e53-4f10-8d29-9f44d3e2d2b2" \
  --scope "/subscriptions/<sub-id>"

12.3 ADLS Gen2: containers como sistemas de arquivo

Quando a Storage Account tem Hierarchical Namespace (HNS) habilitado, os containers do Blob Storage tornam-se file systems do Azure Data Lake Storage Gen2:

Diretórios reais (não apenas prefixos)
Permissões POSIX por diretório e arquivo (ACLs)
Operações atômicas de renomeação de diretório
Performance superior para workloads de analytics

A nomenclatura muda: no contexto ADLS Gen2, o que seria um container passa a ser chamado de filesystem, mas tecnicamente é o mesmo recurso.

13. Resumo Final

Conceitos essenciais:

Um container é a única unidade de organização real no Blob Storage. Todo blob existe dentro de um container.
O Blob Storage tem namespace plano: o que parece ser hierarquia de pastas são prefixos no nome dos blobs.
Containers têm três níveis de acesso público: Private (padrão), Blob (URL específica) e Container (listagem + leitura pública).
A configuração "Allow Blob Anonymous Access" na conta controla se qualquer container pode ter acesso público.

Diferenças críticas:

Blob vs Container access level: Nível "Blob" permite acesso por URL mas não listagem. Nível "Container" permite ambos.
Soft Delete de container vs blob: São configurações separadas, com períodos de retenção independentes.
Storage Account Contributor vs Storage Blob Data Contributor: O primeiro gerencia a conta (plano de controle). O segundo acessa os dados (plano de dados).
Immutability Locked vs Unlocked: Unlocked pode ser cancelado. Locked só pode ter o período aumentado, nunca reduzido ou removido.
Stored Access Policy vs SAS token direto: SAP permite revogação centralizada. SAS direto não pode ser revogado individualmente.

O que precisa ser lembrado:

Nomes de containers: 3 a 63 caracteres, apenas minúsculas, números e hífens.
Máximo de 5 Stored Access Policies por container.
Immutability Policy Locked é irreversível para redução de período.
Soft Delete deve ser habilitado antes de deletar dados; não protege exclusões anteriores à habilitação.
Archive tier só está disponível em Standard GPv2, não em contas Premium.
O container $web é reservado para Static Website hosting.
Em ADLS Gen2, containers são chamados de filesystems e suportam diretórios reais e ACLs POSIX.

1. Intuição Inicial​

2. Contexto​

2.1 Hierarquia do Blob Storage​

2.2 Por que containers existem​

2.3 O que você configura no container​

3. Construção dos Conceitos​

3.1 Tipos de blob​

3.2 Nível de acesso público do container​

3.3 Diretórios virtuais e prefixos​

3.4 Immutability Policies (WORM)​

3.5 Stored Access Policies​

4. Visão Estrutural​

5. Funcionamento na Prática​

5.1 Nomenclatura de containers​

5.2 O container $web e hospedagem estática​

5.3 Leases em containers e blobs​

5.4 Versioning e Snapshots no contexto do container​

6. Formas de Implementação​

6.1 Portal Azure​

6.2 Azure CLI​

6.3 Azure PowerShell​

6.4 Bicep​

6.5 REST API​

7. Controle e Segurança​

7.1 Controle de acesso em camadas​

7.2 Roles RBAC relevantes para containers​

7.3 Soft Delete de containers e blobs​

8. Tomada de Decisão​

8.1 Nível de acesso público do container​

8.2 Organização de containers​

8.3 Immutability: Locked vs Unlocked​

9. Boas Práticas​

10. Erros Comuns​

11. Operação e Manutenção​

11.1 Políticas de ciclo de vida (Lifecycle Management)​

11.2 Monitoramento de containers​

11.3 Limites importantes​

12. Integração e Automação​

12.1 Event Grid: reagindo a eventos do container​

12.2 Azure Policy para governança de containers​

12.3 ADLS Gen2: containers como sistemas de arquivo​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

2.1 Hierarquia do Blob Storage

2.2 Por que containers existem

2.3 O que você configura no container

3. Construção dos Conceitos

3.1 Tipos de blob

3.2 Nível de acesso público do container

3.3 Diretórios virtuais e prefixos

3.4 Immutability Policies (WORM)

3.5 Stored Access Policies

4. Visão Estrutural

5. Funcionamento na Prática

5.1 Nomenclatura de containers

5.2 O container `$web` e hospedagem estática

5.3 Leases em containers e blobs

5.4 Versioning e Snapshots no contexto do container

6. Formas de Implementação

6.1 Portal Azure

6.2 Azure CLI

6.3 Azure PowerShell

6.4 Bicep

6.5 REST API

7. Controle e Segurança

7.1 Controle de acesso em camadas

7.2 Roles RBAC relevantes para containers

7.3 Soft Delete de containers e blobs

8. Tomada de Decisão

8.1 Nível de acesso público do container

8.2 Organização de containers

8.3 Immutability: Locked vs Unlocked

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

11.1 Políticas de ciclo de vida (Lifecycle Management)

11.2 Monitoramento de containers

11.3 Limites importantes

12. Integração e Automação

12.1 Event Grid: reagindo a eventos do container

12.2 Azure Policy para governança de containers

12.3 ADLS Gen2: containers como sistemas de arquivo

13. Resumo Final