Quiz de Validação - MÓDULO 9
Este quiz de 30 perguntas permite validar seus conhecimentos sobre Auto Scaling antes de passar para o laboratório prático.
Pergunta 1
O que é um Auto Scaling Group (ASG)?
A) Um grupo de Security Groups
B) Uma coleção de instâncias EC2 gerenciadas automaticamente conforme regras de scaling
C) Um grupo de usuários
D) Um tipo de Load Balancer
Ver resposta
Resposta: B
Um Auto Scaling Group é um conjunto lógico de instâncias EC2 tratadas como um grupo para scaling automático. O ASG mantém o número desejado de instâncias, substitui instâncias unhealthy e faz scaling conforme as políticas definidas.
Pergunta 2
Quais são os três parâmetros de capacidade de um ASG?
A) Small, Medium, Large
B) Minimum, Desired, Maximum
C) Low, Normal, High
D) Start, Running, Stop
Ver resposta
Resposta: B
Minimum: número mínimo de instâncias (nunca abaixo). Desired: número alvo de instâncias (o ASG tenta manter esse número). Maximum: limite superior (nunca acima). Relação: Minimum é menor ou igual a Desired, que é menor ou igual a Maximum.
Pergunta 3
O que é um Launch Template?
A) Um modelo de documento
B) Uma configuração que descreve como lançar instâncias EC2 (AMI, tipo, SG, etc.)
C) Um plano de deploy
D) Um script de inicialização
Ver resposta
Resposta: B
O Launch Template define todos os parâmetros para lançar uma instância: AMI, tipo de instância, key pair, Security Groups, user data, volumes EBS, etc. O ASG usa esse template para criar instâncias idênticas. Substitui o antigo Launch Configuration.
Pergunta 4
Qual a diferença entre Launch Template e Launch Configuration?
A) Nenhuma
B) Launch Template suporta versionamento e mais funcionalidades, Launch Configuration está depreciado
C) Launch Configuration é mais recente
D) Launch Template é pago
Ver resposta
Resposta: B
Launch Template é o método recomendado. Suporta: versionamento, mix de tipos de instância, mix On-Demand/Spot, T2/T3 unlimited. Launch Configuration é o método antigo, imutável e com menos funcionalidades. Migre para Launch Template.
Pergunta 5
O que acontece se uma instância de um ASG falhar no health check?
A) Nada
B) O ASG termina e lança uma nova automaticamente
C) Um e-mail é enviado
D) O ASG para
Ver resposta
Resposta: B
O ASG detecta instâncias unhealthy (via EC2 status checks ou ELB health checks) e as substitui automaticamente. Essa é a funcionalidade de self-healing que mantém o número desejado de instâncias saudáveis.
Pergunta 6
Quais tipos de health checks um ASG pode usar?
A) Somente EC2
B) EC2 e/ou ELB
C) Somente ELB
D) Somente CloudWatch
Ver resposta
Resposta: B
EC2 health check: verifica os status checks EC2 (instância rodando, sistema OK). ELB health check: verifica se a instância responde aos health checks do Load Balancer. Se integrado a um LB, use ELB health check para uma detecção mais precisa.
Pergunta 7
O que é a scaling policy "Target Tracking"?
A) Seguir um alvo específico
B) Ajustar a capacidade para manter uma métrica em um valor alvo
C) Rastrear os usuários
D) Atingir um objetivo de custo
Ver resposta
Resposta: B
Target Tracking ajusta automaticamente a capacidade para manter uma métrica do CloudWatch em um valor alvo. Exemplo: manter CPUUtilization em 50%. O ASG faz scale out se CPU > 50%, scale in se CPU < 50%. Simples e eficaz.
Pergunta 8
Quais métricas podem ser usadas com Target Tracking?
A) Apenas CPU
B) CPU, Network, ALB Request Count por alvo, métricas personalizadas
C) Somente métricas de rede
D) Apenas métricas de custo
Ver resposta
Resposta: B
Métricas predefinidas: ASGAverageCPUUtilization, ASGAverageNetworkIn/Out, ALBRequestCountPerTarget. Também é possível usar métricas personalizadas do CloudWatch (ex: queue depth, métricas customizadas de aplicação).
Pergunta 9
O que é a scaling policy "Step Scaling"?
A) Scaling etapa por etapa
B) Ações diferentes conforme a amplitude do excesso de threshold
C) Scaling manual
D) Scaling linear
Ver resposta
Resposta: B
Step Scaling define ações diferentes conforme a amplitude do alarme. Exemplo: +1 instância se CPU 60-70%, +2 se CPU 70-80%, +4 se CPU > 80%. Permite uma resposta proporcional à intensidade da carga.
Pergunta 10
O que é a scaling policy "Simple Scaling"?
A) A mais simples das políticas
B) Aguarda o fim de uma ação de scaling antes de disparar outra
C) Scaling constante
D) Sem scaling
Ver resposta
Resposta: B
Simple Scaling dispara uma ação quando um alarme entra em ALARM, mas aguarda um cooldown antes de reagir novamente. Menos reativa que Step ou Target Tracking. Geralmente substituída pelas outras políticas.
Pergunta 11
O que é o "Cooldown Period"?
A) Período de resfriamento dos servidores
B) Tempo de espera após uma ação de scaling antes de permitir outra
C) Tempo de manutenção
D) Delay de faturamento
Ver resposta
Resposta: B
O cooldown (padrão 300s) impede que o ASG lance/termine muitas instâncias rapidamente. Após um scale out/in, o ASG espera antes de reagir novamente, permitindo que as novas instâncias iniciem e as métricas se estabilizem.
Pergunta 12
O que é o "Scheduled Scaling"?
A) Scaling baseado em um calendário predefinido
B) Scaling aleatório
C) Scaling baseado em custos
D) Scaling baseado em geografia
Ver resposta
Resposta: A
Scheduled Scaling permite definir ações de scaling em horários específicos. Exemplo: aumentar para 10 instâncias todos os dias às 8h, reduzir para 2 à noite. Útil para padrões de carga previsíveis.
Pergunta 13
Quando usar Scheduled Scaling vs Target Tracking?
A) Scheduled para carga imprevisível, Target Tracking para carga previsível
B) Scheduled para padrões previsíveis, Target Tracking para carga variável
C) São idênticos
D) Nunca usar os dois juntos
Ver resposta
Resposta: B
Scheduled Scaling para padrões previsíveis (horário comercial, eventos planejados). Target Tracking para reagir à carga real variável. Pode-se combinar os dois: scheduled para o baseline, target tracking para ajustes finos.
Pergunta 14
O que é o "Predictive Scaling"?
A) Previsões meteorológicas
B) Machine learning para antecipar a demanda e pré-escalar
C) Previsões de custos
D) Scaling baseado em previsões de usuários
Ver resposta
Resposta: B
Predictive Scaling usa machine learning para analisar padrões históricos e antecipar a demanda futura. O ASG faz scaling proativamente antes do aumento de carga. Combine com outras políticas para cobertura completa.
Pergunta 15
Como um ASG distribui as instâncias entre as AZ?
A) Todas em uma única AZ
B) Equilíbrio entre as AZ configuradas para alta disponibilidade
C) Aleatoriamente
D) Conforme o custo
Ver resposta
Resposta: B
O ASG distribui as instâncias de forma equilibrada entre as AZ configuradas. Se você tem 4 instâncias e 2 AZ, coloca 2 em cada. Isso garante alta disponibilidade: se uma AZ falhar, a outra tem instâncias.
Pergunta 16
O que acontece se uma AZ se tornar indisponível?
A) O ASG para
B) O ASG lança instâncias adicionais nas AZ restantes
C) Nada
D) As instâncias migram automaticamente
Ver resposta
Resposta: B
O ASG detecta que as instâncias da AZ com falha estão unhealthy e as termina. Em seguida, lança instâncias de substituição nas AZ disponíveis para manter o desired capacity. Isso é o rebalancing automático.
Pergunta 17
O que é o "Instance Warmup"?
A) Aquecimento dos servidores
B) Tempo concedido para uma nova instância se inicializar antes de contar nas métricas
C) Tempo de boot do SO
D) Delay de faturamento
Ver resposta
Resposta: B
O Instance Warmup dá tempo para uma nova instância iniciar sua aplicação e se estabilizar. Durante esse tempo, ela não contribui para as métricas de scaling, evitando scale out em cascata baseado em métricas temporariamente elevadas.
Pergunta 18
O que é o "Lifecycle Hook"?
A) Um gancho físico
B) Um ponto de parada durante o lançamento/terminação para executar ações personalizadas
C) Um log
D) Um webhook HTTP
Ver resposta
Resposta: B
Os Lifecycle Hooks permitem executar ações durante o lançamento (ex: instalar softwares, registrar em um serviço) ou terminação (ex: desregistrar, salvar dados) de uma instância antes que ela entre/saia do grupo.
Pergunta 19
O que é a "Termination Policy"?
A) Política de exclusão de conta
B) Regras para escolher quais instâncias terminar durante um scale in
C) Termos de uso
D) Política de retenção de logs
Ver resposta
Resposta: B
A Termination Policy define como o ASG escolhe as instâncias a serem terminadas durante um scale in. Opções: OldestInstance, NewestInstance, OldestLaunchConfiguration, ClosestToNextInstanceHour, Default (equilíbrio entre AZ e depois mais antiga).
Pergunta 20
O que é "Instance Protection"?
A) Antivirus
B) Impede que uma instância específica seja terminada pelo scaling
C) Criptografia
D) Firewall
Ver resposta
Resposta: B
Instance Protection protege uma instância contra terminação por ações de scale in do ASG. Útil para instâncias que executam tarefas longas. A instância ainda pode ser terminada manualmente ou se ficar unhealthy.
Pergunta 21
É possível misturar instâncias On-Demand e Spot em um ASG?
A) Não
B) Sim, com uma política de mix no Launch Template ou ASG
C) Somente com um Launch Configuration
D) Somente para instâncias grandes
Ver resposta
Resposta: B
O ASG suporta um mix de instâncias On-Demand e Spot. É possível definir uma porcentagem (ex: 70% Spot, 30% On-Demand base). Isso reduz custos mantendo uma capacidade base garantida.
Pergunta 22
O que são instâncias Spot?
A) Instâncias especiais
B) Instâncias que usam a capacidade ociosa da AWS a preço reduzido, mas podem ser interrompidas
C) Instâncias gratuitas
D) Instâncias apenas para desenvolvimento
Ver resposta
Resposta: B
As instâncias Spot usam a capacidade EC2 excedente a preço reduzido (até 90% mais barato). Podem ser interrompidas pela AWS com aviso prévio de 2 minutos quando a AWS precisa da capacidade. Ideais para workloads tolerantes a interrupções.
Pergunta 23
Como se proteger contra interrupções Spot?
A) Não é possível
B) Diversificar tipos de instância e AZ, usar mix On-Demand/Spot
C) Pagar mais
D) Usar Reserved Instances
Ver resposta
Resposta: B
Para resiliência Spot: diversifique tipos de instância (várias famílias/tamanhos), use múltiplas AZ, configure uma porcentagem base On-Demand, implemente gestão de interrupções (notificação de 2 min) e projete aplicações tolerantes a falhas.
Pergunta 24
Qual alarme CloudWatch normalmente dispara um scale out?
A) CPU < 20%
B) CPU > 70% por 5 minutos
C) Nenhum alarme necessário
D) Alarme de faturamento
Ver resposta
Resposta: B
Um alarme típico de scale out monitora CPUUtilization > 70% (threshold configurável) por vários períodos (ex: 3 períodos de 1 minuto). Quando o alarme entra em ALARM, a ação de scaling adiciona instâncias.
Pergunta 25
O que é o "Desired Capacity"?
A) A capacidade desejada pela AWS
B) O número de instâncias que o ASG tenta manter
C) A capacidade máxima do servidor
D) O número de usuários desejados
Ver resposta
Resposta: B
Desired Capacity é o número de instâncias que o ASG mantém ativamente. Se uma instância falhar, o ASG lança outra para voltar ao desired. As políticas de scaling modificam o desired capacity dentro dos limites min/max.
Pergunta 26
É possível modificar manualmente o Desired Capacity?
A) Não, apenas o auto scaling pode modificar
B) Sim, via console, CLI ou API
C) Apenas via API
D) Apenas se o auto scaling estiver desativado
Ver resposta
Resposta: B
É possível modificar manualmente o Desired Capacity a qualquer momento via console, CLI (aws autoscaling set-desired-capacity) ou API. O ASG ajustará então o número de instâncias. As políticas de scaling ajustarão depois, se necessário.
Pergunta 27
Como monitorar as atividades de scaling?
A) Apenas CloudWatch
B) CloudWatch, Activity History do ASG, notificações SNS
C) Apenas logs EC2
D) Apenas AWS Config
Ver resposta
Resposta: B
Monitore: Activity History no ASG (histórico de ações), métricas CloudWatch (GroupDesiredCapacity, GroupInServiceInstances, etc.), CloudTrail para chamadas API e configure notificações SNS para eventos de scaling.
Pergunta 28
O que é "Suspend Processes" em um ASG?
A) Pausar as instâncias
B) Desativar temporariamente certos processos do ASG (Launch, Terminate, etc.)
C) Suspender faturamento
D) Parar o monitoring
Ver resposta
Resposta: B
É possível suspender processos do ASG: Launch (não lança novas instâncias), Terminate (não termina), HealthCheck (não verifica), ReplaceUnhealthy, AZRebalance, etc. Útil para manutenção ou debugging.
Pergunta 29
Qual métrica indica que um ASG está escalando?
A) CPUUtilization
B) GroupDesiredCapacity, GroupInServiceInstances, GroupTotalInstances
C) NetworkIn
D) DiskReadOps
Ver resposta
Resposta: B
As métricas do ASG incluem: GroupDesiredCapacity (capacidade alvo), GroupInServiceInstances (instâncias saudáveis), GroupPendingInstances (em lançamento), GroupTerminatingInstances (em terminação). Essas métricas mostram a atividade de scaling.
Pergunta 30
Como testar uma política de scaling?
A) Esperar uma carga real
B) Gerar carga artificial (stress test) ou modificar manualmente as métricas
C) Ler a documentação
D) Não é possível
Ver resposta
Resposta: B
Teste gerando carga artificial (stress, ab, locust) para disparar os alarmes. Ou use ferramentas como stress nas instâncias para aumentar o CPU. Verifique se o ASG escala como esperado e se as instâncias ficam healthy.
Resultado
Conte suas respostas corretas:
- 27-30: Excelente - Você domina Auto Scaling
- 22-26: Bom - Alguns pontos para revisar
- 17-21: Médio - Releia o curso antes do lab
- Menos de 17: Insuficiente - Refaça o curso desde o início
Passe para o Lab Auto Scaling assim que atingir pelo menos 22 respostas corretas.