Laboratório Técnico: Choose between manual and autoscale
Questões
Questão 1 — Múltipla Escolha
Uma equipe de engenharia precisa dimensionar um Azure Application Gateway v2 para suportar um sistema de e-commerce com picos de tráfego previsíveis durante campanhas sazonais. Fora desses períodos, o tráfego cai para níveis muito baixos. A equipe quer minimizar custos operacionais e evitar intervenção manual a cada campanha.
Qual configuração de escalonamento é mais adequada para esse cenário?
A) Manual scaling com uma contagem fixa de instâncias alta o suficiente para suportar o pico máximo previsto
B) Autoscale com um valor mínimo de instâncias baixo e um valor máximo compatível com o pico esperado
C) Manual scaling com ajuste programado via scripts de automação antes de cada campanha
D) Autoscale com valor mínimo igual ao valor máximo para garantir estabilidade durante os picos
Questão 2 — Cenário Técnico
Um arquiteto está revisando a configuração de um Azure Application Gateway v2 em produção. Ele observa que o gateway foi configurado com autoscale habilitado, mas a propriedade minCapacity está definida como 0.
{
"sku": {
"name": "Standard_v2",
"tier": "Standard_v2"
},
"autoscaleConfiguration": {
"minCapacity": 0,
"maxCapacity": 10
}
}
Durante um período de tráfego próximo a zero durante a madrugada, usuários relatam latência elevada nas primeiras requisições ao retomar o uso pela manhã. Qual é a causa mais provável desse comportamento?
A) O valor maxCapacity: 10 é insuficiente para absorver a retomada de tráfego
B) Com minCapacity: 0, o gateway pode escalar para zero instâncias e precisa de tempo para provisionar ao receber novas requisições
C) O SKU Standard_v2 não suporta autoscale com valor mínimo abaixo de 2
D) A configuração JSON está malformada e o autoscale não está sendo aplicado corretamente
Questão 3 — Verdadeiro ou Falso
O Azure Application Gateway v1 suporta autoscaling nativo da mesma forma que o v2, sendo a escolha do tier uma decisão puramente de custo, sem impacto na disponibilidade do recurso de escalonamento automático.
Questão 4 — Cenário Técnico
Uma empresa configura um Azure Application Gateway v2 com manual scaling definido como capacity: 2. Durante um teste de carga, o throughput máximo do gateway é atingido e requisições começam a ser descartadas. O engenheiro responsável aumenta a capacidade para 8 via portal, mas percebe que o ajuste leva vários minutos para ter efeito completo.
Qual conclusão técnica esse cenário ilustra sobre o uso de manual scaling em ambientes de carga variável?
A) Manual scaling é inadequado para qualquer ambiente de produção e deve sempre ser substituído por autoscale
B) O atraso no provisionamento de instâncias adicionais é esperado e representa um risco operacional em cargas imprevisíveis com escalonamento manual
C) O problema foi causado por escolha incorreta do SKU; a versão correta eliminaria o atraso de provisionamento
D) Aumentar a capacidade via portal aplica as instâncias imediatamente sem atraso, indicando outro problema na infraestrutura
Questão 5 — Múltipla Escolha
Ao configurar autoscale em um Azure Application Gateway v2, qual afirmação descreve corretamente a relação entre minCapacity, maxCapacity e o comportamento de cobrança?
A) O gateway cobra apenas pelas instâncias que estão efetivamente em uso no momento, independentemente do valor de minCapacity
B) O valor de minCapacity define o número mínimo de instâncias sempre provisionadas e cobradas, mesmo que o tráfego seja zero
C) Quando minCapacity é 0, não há cobrança por capacidade de instância em nenhum momento, incluindo durante o tráfego ativo
D) O maxCapacity determina o custo fixo mensal, independentemente do escalonamento real ocorrido
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
Configurar autoscale com minCapacity baixo e maxCapacity compatível com o pico sazonal é a abordagem correta para este cenário. O autoscale ajusta o número de instâncias dinamicamente com base na demanda real, reduzindo custos nos períodos de baixo tráfego e expandindo capacidade automaticamente durante as campanhas.
A alternativa A desperdiça recursos ao manter instâncias ociosas fora dos picos. A alternativa C adiciona complexidade operacional e risco de falha humana ou de agendamento. A alternativa D equivale funcionalmente ao manual scaling, pois fixar min igual a max elimina o benefício do escalonamento dinâmico.
Gabarito — Questão 2
Resposta: B
Quando minCapacity é definido como 0, o Application Gateway v2 pode reduzir o número de instâncias ativas a zero durante períodos de tráfego inexpressivo. Ao retomar o uso, há um tempo de cold start para provisionar instâncias, o que explica a latência elevada nas primeiras requisições da manhã.
A alternativa A é incorreta porque maxCapacity: 10 é suficiente para a maioria dos cenários. A alternativa C é falsa: o SKU Standard_v2 suporta minCapacity: 0 sem restrição de SKU. A alternativa D é incorreta; o JSON está bem formado e a configuração é válida.
O ponto central é entender que minCapacity: 0 é uma decisão de custo versus disponibilidade imediata, e não um erro de configuração.
Gabarito — Questão 3
Resposta: Falso
O Application Gateway v1 não suporta autoscaling nativo. O escalonamento automático é uma funcionalidade exclusiva do tier v2. No v1, o dimensionamento é estritamente manual, exigindo que o operador defina e ajuste a contagem de instâncias explicitamente.
Portanto, a escolha entre v1 e v2 não é apenas uma decisão de custo: ela determina se o recurso de autoscale está disponível ou não. Ambientes que exigem escalonamento automático devem obrigatoriamente usar o tier v2.
Gabarito — Questão 4
Resposta: B
O cenário ilustra um risco inerente ao manual scaling: o provisionamento de novas instâncias não é instantâneo. Quando a capacidade é aumentada manualmente em resposta a uma sobrecarga já em andamento, existe uma janela de tempo durante a qual o gateway opera além da sua capacidade configurada, resultando em descarte de requisições ou degradação de serviço.
A alternativa A é uma generalização incorreta: manual scaling tem casos de uso legítimos em ambientes com carga estável e previsível. A alternativa C está errada pois o atraso de provisionamento é comportamento esperado, não um defeito de SKU. A alternativa D está factualmente incorreta: aumentar instâncias via portal, API ou CLI envolve tempo de provisionamento.
Gabarito — Questão 5
Resposta: B
O minCapacity define um piso de capacidade sempre provisionado, e as instâncias correspondentes são cobradas continuamente, mesmo sem tráfego ativo. Isso ocorre porque o Application Gateway mantém essas instâncias em estado pronto para garantir disponibilidade imediata.
A alternativa A é incorreta: o modelo de cobrança inclui as instâncias do minCapacity independentemente do tráfego. A alternativa C é incorreta: mesmo com minCapacity: 0, quando o gateway está processando tráfego as instâncias provisionadas são cobradas. A alternativa D é incorreta: o maxCapacity é um limite operacional, não uma base de cobrança fixa.
Compreender esse modelo é essencial para estimar custos e justificar a escolha entre minCapacity: 0 (menor custo, possível cold start) e minCapacity >= 1 (custo fixo mínimo, disponibilidade imediata garantida).