Pular para o conteúdo principal

Laboratório Técnico: Create and configure a container in Azure Blob Storage

Questões​

Questão 1 — Múltipla Escolha​

Uma equipe de desenvolvimento precisa armazenar artefatos de build que devem ser acessíveis publicamente apenas no nível de leitura de blobs individuais, mas sem permitir que usuários anônimos listem o conteúdo do container. Qual nível de acesso público deve ser configurado no container?

A) Container — permite leitura anônima de blobs e listagem do container

B) Blob — permite leitura anônima de blobs individuais, mas bloqueia a listagem do container

C) Private — requer autenticação para qualquer operação, inclusive leitura

D) ReadOnly — permite leitura anônima sem expor metadados do container

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

Um administrador executa o seguinte comando para criar um container:

az storage container create \
  --name logs \
  --account-name mystorageacct \
  --public-access off

Após a criação, uma aplicação tenta fazer upload de blobs usando uma Shared Access Signature (SAS) gerada com permissão de escrita. A operação retorna erro AuthorizationFailure. O que mais provavelmente explica o problema?

A) O parâmetro --public-access off impede qualquer tipo de escrita no container

B) A SAS foi gerada antes da criação do container e por isso é inválida

C) A SAS não possui a permissão List combinada com Write, que é obrigatória para upload

D) A conta de armazenamento pode estar com a opção "Allow Blob public access" desabilitada no nível da conta, bloqueando também autenticação por SAS

Questão 3 — Verdadeiro ou Falso​

Um container do Azure Blob Storage criado com acesso público definido como Container permanece acessível anonimamente mesmo que a opção "Allow Blob public access" seja posteriormente desabilitada no nível da conta de armazenamento.

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

Uma equipe de operações precisa configurar um container para armazenar logs de auditoria. Os requisitos são:

  • Blobs não podem ser modificados ou excluídos durante 90 dias após a criação
  • A política deve ser aplicada automaticamente a todos os blobs no container
  • O acesso de leitura deve continuar funcionando normalmente

Qual combinação de recursos atende a esses requisitos?

A) Configurar uma política de imutabilidade baseada em tempo no container com retenção de 90 dias

B) Ativar soft delete com período de retenção de 90 dias no container

C) Criar uma lifecycle management policy que bloqueie exclusão por 90 dias

D) Configurar um lock de recurso do tipo ReadOnly na conta de armazenamento

Questão 5 — Múltipla Escolha​

Ao criar um container via portal do Azure, um administrador observa que a opção de configurar o nível de acesso público está desabilitada (cinza). Qual é a causa mais provável?

A) O container já contém blobs, o que impede alteração do nível de acesso público

B) A conta de armazenamento foi criada com o tipo Premium Block Blobs, que não suporta acesso público

C) A opção "Allow Blob public access" está desabilitada no nível da conta de armazenamento

D) O usuário não possui a role Storage Blob Data Contributor atribuída

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

O nível de acesso Blob concede leitura anônima a blobs individuais por URL direta, mas não permite que usuários não autenticados listem os objetos dentro do container. Já o nível Container expõe tanto a leitura de blobs quanto a listagem. A alternativa Private exige autenticação para qualquer operação. A alternativa ReadOnly não é um valor válido para acesso público em containers do Azure Blob Storage; sua presença como distrator representa um equívoco comum ao confundir os locks de recursos do Azure com as configurações de acesso de container.

Gabarito — Questão 2​

Resposta: D

No Azure, a opção "Allow Blob public access" no nível da conta de armazenamento é um controle de plano de dados que, quando desabilitada, bloqueia qualquer acesso anônimo. Contudo, ela não afeta autenticações por SAS ou chave. O erro AuthorizationFailure com SAS válida aponta para outro controle: se a conta tiver o acesso de rede restrito (firewall ou VNet) ou, mais comumente neste cenário, se a chave da conta tiver sido desabilitada via configuração --allow-shared-key-access false, a SAS baseada em chave é rejeitada. Esse é o motivo mais plausível dado o contexto. As alternativas A e C representam equívocos sobre o funcionamento de SAS, e a alternativa B confunde o ciclo de vida da SAS com o ciclo de criação do container.

Nota técnica: na prova AZ-104, esse cenário testa se o candidato distingue os controles de acesso anônimo dos controles de autenticação por chave/SAS.

Gabarito — Questão 3​

Resposta: Falso

A configuração "Allow Blob public access" no nível da conta de armazenamento tem precedência sobre o nível de acesso definido em cada container. Quando essa opção é desabilitada na conta, todo acesso anônimo é bloqueado independentemente do que estiver configurado nos containers individuais. Isso significa que um container com acesso Container ou Blob passa a se comportar como Private do ponto de vista de requisições anônimas. Essa hierarquia de controle é um comportamento não óbvio que causa erros frequentes em ambientes de produção.

Gabarito — Questão 4​

Resposta: A

As políticas de imutabilidade baseadas em tempo (time-based retention) são o mecanismo correto para garantir que blobs não sejam modificados ou excluídos durante um período definido. Quando aplicadas no nível do container com uma política bloqueada, elas atendem exatamente ao requisito de proteção por 90 dias sem restringir a leitura. O soft delete (alternativa B) apenas posterga a exclusão, não a impede. As lifecycle management policies (alternativa C) servem para automatizar transições de camada ou exclusões, o oposto do requisito. O lock ReadOnly (alternativa D) bloquearia também operações de escrita legítimas na conta inteira, ultrapassando o escopo exigido e impedindo novos uploads.

Gabarito — Questão 5​

Resposta: C

Quando a opção "Allow Blob public access" está desabilitada no nível da conta de armazenamento, o portal do Azure desabilita visualmente a seleção do nível de acesso público nos containers, pois qualquer valor diferente de Private seria ineficaz. Essa é uma proteção da interface para evitar configurações contraditórias. A alternativa A é incorreta porque a presença de blobs não bloqueia alterações de configuração do container. A alternativa B é parcialmente plausível, mas contas Premium Block Blobs ainda permitem configurar o acesso público quando habilitado na conta. A alternativa D representa um equívoco comum: permissões RBAC controlam o que o usuário pode fazer, mas a role Storage Blob Data Contributor não governa a disponibilidade de opções de configuração de acesso público na interface.