Laboratório Técnico: Configure scaling for an App Service plan
Questões
Questão 1 — Múltipla Escolha
Uma equipe de desenvolvimento hospeda uma aplicação no Azure App Service com um plano Standard S2. O tráfego da aplicação é previsível: alta demanda de segunda a sexta entre 08h e 18h, e demanda mínima nos demais períodos. O time deseja reduzir custos sem comprometer a disponibilidade.
Qual abordagem de escalabilidade é mais adequada para esse cenário?
A) Configurar scale out manual, ajustando o número de instâncias manualmente toda manhã e toda noite.
B) Configurar autoscale com regras baseadas em agendamento, aumentando instâncias no horário de pico e reduzindo fora dele.
C) Migrar para um plano Premium P1v3 e configurar regras de autoscale baseadas em métricas de CPU.
D) Habilitar scale up para um plano S3 durante o horário de pico e retornar ao S2 fora dele via script.
Questão 2 — Cenário Técnico
Um administrador configurou a seguinte regra de autoscale em um App Service plan:
Métrica: CPU Percentage
Operador: Greater than
Threshold: 70%
Duration: 5 minutes
Action: Increase count by 1
Cool down: 5 minutes
Durante um pico de carga, os logs mostram que a CPU permaneceu acima de 70% por 20 minutos, mas o número de instâncias aumentou apenas uma vez, de 2 para 3, e não escalou mais. O plano está configurado com máximo de 3 instâncias.
Qual é a causa do comportamento observado?
A) O período de cool down de 5 minutos bloqueou todas as novas avaliações após o primeiro scale out.
B) A regra está configurada para aumentar apenas uma instância por evento, e o limite máximo de instâncias definido no perfil de autoscale já foi atingido.
C) O autoscale só executa uma ação por ciclo de 5 minutos de avaliação, independentemente do limite máximo.
D) A duração de 5 minutos da métrica é insuficiente para detectar picos prolongados, causando supressão das ações subsequentes.
Questão 3 — Verdadeiro ou Falso
Um App Service plan no nível Free (F1) suporta a configuração de regras de autoscale baseadas em métricas, desde que o número máximo de instâncias seja definido como 1.
Questão 4 — Cenário Técnico
Uma aplicação web em produção apresenta lentidão durante eventos sazonais de alto tráfego. A equipe decide configurar autoscale, mas após a implantação, observa que as instâncias escalam horizontalmente com atraso, e a aplicação já degradou antes de as novas instâncias ficarem prontas.
O arquiteto suspeita que o problema está na configuração do gatilho de escalonamento. Veja o perfil atual:
Métrica: CPU Percentage
Threshold: 85%
Duration: 10 minutes
Action: Increase count by 1
Qual ajuste resolve o problema de forma mais direta?
A) Reduzir o threshold de CPU para um valor mais baixo, como 60%, para que o gatilho seja acionado antes da saturação.
B) Aumentar o número de instâncias mínimas no perfil de autoscale para reduzir a dependência do escalonamento reativo.
C) Substituir a métrica de CPU por Http Queue Length para detectar sobrecarga antes que a CPU sature.
D) Reduzir a duration de 10 para 1 minuto para que o gatilho reaja mais rapidamente a picos de curta duração.
Questão 5 — Múltipla Escolha
Ao configurar um perfil de autoscale no Azure App Service, um administrador define simultaneamente um perfil recorrente para fins de semana e um perfil padrão com regras baseadas em métricas.
Como o Azure determina qual perfil aplicar em um dado momento?
A) O perfil com o maior número de instâncias máximas configuradas sempre tem precedência sobre os demais.
B) O perfil padrão é sempre aplicado como base; os perfis recorrentes e de data fixa sobrepõem o padrão quando suas condições são atendidas.
C) Os dois perfis são avaliados simultaneamente, e o Azure aplica a média das instâncias definidas em cada um.
D) O perfil mais recentemente criado tem precedência sobre os anteriores, independentemente do tipo.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O autoscale com regras baseadas em agendamento é a solução ideal quando o padrão de carga é conhecido e previsível. Ele permite definir instâncias mínimas e máximas para janelas de tempo específicas, garantindo capacidade antes do pico e redução de custo fora dele, sem intervenção manual.
O principal erro dos distratores está em confundir tipos de escalonamento:
- A alternativa A descreve um processo manual, que é operacionalmente inviável e propenso a falha humana.
- A alternativa C sugere scale up (mudança de tier) combinado com autoscale por métrica, o que seria uma resposta reativa e desnecessariamente cara para um padrão previsível.
- A alternativa D tenta usar scale up como substituto de scale out, ignorando que trocar de tier não é uma operação de autoscale e envolve reinicialização do plano.
Gabarito — Questão 2
Resposta: B
O comportamento é exatamente o esperado: o autoscale aumentou de 2 para 3 instâncias e parou porque o limite máximo definido no perfil é 3. O mecanismo de autoscale nunca ultrapassa os limites configurados no perfil, independentemente da carga.
O distrator A representa um equívoco comum: o cool down controla o intervalo mínimo entre ações consecutivas, mas não impede avaliações. Após o cool down de 5 minutos, o autoscale avaliaria novamente e tentaria escalar, mas o limite máximo já havia sido atingido.
A distinção importante é que cool down e limite máximo de instâncias são controles independentes, e o limite máximo é absoluto e inviolável pela regra de escalonamento.
Gabarito — Questão 3
Resposta: Falso
O App Service plan no nível Free (F1) e também no nível Shared (D1) não suportam autoscale. A funcionalidade de autoscale está disponível apenas a partir dos planos Basic (B1 e superiores), e escalonamento horizontal automático exige planos Standard ou superiores.
O enunciado apresenta uma condição que parece razoável (limitar a 1 instância), mas a restrição não é sobre o número de instâncias: é sobre o tier do plano em si. Compreender esse limite evita tentativas de configuração que o portal simplesmente não permitirá.
Gabarito — Questão 4
Resposta: A
Reduzir o threshold de CPU para um valor como 60% faz com que o gatilho seja acionado mais cedo, antes que a aplicação já esteja saturada. Isso dá tempo para que as novas instâncias sejam provisionadas e aquecidas antes da degradação visível ao usuário.
A alternativa B também é válida como prática complementar (aumentar o mínimo de instâncias reduz a dependência do escalonamento reativo), mas não resolve o problema de timing do gatilho, que é o ponto central do cenário.
A alternativa D é tecnicamente perigosa: uma duration de 1 minuto torna o autoscale hipersensível a picos transitórios, causando flapping (escalonamento e desescalonamento em ciclos rápidos), o que aumenta custos e pode instabilizar a aplicação.
A alternativa C poderia ser útil em cenários específicos, mas Http Queue Length é uma métrica secundária e não necessariamente o melhor indicador para o problema descrito.
Gabarito — Questão 5
Resposta: B
O Azure Autoscale aplica os perfis em uma hierarquia de precedência definida: perfis de data fixa têm prioridade máxima, seguidos por perfis recorrentes, e por último o perfil padrão, que atua como fallback quando nenhum outro perfil está ativo.
O perfil padrão nunca compete com os outros: ele é simplesmente substituído quando um perfil mais específico está vigente. Isso significa que as regras de métricas definidas no perfil padrão não serão avaliadas durante um fim de semana coberto por um perfil recorrente, a menos que o perfil recorrente também contenha suas próprias regras.
Os distratores A, C e D descrevem comportamentos inexistentes no Azure. Não há agregação de médias entre perfis, nem precedência por data de criação ou por tamanho de instância.