Módulo 1: The Exam And Your Unfair Advantage
3. Los 4 dominios y sus pesos reales
Descripción
Si buscas "SAA-C03 domains" en cualquier foro o video de estudio informal, es común encontrar el orden de peso equivocado —muchos materiales listan Resilient Architectures como el dominio más pesado, o simplemente no citan un porcentaje verificable. No es así. El dominio con más peso real es Design Secure Architectures, con un 30% —el único que supera un tercio del examen—. Esta lección corrige ese error de entrada, con los cuatro pesos exactos confirmados contra la guía de examen oficial de AWS, y lista los task statements completos de cada dominio: el temario oficial, textual, que define qué es "material de examen" y qué no.
Conexión con el módulo
Esta lección es la contraparte de contenido de la lección 2 —forma vs. contenido—. Con las dos, tienes el mapa completo del examen. La lección 4 cruza este mapa con el inventario de las nueve guías previas: vas a ver, dominio por dominio, cuánto de esto ya construiste con tus propias manos.
Los 4 dominios, en el orden real de peso
| # | Dominio | Peso | Task statements |
|---|---|---|---|
| 1 | Design Secure Architectures | 30% | 3 |
| 2 | Design Resilient Architectures | 26% | 2 |
| 3 | Design High-Performing Architectures | 24% | 5 |
| 4 | Design Cost-Optimized Architectures | 20% | 4 |
Tres cosas saltan de esta tabla, y las tres importan para cómo repartes tu tiempo de estudio:
- Secure pesa casi un tercio del examen entero, solo. Un candidato que estudia los cuatro dominios por igual está subinvirtiendo, en proporción, en el que más pesa. El Módulo 2 de esta guía —el más largo de los cuatro dominios en número de lecciones— refleja esto a propósito.
- High-Performing tiene el mayor número de task statements (5), pero no el mayor peso. Es el dominio más ancho en superficie —toca storage, cómputo, base de datos, red e ingesta de datos— sin ser, por peso, el más importante. Ancho no es lo mismo que pesado.
- Cost-Optimized es el más liviano, y coincide con el dominio que ya dominas más si vienes de
finops-and-cost-guardrails-guide. La lección 4 desarrolla esto con la tabla completa.
Qué te pide cada dominio
Los cuatro dominios y sus pesos son los que AWS publica en su guía de examen, y están enlazados en Recursos al final de esta lección. Lo que sigue no es esa guía traducida. Es otra cosa, y más útil para ti: cómo se lee cada dominio desde el trabajo que ya hiciste con las manos, y qué tipo de decisión te va a pedir tomar el examen en cada uno.
Para la lista oficial —los task statements con sus conocimientos y habilidades detallados— ve a la fuente. Es la única versión vigente, y AWS la actualiza cuando saca versión nueva del examen; cualquier copia envejece en silencio.
Domain 1 — Design Secure Architectures · 30% · 3 task statements
Seguridad en este examen no es "qué servicios de seguridad existen". Es una pregunta repetida en tres capas: quién puede tocar qué, por dónde entra el tráfico, y qué le pasa al dato cuando está guardado y cuando viaja.
- Identidad. Roles en vez de credenciales de larga vida, permisos mínimos, y qué hacer cuando hay más de una cuenta. Si ya montaste federación y políticas acotadas, aquí reconoces el terreno.
- Perímetro. Diseño de red privada, qué se expone y qué no, y qué servicio te defiende de qué amenaza concreta. La trampa típica es elegir el servicio correcto para el ataque equivocado.
- Dato. Cifrado en reposo y en tránsito, y sobre todo quién controla la llave, que es donde el examen separa a quien memorizó nombres de quien entendió el modelo.
El dominio más pesado del examen, y el mejor cubierto por
cloud-security-and-guardrails-guide.
Domain 2 — Design Resilient Architectures · 26% · 2 task statements
Dos preguntas que suenan parecidas y no lo son: cómo se desacopla un sistema y cómo sobrevive a que algo se caiga.
- Desacoplar. Colas, eventos y piezas sin estado para que un componente
lento o caído no arrastre al resto. Es el terreno de
aws-serverless-and-containers-guidey dekubernetes-and-eks-in-production-guide. - Sobrevivir. Aquí el examen se pone cuantitativo: cuánto dato puedes permitirte perder y cuánto tiempo puedes estar caído. De esos dos números sale la estrategia de recuperación, y no al revés. Repartir entre zonas o entre regiones cuesta distinto y protege de cosas distintas.
Este es el hueco más grande del ecosistema. Ninguna de las nueve guías previas montó un balanceador real, un grupo de auto escalado ni una estrategia formal de recuperación ante desastres. Presupuesta tiempo nuevo de verdad.
Domain 3 — Design High-Performing Architectures · 24% · 5 task statements
El dominio más ancho de los cuatro, y conviene no confundir ancho con pesado. Recorre cinco frentes —almacenamiento, cómputo, base de datos, red e ingesta de datos— y en los cinco la pregunta es la misma: dado este perfil de carga, ¿cuál es la herramienta correcta?
El examen no premia saber que un servicio existe. Premia saber por qué este encaja y el de al lado no: si el acceso es secuencial o aleatorio, si el tráfico es constante o a ráfagas, si la lectura pesa más que la escritura, si la latencia la manda la distancia o el cálculo.
aws-core-services-guide cubre bien la parte de cómputo y base de datos. El
almacenamiento y la red de alto rendimiento son, en su mayoría, terreno nuevo.
Domain 4 — Design Cost-Optimized Architectures · 20% · 4 task statements
Aquí hay un atajo que vale oro y que casi nadie señala: este dominio recorre las mismas cuatro áreas que el anterior —almacenamiento, cómputo, base de datos, red— pero con otra lente. Donde Domain 3 pregunta "¿cuál rinde más?", Domain 4 pregunta "¿cuál cuesta menos sin romper el requisito?".
Estudiarlos como si fueran temarios independientes es duplicar trabajo. Estudia cada área una vez, y en cada una hazte las dos preguntas.
Lo específico de este dominio son los mecanismos de descuento por compromiso y
las herramientas de análisis de gasto. El resto es criterio que ya tienes si
vienes de finops-and-cost-guardrails-guide: el más liviano del examen, y
probablemente el que ya dominas más.
Por qué el orden importa para cómo estudias
No es solo trivia de examen. Un candidato que reparte su tiempo de estudio en cuatro partes iguales —25% cada dominio— está, en efecto, subinvirtiendo un 5 puntos porcentuales en Secure (30% real vs. 25% de su tiempo) y sobreinvirtiendo 5 puntos en Cost-Optimized (20% real vs. 25% de su tiempo). No es un error catastrófico —el modelo compensatorio de la lección 2 amortigua esto—, pero sí es una ineficiencia evitable. Esta guía refleja los pesos reales en su propia estructura: el Módulo 2 (Secure) es, a propósito, el módulo más largo de los cuatro dominios; el Módulo 5 (Cost-Optimized) es, a propósito, el más corto de escribir —porque finops-and-cost-guardrails-guide ya construyó la mayor parte de lo que ese dominio exige.
Qué significa "in-scope" y por qué importa antes de la lección 4
Cada task statement que acabas de leer viene acompañado, en la fuente oficial, de dos listas: "Knowledge of" (qué necesitas saber conceptualmente) y "Skills in" (qué necesitas poder decidir dado un escenario). Ninguna de las dos listas es exhaustiva por diseño —la propia guía de examen de AWS lo aclara: "This exam guide does not provide a comprehensive list of the content on the exam"—. Lo que sí es exhaustivo, y complementa a los task statements, es una lista separada que AWS publica: los servicios in-scope del examen, agrupados por categoría (Analytics, Compute, Database, Networking, Security, Storage, y otras). Esa lista es la que usa el Módulo 6 de esta guía para construir su matriz de cobertura completa, y la que la lección 4 —la siguiente— usa para cruzar cada task statement con lo que ya construiste en las nueve guías previas.
Una aclaración importante sobre esa lista: es in-scope, no "va a aparecer en tu examen específico". El examen real solo usa un subconjunto de esos servicios en las 65 preguntas que te toquen a ti —nadie ve una pregunta sobre cada servicio de la lista—. Lo que la lista garantiza es que ningún servicio fuera de ella debería aparecer en una pregunta legítima del examen. Si alguna vez encuentras una pregunta de práctica —en esta guía o en cualquier otra fuente— que depende de un servicio fuera de esa lista oficial, es una señal de que esa pregunta no está bien calibrada al examen real.
Cómo se reparten los task statements entre las nueve guías previas
Antes de entrar a la tabla completa de la lección 4, aquí tienes una vista rápida de qué tan repartido está el trabajo de "relectura" entre los cuatro dominios, según cuántas guías previas tocan cada uno de forma directa:
| Dominio | Guías previas más relevantes | Densidad de "ya lo operé" |
|---|---|---|
| Secure (30%) | cloud-security-and-guardrails-guide, aws-core-services-guide | Alta — es, con ventaja, el dominio mejor cubierto por el ecosistema |
| Resilient (26%) | aws-serverless-and-containers-guide, kubernetes-and-eks-in-production-guide, sre-and-incident-response-guide | Media-alta — fuerte en desacoplamiento y contenedores, con huecos reales en ELB/Auto Scaling |
| High-Performing (24%) | aws-core-services-guide, finops-and-cost-guardrails-guide (tangencial) | Media — cubre DynamoDB y Lambda a fondo, pero storage/red de alto rendimiento son mayormente nuevos |
| Cost-Optimized (20%) | finops-and-cost-guardrails-guide | Alta — el dominio que, en criterio, ya dominas más de los cuatro |
Esta tabla no es una promesa de que un dominio "denso" no requiera estudio —cada uno tiene servicios genuinamente nuevos, como viste arriba—. Es una guía de dónde tu tiempo de relectura probablemente rinde más rápido, y dónde vas a necesitar más tiempo nuevo de verdad. La lección 4 la desarrolla con precisión total, guía por guía.
Errores comunes
Repetir el orden de peso incorrecto que circula informalmente. Qué pasa: alguien memoriza "Resilient es el dominio más pesado" porque lo leyó en un video o post no verificado. Cómo detectarlo: si tu plan de estudio le da más tiempo a Resilient que a Secure. Cómo corregirlo: el orden real, confirmado contra la fuente oficial de AWS, es Secure (30%) → Resilient (26%) → High-Performing (24%) → Cost-Optimized (20%). Vuelve a esta tabla cada vez que dudes.
Asumir que el dominio con más task statements es el más pesado. Qué pasa: alguien ve que High-Performing tiene 5 task statements —más que ningún otro dominio— y asume que por eso pesa más. Cómo detectarlo: si estás contando task statements en vez de mirar el porcentaje oficial. Cómo corregirlo: el número de task statements mide amplitud de temario, no peso en el puntaje. High-Performing es el dominio más ancho (24% repartido en 5 áreas distintas), no el más pesado —ese sigue siendo Secure, con solo 3 task statements pero 30% de peso.
Estudiar los cuatro dominios con el mismo tiempo asignado. Qué pasa: alguien construye un calendario de estudio con bloques iguales para cada dominio, "para ser justos". Cómo detectarlo: si tu calendario tiene la misma cantidad de horas para Secure que para Cost-Optimized. Cómo corregirlo: no es necesario ser rígido con los porcentajes exactos, pero el peso real debería inclinar la balanza —más tiempo relativo en Secure y Resilient (56% del examen combinado), menos en Cost-Optimized (20%, y el dominio que probablemente ya dominas más si vienes de finops-and-cost-guardrails-guide).
Resumen y siguiente paso
En esta lección confirmaste el orden real de peso de los cuatro dominios —Secure (30%) → Resilient (26%) → High-Performing (24%) → Cost-Optimized (20%)— y viste el temario oficial completo, task statement por task statement, tal como AWS lo publica. Esta tabla es la que gobierna la estructura de los Módulos 2 a 5 de esta guía, lección por lección.
Antes de avanzar deberías poder recitar los cuatro dominios en su orden real de peso, sin mirar la tabla, y explicar por qué High-Performing tiene más task statements sin ser el dominio más pesado.
La lección 4 cruza este mapa con lo que ya construiste: la tabla completa de las nueve guías previas y qué le dio cada una a Andes Cargo, dominio por dominio.
Recursos
- Guía oficial del examen SAA-C03 — Content outline — la fuente de los cuatro pesos exactos.
- Domain 1: Design Secure Architectures — los 3 task statements completos, con conocimientos y habilidades detallados.
- Domain 2: Design Resilient Architectures
- Domain 3: Design High-Performing Architectures
- Domain 4: Design Cost-Optimized Architectures