O Azure Blob Storage e um servico de armazenamento de objetos que pode armazenar qualquer forma de dados nao estruturados — imagens, videos, documentos, arquivos de log e muito mais. Para o exame AZ-204, os topicos principais sao uso do SDK, distinguir propriedades vs metadados, camadas de armazenamento, politicas de ciclo de vida e politicas de imutabilidade.
SDK: Tres Classes de Cliente
Para entender o SDK do Blob Storage, o mais importante e distinguir os papeis de tres classes de cliente. Pense em um condominio de apartamentos como exemplo. E como a relacao entre o escritorio de administracao que gerencia todo o condominio (BlobServiceClient), cada predio (BlobContainerClient) e cada unidade individual (BlobClient).
| Classe | Funcao | Analogia | |--------|--------|---------| | BlobServiceClient | Conecta-se a toda a conta de armazenamento | Escritorio de administracao do condominio | | BlobContainerClient | Acessa um container especifico (pasta) | Gerenciamento de um predio especifico | | BlobClient | Manipula um arquivo blob especifico | Uma unidade especifica |
Cada cliente pode ser obtido a partir de seu cliente pai ou criado diretamente com uma URL.
Padroes de Operacoes Principais
Carregar: blob_client.upload_blob(data, overwrite=True) Baixar: blob_client.download_blob().readall() Excluir: blob_client.delete_blob() Criar container: container_client.create_container() Listar blobs: container_client.list_blobs()
Se voce nao especificar overwrite=True ao carregar, ocorre uma excecao ao tentar carregar para um blob existente.
Propriedades e Metadados: Armazenando Informacoes Sobre Arquivos
Alem do arquivo blob em si, voce pode armazenar informacoes sobre o arquivo de duas maneiras. Pense em um livro como exemplo. As propriedades do livro (espessura, numero de paginas, cor da capa — caracteristicas fisicas) sao diferentes em natureza das etiquetas que a biblioteca coloca (numero de chamada, localizacao na estante, disponibilidade).
Propriedades do Sistema
Propriedades gerenciadas automaticamente pelo Azure, diretamente vinculadas a cabecalhos HTTP.
Content-Type: Formato do arquivo (ex.: image/jpeg, application/pdf) Content-Length: Tamanho do arquivo em bytes ETag: Identificador de versao (usado para controle de simultaneidade otimista) Last-Modified: Hora da ultima modificacao Content-Encoding, Content-Language, etc.
Essas propriedades podem ser recuperadas via SDK ou API REST, e algumas podem ser modificadas.
Metadados Definidos pelo Usuario
Pares chave-valor que os desenvolvedores definem arbitrariamente. Sao gerenciados separadamente, nao armazenados diretamente no blob.
Formato: pares chave=valor (ex.: author=Joao, project=alpha, environment=production) Deve seguir as regras de nomenclatura de cabecalhos HTTP (apenas letras, numeros, hifens) Recuperar: blob_client.get_blob_properties().metadata Definir: blob_client.set_blob_metadata({"author": "Joao"})
Questoes do exame frequentemente testam se voce consegue distinguir propriedades do sistema de metadados definidos pelo usuario.
Camadas de Armazenamento: Otimizacao de Custos com Base na Frequencia de Acesso
A camada de armazenamento adequada depende da frequencia com que voce precisa acessar os dados. Pense em uma geladeira e um deposito como exemplo. Alimentos que voce come com frequencia vao na geladeira (Hot), itens de uso ocasional vao no deposito (Cool), itens raramente usados vao em um deposito mais profundo (Cold) ou armazenamento de longo prazo (Archive).
| Camada | Caracteristicas | Duracao Minima de Armazenamento | Custo de Acesso | Custo de Armazenamento | |--------|----------------|--------------------------------|-----------------|----------------------| | Hot | Dados acessados com frequencia | Nenhuma | Baixo | Mais alto | | Cool | Dados acessados ocasionalmente | 30 dias | Medio | Medio | | Cold | Dados acessados raramente | 90 dias | Alto | Baixo | | Archive | Dados quase nunca acessados | 180 dias | Mais alto | Mais baixo |
Voce deve lembrar as caracteristicas especiais da camada Archive.
Estado offline: Blobs no Archive nao podem ser lidos diretamente Rehidratacao: Para ler dados, voce deve mova-los para a camada Hot ou Cool, o que leva tempo Prioridade de rehidratacao: Padrao (varias horas ate 15 horas), Alta (dentro de 1 hora, custo adicional)
Se voce alterar camadas ou excluir antes da duracao minima de armazenamento, taxas de exclusao antecipada se aplicam.
Gerenciamento do Ciclo de Vida
Voce pode definir politicas para alterar automaticamente a camada de um blob ou exclui-lo ao longo do tempo. Como a politica de retencao de documentos de uma empresa — regras como "arquivos com mais de 3 meses vao para o armazenamento, arquivos com mais de 1 ano sao destruidos" sao executadas automaticamente.
As politicas de ciclo de vida sao definidas no formato JSON.
Componentes da regra: Filtros (selecionar blobs alvo) + Acoes (o que fazer) Condicoes de filtro: Prefixo do nome do blob, tipo de blob, data da ultima modificacao, etc. Acoes suportadas: tierToCool, tierToCold, tierToArchive, delete Frequencia de execucao: Executado uma vez por dia
Por exemplo, voce pode definir uma unica politica: "blobs nao modificados por 30+ dias vao para Cool, 90+ dias vao para Archive, 365+ dias sao excluidos."
Politica de Imutabilidade: Prevenindo Alteracoes nos Dados
Um recurso que protege os dados do blob de serem modificados ou excluidos por requisitos regulatorios ou obrigacoes legais. Como guardar um contrato notariado em um cofre. Mesmo com permissoes, nao pode ser alterado durante o periodo de retencao.
Politica de Retencao Baseada em Tempo
Os blobs nao podem ser modificados ou excluidos por um periodo especificado.
Periodo de retencao: 1 dia a 146.000 dias (400 anos) Antes de bloquear: A politica pode ser modificada ou excluida Apos bloquear (Bloqueado): O periodo de retencao nao pode ser encurtado, a politica nao pode ser excluida (apenas extensao permitida) Casos de uso: Registros financeiros, dados medicos, retencao de documentos legais
Legal Hold
Protege os blobs indefinidamente durante disputas legais ou investigacoes para preservar evidencias.
Ativado/desativado via tags Enquanto o Legal Hold esta ativo, os blobs nao podem ser modificados ou excluidos Varias tags podem ser aplicadas simultaneamente
| Tipo de Politica | Duracao | Bloqueio | Caso de Uso | |-----------------|---------|---------|-------------| | Retencao Baseada em Tempo | Periodo especificado | Bloqueavel | Conformidade, retencao legal | | Legal Hold | Indefinida | Liberado via tag | Disputas legais, investigacoes |
!Retenção baseada em tempo vs Legal Hold
Pontos-chave do exame
"Conectar a toda a conta de armazenamento" -- BlobServiceClient
"Acessar container especifico" -- BlobContainerClient
"Manipular arquivo especifico (carregar/baixar/excluir)" -- BlobClient
"Informacao do arquivo gerenciada via cabecalhos HTTP" -- Propriedades do sistema (Content-Type, ETag, etc.)
"Pares chave-valor definidos por desenvolvedores" -- Metadados definidos pelo usuario
"Para ler dados do Archive" -- Rehidratacao necessaria (mover para Hot/Cool)
"Armazenamento minimo: Hot=nenhum, Cool=30 dias, Cold=90 dias, Archive=180 dias"
"Transicoes de camada automaticas/exclusao via politica JSON" -- Gerenciamento do ciclo de vida
"Bloquear modificacao/exclusao por periodo especificado" -- Politica de retencao baseada em tempo
"Bloquear modificacao/exclusao indefinidamente, liberado via tag" -- Legal Hold