Laboratório Técnico: Deploy and configure an Azure Virtual Machine Scale Sets
Questões
Questão 1 — Múltipla Escolha
Uma equipe de operações precisa garantir que um Azure Virtual Machine Scale Set (VMSS) mantenha sempre entre 3 e 10 instâncias, com escalonamento automático baseado em CPU. O engenheiro configura uma regra de scale-out quando a CPU média ultrapassar 75% por 5 minutos, e uma regra de scale-in quando cair abaixo de 30% por 10 minutos.
Após uma semana, a equipe observa que o número de instâncias oscila repetidamente entre 4 e 5, mesmo sem variação real de carga. Qual característica do autoscaling é a causa mais provável desse comportamento?
A) O intervalo de coleta de métricas está configurado com granularidade muito alta, causando leituras imprecisas.
B) O cooldown period está muito curto, permitindo que novas ações de escalonamento ocorram antes que o sistema estabilize após o ajuste anterior.
C) O valor mínimo de instâncias está impedindo que o scale-in reduza abaixo de 3, causando conflito com a regra de scale-out.
D) O VMSS está usando o modo de orquestração Uniform, que não suporta regras de scale-in personalizadas.
Questão 2 — Cenário Técnico
Um administrador implanta um VMSS com a seguinte configuração parcial:
"upgradePolicy": {
"mode": "Rolling",
"rollingUpgradePolicy": {
"maxBatchInstancePercent": 20,
"maxUnhealthyInstancePercent": 20,
"maxUnhealthyUpgradedInstancePercent": 5,
"pauseTimeBetweenBatches": "PT0S"
}
},
"automaticRepairsPolicy": {
"enabled": true,
"gracePeriod": "PT10M"
}
Após atualizar a imagem base do VMSS, 3 de 10 instâncias ficam em estado Unhealthy imediatamente após o upgrade do primeiro lote. O processo de upgrade para completamente.
Qual é a causa direta da interrupção?
A) O gracePeriod de 10 minutos bloqueou a verificação de saúde das instâncias do primeiro lote antes que o próximo pudesse iniciar.
B) O valor de maxUnhealthyUpgradedInstancePercent foi excedido, pois 3 instâncias com falha representam 30% do total, acima do limite de 5%.
C) O pauseTimeBetweenBatches configurado como PT0S não permite tempo suficiente para que as instâncias reportem saúde antes do próximo lote.
D) O modo Rolling requer que o Application Health Extension esteja instalado; sem ele, todas as instâncias são marcadas como unhealthy por padrão.
Questão 3 — Verdadeiro ou Falso
Em um Azure Virtual Machine Scale Set configurado com modo de orquestração Flexible, é possível adicionar manualmente VMs individuais existentes ao scale set após a sua criação, da mesma forma que se associa uma VM a um Availability Set.
Questão 4 — Cenário Técnico
Uma aplicação crítica é executada em um VMSS com 6 instâncias distribuídas em 3 fault domains e 5 update domains. O time de infraestrutura precisa aplicar uma atualização de sistema operacional com o mínimo de impacto simultâneo possível, garantindo que instâncias em diferentes fault domains sejam atualizadas em momentos distintos.
O administrador considera as seguintes abordagens:
A) Configurar o upgradePolicy.mode como Automatic e ajustar maxBatchInstancePercent para 20%, garantindo que no máximo 1 instância seja atualizada por vez.
B) Configurar o upgradePolicy.mode como Manual e executar Update-AzVmssInstance para cada instância individualmente, controlando a ordem manualmente.
C) Configurar o upgradePolicy.mode como Rolling com maxBatchInstancePercent de 20% e habilitar o Application Health Extension para validar cada lote antes de prosseguir.
D) Migrar o VMSS para o modo de orquestração Uniform e usar Scheduled Events para coordenar as atualizações entre fault domains.
Qual abordagem atende melhor ao requisito de minimizar impacto simultâneo com validação automática de saúde entre lotes?
Questão 5 — Múltipla Escolha
Um VMSS usa Custom Script Extension para configurar a aplicação durante o provisionamento. Ao escalar horizontalmente, as novas instâncias demoram muito mais do que o esperado para ficarem prontas. A análise mostra que cada nova instância baixa e executa o script de 800 MB a partir de um endpoint externo na internet.
Qual mudança na arquitetura do VMSS eliminaria esse gargalo de forma mais direta?
A) Substituir a Custom Script Extension por cloud-init, que executa scripts localmente sem dependência de download externo.
B) Referenciar o script a partir de um Azure Storage Account com endpoint privado na mesma região do VMSS, reduzindo a latência de download.
C) Incorporar a configuração da aplicação diretamente na imagem base customizada usada pelo VMSS, eliminando a necessidade de execução de script no provisionamento.
D) Aumentar o instanceFlexibility do VMSS para que novas instâncias sejam provisionadas com SKUs de rede mais rápidas durante o scale-out.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O comportamento de "flapping" (oscilação repetida entre valores próximos) é uma consequência clássica de um cooldown period insuficiente. Após uma ação de escalonamento, o sistema precisa de tempo para que as novas instâncias comecem a absorver carga e as métricas se estabilizem. Se o cooldown for muito curto, o autoscaler lê métricas transitórias do período de ajuste e dispara uma nova ação em sentido contrário, criando um ciclo.
O erro principal que os distratores representam é confundir o problema com limitações de configuração de limites mínimos/máximos (C) ou restrições de modo de orquestração (D), quando o problema é temporal, não estrutural. A alternativa A é plausível mas descreve um problema de precisão de dados, não de estabilidade de decisão.
Escolher D seria particularmente problemático: o modo Uniform suporta plenamente regras de scale-in, e acreditar no contrário levaria o administrador a migrar o VMSS desnecessariamente.
Gabarito — Questão 2
Resposta: B
O parâmetro maxUnhealthyUpgradedInstancePercent define o percentual máximo de instâncias já atualizadas que podem estar unhealthy para que o processo continue. Com 10 instâncias e maxBatchInstancePercent de 20%, o primeiro lote contém 2 instâncias. Porém, o enunciado indica que 3 instâncias ficaram unhealthy, o que representa 30% do total atualizado até aquele momento, excedendo o limite de 5% e interrompendo o rolling upgrade.
O erro conceitual mais comum é confundir maxUnhealthyInstancePercent (limite sobre o total do scale set) com maxUnhealthyUpgradedInstancePercent (limite apenas sobre as instâncias que já passaram pelo upgrade). A alternativa A é um distrator sofisticado: o gracePeriod do Automatic Repairs é o tempo que o sistema aguarda antes de reparar uma instância unhealthy, e não interfere diretamente na progressão do rolling upgrade. A alternativa D seria verdadeira se a extensão de saúde não estivesse instalada, mas o cenário não indica sua ausência.
Gabarito — Questão 3
Resposta: Falso
O modo Flexible do VMSS permite que VMs individuais sejam criadas e associadas ao scale set no momento da criação da VM, especificando o virtualMachineScaleSet como referência. No entanto, não é possível adicionar VMs existentes e independentes a um VMSS após sua criação, ao contrário do que ocorre com Availability Sets, onde uma VM pode ser associada em momentos distintos do ciclo de vida.
Essa distinção é crítica: o VMSS Flexible oferece flexibilidade de gerenciamento individual de instâncias, mas o modelo de associação é definido no provisionamento da VM, não retroativamente. Confundir os dois modelos pode levar a decisões de arquitetura incorretas ao planejar a migração de workloads existentes para scale sets.
Gabarito — Questão 4
Resposta: C
O modo Rolling com maxBatchInstancePercent baixo (20% = aproximadamente 1 instância por lote em um conjunto de 6) combinado com o Application Health Extension é a abordagem que atende aos dois requisitos: minimiza impacto simultâneo e valida automaticamente a saúde de cada lote antes de prosseguir para o próximo.
A alternativa B (Manual) oferece controle total, mas não garante validação automática de saúde entre lotes, exigindo intervenção humana em cada etapa, o que aumenta o risco operacional. A alternativa A (Automatic) com batch pequeno reduz o impacto simultâneo, mas o modo Automatic não pausa para validação de saúde entre lotes da mesma forma que o Rolling com health extension. A alternativa D propõe uma mudança de modo de orquestração que não resolve o problema central e adiciona complexidade desnecessária.
Gabarito — Questão 5
Resposta: C
Incorporar a configuração diretamente na imagem base customizada (via Packer, Azure Image Builder ou similar) elimina completamente a necessidade de download e execução de scripts no momento do provisionamento. Isso reduz o tempo de inicialização da instância ao tempo de boot da VM mais o tempo de inicialização da aplicação, sem dependências externas.
A alternativa B reduz a latência mas não elimina o gargalo: 800 MB ainda precisam ser baixados e executados a cada nova instância. A alternativa A é um erro conceitual relevante: o cloud-init também pode depender de scripts externos e não executa "localmente sem download" por definição; o problema é a origem e o tamanho do artefato, não a ferramenta de provisionamento. A alternativa D referencia instanceFlexibility, que não é um parâmetro real do VMSS para controle de SKU de rede durante scale-out.