En abril del año pasado rendí y aprobé la certificación AWS Security Specialty. Lo hice sin cortar mi rutina laboral, con reuniones, incidentes, proyectos y responsabilidades de liderazgo.

No hubo magia ni “fórmulas secretas”. Hubo algo más aburrido, pero mucho más poderoso: claridad de enfoque y consistencia.

Empezar por la estrategia, no por el contenido

Antes de abrir ningún curso, hice algo que hoy me parece obvio, pero que muchas veces salteamos: leí el blueprint oficial del examen. Revisé los seis dominios y sus pesos, y me pregunté con honestidad:

  • ¿En cuáles me siento fuerte por mi trabajo diario?
  • ¿En cuáles tengo lagunas o solo conocimientos superficiales?

Mis fortalezas estaban en IAM, logging, monitoreo e infraestructura. Mis brechas aparecían en KMS avanzado, criptografía aplicada y governance. Esa foto inicial fue clave para no intentar “estudiar todo” y terminar saturado.

Estudiar por dominio, no por servicio

Una tentación muy común es abrir la consola de AWS y empezar a repasar servicios como si fueran una checklist: IAM, S3, KMS, CloudTrail, Config…

Yo decidí otra cosa: estudiar por dominio. Para cada dominio me hacía una pregunta guía:

“¿Qué espera AWS que sepa un Security Engineer real frente a un escenario complejo en este dominio?”

Eso me obligó a pensar en patrones, no en features sueltas: modelos de cuentas, aislamiento, flujos de cifrado, estrategias de detección, líneas de responsabilidad entre servicios y equipos.

Cada servicio pasaba a ser una pieza de un sistema más grande. De esa forma, cuando el examen planteaba un escenario con varias capas (multi-account, compliance, incident response, costos), mi cabeza ya estaba entrenada para verlo como un todo.

Simulacros como herramienta de pensamiento

Los exámenes de práctica no los usé para “medir la nota”, sino como herramienta de pensamiento.

Cada vez que fallaba una pregunta, iba más allá del “la respuesta correcta era la C” y me preguntaba:

  • ¿Qué me hizo elegir la opción incorrecta?
  • ¿Qué palabra de la pregunta no vi o subestimé?
  • ¿Qué supuesto técnico estaba dando por hecho que no era válido?

Esto entrenó mi capacidad de lectura rápida y precisa en inglés, pero sobre todo afinó mi manera de pensar como el perfil que AWS espera: alguien que evalúa riesgo, impacto y trade-offs, no solo que recuerda comandos o pantallas.

Bloques pequeños, consistencia grande

Decidí estudiar 30 minutos por día, de lunes a viernes. Nada épico. Lo importante no era el tamaño del bloque, sino su calidad.

Cada bloque tenía un objetivo concreto, por ejemplo:

  • “Hoy quiero terminar de entender bien cómo rota KMS las claves.”
  • “Hoy solo repaso escenarios de incident response y CloudTrail.”
  • “Hoy comparo alternativas de diseño para un entorno multi-account.”

Al final de cada día, hacía un mini cierre mental: ¿qué entendí hoy que ayer no tenía tan claro?. Eso hacía que el progreso fuera visible, aunque el tiempo fuera poco.

Lo que realmente marcó la diferencia

Mirando hacia atrás, no fue el curso que elegí ni la cantidad total de horas lo que inclinó la balanza. Fueron tres cosas:

  • Un mapa claro de dominios y prioridades.
  • Un método para aprender de cada error en los simulacros.
  • Un sistema de bloques pequeños pero constantes.

La certificación terminó siendo casi una consecuencia natural de ese sistema. Y, de paso, mejoró mi forma de pensar arquitectura y seguridad en el día a día, más allá del examen.

Si estás pensando en rendir AWS Security Specialty mientras trabajás a tiempo completo, mi recomendación es esta: no busques tiempo “perfecto”, construí un sistema lo suficientemente simple como para sostenerlo incluso en semanas caóticas.

La intensidad impresiona, pero la consistencia transforma.