Minha certificação AWS Cloud Practitioner estava chegando na renovação. Em vez de marcar a prova, passei três noites como um boneco de desenho animado em uma cidade de desenho animado.
Isso é o AWS Cloud Quest: Recertify Cloud Practitioner. Você ganha um avatar, uma cidade low-poly com a infraestrutura discretamente quebrada e onze assignments que colocam você num console AWS de verdade com um problema de verdade — computação, rede, storage, bancos de dados, segurança, custo. Termine todos e o relógio de três anos reinicia. Sem centro de provas, sem fiscal me observando não piscar.
Eu esperava me entediar. Trabalho projetando arquitetura de IA e workflows agênticos; no último ano escrevi muito mais specs sobre VPCs do que construí. O que recebi em troca foi uma auditoria desconfortável da distância entre explicar infraestrutura e fazer infraestrutura.
O formato é melhor do que parece
Todo assignment começa igual: um Solution Request em linguagem de negócio, uma lista de objetivos do laboratório guiado e, no fim, um objetivo DIY que você tem que resolver sozinha.
A metade guiada é guiada mesmo — clique aqui, depois aqui. A metade DIY não é. "Mude as regras do security group para permitir tráfego na porta 3306 para o DB server" chega sem nenhum passo. Essa estrutura em dois níveis é o design inteiro: ensinar o movimento, tirar as rodinhas e conferir se sobrou alguma coisa.
Onde ele me pegou
Connecting VPCs. O laboratório conduz você por uma conexão de peering, Marketing para Finance. O objetivo DIY então pede uma segunda, Developer para Finance.
Eu sabia que peering de VPC não é transitivo, do jeito que a gente sabe as coisas que leu. Saber disso e ter que sentar e adicionar a segunda entrada na route table com a própria mão são experiências diferentes, e só uma delas gruda.
Mesma história com Highly Available Web Applications: apontar um Auto Scaling group para um Application Load Balancer, configurar os health checks, adicionar uma segunda Availability Zone. Aí o objetivo DIY quer uma terceira.
Nada disso é difícil. Não é esse o ponto. O ponto é que eu não fazia isso na mão havia muito tempo, porque há dois anos meu instinto numa tarefa dessas é descrever e revisar o que volta.
O que pareceu trabalho de verdade
O último assignment é um challenge lab: Modernize a Cloud Architecture. Seis tarefas, nenhum passo a passo. Habilitar Multi-AZ no banco RDS. Liberar MySQL a partir da camada de aplicação. Criar uma tabela DynamoDB para log de atividade. Aceitar uma conexão de peering de VPC e ajustar o roteamento. Distribuir o Auto Scaling group em duas AZs. Dar ao role da aplicação acesso de leitura ao DynamoDB. Depois você aperta Validate e ele te corrige.
Esse é o único que se parece com o que eu realmente faço. Não siga estes passos, e sim aqui está um sistema com seis coisas erradas, e ninguém vai te dizer em que ordem consertar.
O que eu diria para outra pessoa sênior
O argumento a favor de uma recertificação de múltipla escolha é que ela é rápida. O argumento a favor dessa aqui é que ela tem o formato certo.
Porque é para isso que servem os fundamentos em 2026. Eu não preciso lembrar o caminho de cliques para criar uma route table. Eu preciso olhar um plano que um agente produziu, perceber que ele criou a conexão de peering e parou, e saber que as rotas estão faltando antes de qualquer coisa ser aplicada. Isso não é memória. Isso é revisão — e revisão só funciona sobre primitivas que você já colocou a mão pelo menos uma vez.
Recertificar clicando é mais lento do que recertificar respondendo. Também me deixou com uma coisa que a prova não deixaria: uma lista curta e honesta das primitivas que eu tinha silenciosamente parado de conseguir conferir.
Valeu as três noites.