AWS Certified Solutions Architect - Associate (SAA-C03) é a certificação da AWS mais realizada, e por um bom motivo. Não é preciso ter "arquiteto" no cargo para se beneficiar dela: analistas de custo, desenvolvedores backend e engenheiros de infraestrutura entendem a AWS de forma sistemática pela primeira vez enquanto se preparam. Como uma enfermeira de triagem decidindo para qual setor encaminhar um paciente, o SAA-C03 avalia se você julga qual combinação de serviços da AWS se encaixa em uma situação. Muitas das 65 questões oferecem respostas plausíveis e pedem a melhor entre elas, então decorar nomes de serviços não basta para passar.
Por Que Este Exame Continua Sendo o Mais Popular
Ninguém assina um contrato de aluguel olhando só a quantidade de quartos: localização, luz natural e taxas de condomínio também importam. O SAA-C03 funciona assim, não verifica apenas se você sabe o que um serviço faz isoladamente, mas se você combina vários deles em uma arquitetura que se encaixe na situação. Por isso um desenvolvedor backend que se prepara para este exame passa a entender a infraestrutura sobre a qual sua aplicação roda, enquanto um engenheiro de infraestrutura aprende a traduzir requisitos de desenvolvimento para linguagem de arquitetura. Também é útil para times sensíveis a custo, já que classe de armazenamento e opções de compra de instância representam cerca de 20% do exame. Essa amplitude explica por que desde engenheiros júnior até desenvolvedores com cinco anos de experiência acabam prestando esse exame.
Formato do Exame: 65 Questões, 130 Minutos e Respostas Deliberadamente Parecidas
Assim como um check-up completo examina vários sistemas em uma única sessão, o SAA-C03 dedica 130 minutos a 65 questões que cobrem todo o design de arquiteturas. Apenas 50 são pontuadas; as 15 restantes são questões-teste para exames futuros, e como não dá para saber quais são, vale dar atenção total a cada uma. A nota de aprovação é 720 de 1000, a taxa é 150 dólares, e a certificação permanece válida por três anos. Os formatos misturam resposta única e múltipla escolha, e os cenários tendem a ser longos, então é preciso praticar para identificar rápido a condição decisiva — custo, latência, tráfego imprevisível — escondida em cada parágrafo.
Domínio 1: Projetar Arquiteturas Resilientes (26%)
Assim como uma usina elétrica mantém um gerador de backup pronto para apagões, este domínio cobre sistemas que continuam funcionando quando algo falha. As ideias centrais são redundância entre zonas de disponibilidade, o Auto Scaling substituindo instâncias com falha, e estratégias de backup e recuperação que atendam metas de RTO e RPO. Uma armadilha comum é confundir Multi-AZ RDS com Read Replicas, ou misturar réplicas em standby com réplicas que servem tráfego ativamente. Os artigos relacionados Alta Disponibilidade e Tolerância a Falhas e Arquitetura Escalável de Acoplamento Fraco aprofundam o desacoplamento de componentes com SQS e SNS.
Domínio 2: Projetar Arquiteturas de Alto Desempenho (24%)
Um depósito ajusta a quantidade de funcionários conforme o volume de pedidos, e este domínio trata de escalar computação, armazenamento, rede e banco de dados para acompanhar o tráfego. Os tópicos-chave incluem escolher o tipo certo de instância EC2, colocar cache na frente do banco com ElastiCache, combinar classes do S3 com o cache do CloudFront, e decidir entre RDS e DynamoDB conforme a carga de trabalho. Quatro artigos relacionados — Computação de Alto Desempenho, Banco de Dados de Alto Desempenho, Rede de Alto Desempenho e Armazenamento de Alto Desempenho — junto com Ingestão e Transformação de Dados de Alto Desempenho, dividem todo esse domínio serviço por serviço.
Domínio 3: Projetar Aplicações e Arquiteturas Seguras (30%)
Um banco entrega a chave do cofre e a chave do compartimento de segurança para pessoas diferentes, e este domínio trata de traçar linhas precisas sobre quem pode acessar o quê. Ele tem o maior peso entre os quatro domínios, então não pode ser tratado como secundário. O essencial são políticas e papéis do IAM, criptografar dados em repouso e em trânsito com o KMS, a diferença entre security groups e network ACLs, e gerenciar credenciais com o Secrets Manager. Os artigos relacionados Projetando Acesso Seguro a Recursos da AWS, Projetando Cargas de Trabalho Seguras e Projetando Controles de Segurança de Dados detalham, cada um, o controle de acesso, o isolamento de cargas de trabalho e a criptografia de dados com cenários reais.
Domínio 4: Projetar Arquiteturas Otimizadas em Custo (20%)
Assim como uma casa troca de plano de energia para se ajustar ao seu padrão real de consumo, este domínio trata de reduzir custo sem sacrificar desempenho. Os tópicos comuns incluem escolher entre instâncias On-Demand, Reserved e Spot conforme as características da carga de trabalho, automatizar a transição entre camadas com políticas de ciclo de vida do S3, e entender como os Savings Plans diferem das Reserved Instances. Quatro artigos relacionados — Computação Otimizada em Custo, Banco de Dados Otimizado em Custo, Rede Otimizada em Custo e Armazenamento Otimizado em Custo — cobrem a estratégia de economia recurso por recurso.
Uma Ordem de Estudo para Iniciantes, e Erros Comuns
Andar por uma cidade desconhecida sem mapa significa percorrer as mesmas ruas duas vezes. Se você é novo na AWS, faz sentido começar pelo Domínio 1 (resiliência) e Domínio 2 (desempenho) para firmar como EC2, S3, RDS e VPC realmente se comportam, depois avançar para o Domínio 3 (segurança) para somar IAM e criptografia, e terminar com o Domínio 4 (custo) para amarrar as opções de compra. O erro mais comum é decorar o que um serviço faz sem nunca clicar no console para testar; passar algumas horas ativando Multi-AZ no RDS ou configurando uma regra de ciclo de vida em um bucket S3 acelera muito mais a resolução de problemas do que só ler. Um segundo erro é não perceber qual das duas condições em conflito — "menor custo" versus "maior desempenho" — o cenário prioriza; comparar a primeira frase da questão com o que ela pede no final ajuda a evitar isso.
Resumo do Exame
"Failover automático entre múltiplas AZs" -- Multi-AZ RDS, Auto Scaling "Desacopla componentes para escalar de forma independente" -- acoplamento fraco com SQS, SNS "Distribui tráfego de leitura, não é um mecanismo de failover" -- Read Replicas "Faz cache de resultados de consultas frequentes ao banco" -- ElastiCache "Entrega conteúdo estático perto do usuário" -- CloudFront "Concede permissões granulares baseadas em papéis" -- políticas e papéis do IAM "Criptografa dados em repouso e em trânsito" -- KMS "Nunca fixar credenciais no código da aplicação" -- Secrets Manager "Cargas de trabalho previsíveis ganham descontos por compromisso" -- Reserved Instances, Savings Plans "Cargas tolerantes a interrupção ganham o menor preço" -- Spot Instances "Dados antigos migram automaticamente para camadas mais baratas" -- políticas de ciclo de vida do S3 "Estratégia de backup alinhada às metas de RTO e RPO" -- design de recuperação de desastres
Resiliência é a estrutura que sobrevive a uma falha, segurança é a estrutura que controla o acesso, e otimização de custo é gastar menos mantendo as duas intactas. Lembrar desses três eixos já resolve metade de cada questão de cenário.