El problema
Aprobé AWS Solutions Architect – Associate (SAA-C03) con un plan de seis semanas compatible con el trabajo. Lo que más me aportó no fue el temario, sino un método para analizar cada fallo de simulacro.
Me presenté para entrenar una cosa concreta: elegir entre servicios con criterio cuando un escenario pone varias restricciones a la vez.
Esta guía es la central de la serie de certificaciones. El método de análisis de fallos vive aquí, y las guías de AIF-C01 y AZ-900 lo enlazan en vez de repetirlo.
SAA-C03 no pregunta qué hace un servicio. Pregunta cuál encaja mejor con unas restricciones concretas.
Qué evalúa
Lo organicé en cuatro bloques, que siguen los dominios de la guía oficial:
- Arquitecturas resilientes y de alta disponibilidad.
- Arquitecturas de alto rendimiento.
- Diseños seguros: IAM, cifrado y red.
- Coste y excelencia operativa.
El peso de cada dominio y el formato del examen cambian con el tiempo. Para los datos vigentes, consulta la guía oficial del examen.
La dificultad casi nunca es saber qué hace un servicio. Es descartar tres opciones que funcionan, pero que incumplen alguna condición del enunciado.
Las comparativas que más pesan
Antes de empezar el plan, me hice una lista de pares que se confunden. Casi todas las preguntas difíciles giraban alrededor de alguno:
- RDS o DynamoDB.
- SQS, SNS o EventBridge.
- EBS, EFS o S3.
- EC2, Lambda o ECS con Fargate.
Para cada par me apuntaba una frase: cuándo gana uno y qué condición del enunciado lo delata. Esa hoja la repasaba antes de cada simulacro.
El plan de seis semanas
Cada semana tenía un tema y un objetivo que podía comprobar al final.
| Semana | Tema | Qué trabajé |
|---|---|---|
| S1 | Fundamentos de arquitectura | networking, IAM, compute y storage |
| S2 | Sistemas resilientes | Multi-AZ, backup y DR básico |
| S3 | Rendimiento y escalabilidad | caching, Auto Scaling y balanceo |
| S4 | Seguridad y gobernanza | mínimo privilegio, cifrado y redes privadas |
| S5 | Coste y operaciones | right sizing, pricing y monitorización |
| S6 | Simulacros y consolidación | análisis de errores por patrón |
En S1 repasé el Well-Architected Framework a nivel práctico. Me sirvió de índice para el resto: cada pilar acaba siendo un dominio del examen.
De S2 a S5 alterné teoría y preguntas del mismo tema. Así un fallo apuntaba a algo concreto y no a todo el temario a la vez.
S6 fue solo simulacros completos y su análisis. Ahí ya no abría temas nuevos.
Dejar seguridad para el final es tentador y caro. Aparece en preguntas de casi todos los bloques, no solo en el suyo.
Recursos que usé
Pocos y en este orden:
- El curso de Joan Amengual en Udemy, como base del temario: Curso AWS Solutions Architect Associate.
- Sus exámenes de práctica, para las dos últimas semanas: Exámenes de práctica AWS Solutions Architect Associate.
- La página oficial de la certificación, para comprobar el alcance: AWS Certified Solutions Architect – Associate.
- El AWS Well-Architected Framework, para entender el porqué de cada patrón.
No cambié de recurso a mitad. Cuando un tema no me quedaba claro, iba a la documentación de ese servicio y volvía al curso.
Cómo analizo cada fallo de simulacro
Este es el método común de la serie. La nota de un simulacro dice poco; lo útil es por qué fallé cada pregunta.
Cada fallo lo paso por cuatro preguntas y lo apunto en una hoja:
- ¿Qué requisito pedía de verdad el enunciado?
- ¿Qué opción parecía correcta, pero era incompleta?
- ¿Qué trade-off olvidé: coste, seguridad, rendimiento u operación?
- ¿Qué patrón tengo que reforzar para no repetirlo?
Con dos o tres simulacros analizados así, los fallos se agrupan solos. Dejan de ser preguntas sueltas y pasan a ser tres o cuatro patrones.
Un simulacro sin analizar solo mide. Analizado, te dice qué estudiar mañana.
En el enunciado busco primero las palabras que fijan la restricción: cost-effective, highly available o minimal operational overhead. Muchas veces deciden la respuesta antes de leer las opciones.
Cómo enfoqué el examen
Me planteé el examen en dos pasadas. En la primera respondía lo claro y marcaba las dudas; en la segunda volvía a los escenarios largos.
Ante cada duda, leía primero el requisito y después descartaba lo que incumplía alguna condición explícita. Entre dos opciones válidas, solía ganar la de menos operación.
Reservé los minutos finales para las preguntas marcadas que más podían cambiar. Las de pura memoria no las revisé.
- Resuelvo escenarios sin depender de recordar frases literales.
- Explico cada comparativa frecuente con una frase.
- Entiendo IAM y cifrado a nivel de diseño.
- Justifico una decisión por coste y por operación.
- Mis simulacros son estables durante varias semanas, no uno bueno suelto.
Lo que aprendí
La opción técnicamente posible y la correcta no son la misma. Casi siempre las separa una condición del enunciado que había leído deprisa.
El hábito de apuntar el trade-off olvidado me sigue sirviendo fuera del examen. Ahora lo aplico al preparar la siguiente, AWS CloudOps Engineer, que está en preparación.
Si tienes dudas o lo estás montando tú, cuéntamelo.
