Pular para o conteúdo principal

Laboratório Técnico: Configure deployment slots for an App Service

Questões​

Questão 1 — Múltipla Escolha​

Uma equipe de desenvolvimento utiliza o Azure App Service com um slot de staging. Após validar a aplicação no slot de staging, a equipe executa uma operação de swap entre staging e production. Qual é o comportamento esperado em relação às configurações de slot (slot settings)?

A. As configurações de slot são trocadas junto com o conteúdo da aplicação, migrando do staging para production.

B. As configurações de slot permanecem fixas em seus respectivos slots e não acompanham o swap.

C. As configurações de slot são excluídas automaticamente após o swap para evitar conflitos de ambiente.

D. As configurações de slot são copiadas para o slot de destino, mas mantidas também no slot de origem.

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

Um administrador precisa garantir que, ao fazer swap entre staging e production, o App Service não receba requisições de usuários finais durante a fase de aquecimento. O slot de staging está configurado com a opção padrão e não há nenhuma configuração especial ativa no momento.

Qual funcionalidade deve ser habilitada para atender a esse requisito?

A. Habilitar Always On no slot de staging para que a inicialização ocorra antes do swap.

B. Configurar o Auto Swap apontando diretamente para production, eliminando a fase de transição.

C. Ativar a opção Swap with Preview, que mantém o slot de staging recebendo as configurações de production antes de concluir o swap.

D. Aumentar o Health Check interval para que o App Service aguarde mais tempo antes de rotear tráfego.

Questão 3 — Múltipla Escolha​

Considere o seguinte cenário de configuração de variáveis em um App Service:

Slot: production
  APP_ENV = production      (slot setting: false)
  DB_CONN = conn-prod       (slot setting: true)

Slot: staging
  APP_ENV = staging         (slot setting: false)
  DB_CONN = conn-staging    (slot setting: true)

Após um swap entre production e staging, qual será o estado de APP_ENV e DB_CONN no slot production?

A. APP_ENV = production e DB_CONN = conn-prod

B. APP_ENV = staging e DB_CONN = conn-prod

C. APP_ENV = production e DB_CONN = conn-staging

D. APP_ENV = staging e DB_CONN = conn-staging

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

Uma organização utiliza um plano Standard S1 do App Service. O time de infraestrutura tenta criar um quinto deployment slot para suportar um novo ambiente de QA dedicado, mas a operação falha com erro de limite excedido.

az webapp deployment slot create \
  --name myapp \
  --resource-group myRG \
  --slot qa-dedicated

Qual é a causa do erro e qual é a ação correta?

A. O nome do slot contém um hífen, que não é permitido. Deve-se renomear para qadedicated.

B. O plano Standard suporta no máximo 4 deployment slots por App Service. Para ter mais slots, é necessário migrar para o plano Premium.

C. O comando está usando o Azure CLI desatualizado. O parâmetro correto seria --deployment-slot em vez de --slot.

D. O recurso de deployment slots não está disponível no plano Standard; é necessário migrar para o plano Premium para habilitá-los.

Questão 5 — Verdadeiro ou Falso​

Ao executar um swap entre dois slots do App Service, o Azure realiza automaticamente uma fase de aquecimento (warm-up) no slot de destino antes de redirecionar o tráfego, desde que o aplicativo responda com HTTP 200 na rota de inicialização configurada em Health Check.

Verdadeiro ou Falso?

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

As configurações de slot (application settings ou connection strings marcadas como "deployment slot setting") são vinculadas ao slot, não ao conteúdo da aplicação. Durante um swap, o conteúdo e as configurações não marcadas como slot settings migram entre os slots, mas as slot settings permanecem fixas onde estão.

Esse comportamento é proposital: permite que cada ambiente (ex.: staging, production) mantenha suas próprias strings de conexão ou variáveis de ambiente específicas, independentemente de quantos swaps ocorram.

O principal equívoco dos distratores é tratar todas as configurações como se fossem equivalentes, sem considerar a distinção entre configurações vinculadas ao slot e configurações que seguem o código.

Gabarito — Questão 2​

Resposta: C

O Swap with Preview é a funcionalidade que permite realizar o swap em duas fases. Na primeira fase, as configurações do slot de destino (production) são aplicadas ao slot de origem (staging), mas o tráfego de usuários finais ainda não é redirecionado. Isso permite que o aplicativo aqueça com as configurações reais de production antes da conclusão do swap.

  • Always On (A) mantém o processo ativo, mas não controla o fluxo de tráfego durante o swap.
  • Auto Swap (B) automatiza o swap imediatamente após um deploy, sem fase de preview.
  • Health Check (D) monitora a saúde da instância, mas não bloqueia o roteamento de tráfego durante a fase de aquecimento do swap por si só.

A consequência de não usar Swap with Preview é que requisições de usuários podem atingir uma instância ainda em inicialização, resultando em erros ou lentidão perceptível.

Gabarito — Questão 3​

Resposta: B

Após o swap:

ConfiguraçãoComportamentoResultado em production
APP_ENVNão é slot setting: acompanha o conteúdostaging (veio do slot staging)
DB_CONNÉ slot setting: fica fixo no slotconn-prod (permanece em production)

APP_ENV não está marcada como slot setting, portanto ela migra junto com o código da aplicação do staging para production. Já DB_CONN está marcada como slot setting, permanecendo vinculada ao slot production com seu valor original conn-prod.

O erro mais comum é assumir que todas as variáveis se comportam da mesma forma durante o swap. A distinção entre slot settings e configurações normais é o núcleo deste comportamento.

Gabarito — Questão 4​

Resposta: B

O plano Standard suporta até 5 slots no total por App Service (incluindo o slot de production), portanto o limite real são 4 slots adicionais. Se o time já possui 4 slots adicionais e tenta criar um quinto, a operação falha por limite de plano.

A solução correta é migrar para o plano Premium, que suporta até 20 slots por App Service.

  • A alternativa D está errada porque deployment slots estão disponíveis no plano Standard; o problema é o limite de quantidade, não a ausência do recurso.
  • As alternativas A e C representam equívocos técnicos sobre nomenclatura de CLI e nomes de slot, que não são a causa real do erro neste cenário.

Gabarito — Questão 5​

Resposta: Falso

O Azure realiza aquecimento automático durante o swap com base nas regras de inicialização da aplicação (como applicationInitialization no web.config ou nas configurações do App Service), e não com base na rota configurada no Health Check.

O Health Check é usado para monitorar a saúde contínua das instâncias e remover instâncias não saudáveis do balanceador de carga, mas não é o mecanismo que controla o aquecimento durante o swap. Confundir os dois é um erro conceitual comum, pois ambos envolvem verificações de HTTP, mas com propósitos e momentos de execução distintos.