Módulo 7: Reference Architectures And Domain Practice

7. Práctica mixta: Dominios 3 y 4 combinados

Siguiente →

Descripción

El segundo y último banco de práctica mixta de este módulo, con la misma disciplina que la lección 6: diez preguntas originales donde cada escenario exige razonar con High-Performing y Cost-Optimized a la vez — nunca por separado. Este cruce es, con frecuencia, el más sutil de los dos posibles combinados en este módulo, porque las respuestas de "máximo rendimiento" y "mínimo costo" con frecuencia empujan en direcciones opuestas — el examen prueba, precisamente, tu capacidad de encontrar el punto donde ambas se satisfacen a la vez, sin sacrificar una por la otra sin que el escenario lo pida. Cuatro de las diez preguntas usan Andes Cargo; las otras seis usan escenarios genéricos nuevos.

Cómo usar este banco: mismo ritmo que la lección anterior — 2 minutos por pregunta, sin mirar respuestas, después revisión completa de cada explicación, prestando atención a si tu primera respuesta maximizó rendimiento sin verificar costo, o minimizó costo sin verificar que el rendimiento exigido seguía cumpliéndose.

Conexión con el módulo

Como la lección 6, esta lección no introduce ningún concepto nuevo — cada explicación remite a la lección exacta de los Módulos 4, 5 o 6 donde el concepto se estableció con su fuente oficial.

❓ Pregunta 1 — Dominios 3 y 4 (High-Performing + Cost-Optimized) — Andes Cargo

Escenario: La aplicación de tracking de Andes Cargo, construida sobre la tabla Shipments, experimenta un patrón de tráfico altamente impredecible: días normales con tráfico bajo, y picos repentinos —sin aviso previo— cuando un envío de alto perfil genera consultas repetidas del mismo shipmentId miles de veces en pocos minutos (una hot key clásica). El equipo quiere reducir la latencia de esas lecturas repetidas a microsegundos, sin comprometerse a pagar por una capacidad de lectura fija que la mayoría de los días no necesita.

Pregunta: ¿Cuál combinación resuelve ambos objetivos?

A. DynamoDB Accelerator (DAX) delante de Shipments, con la tabla configurada en modo de capacidad aprovisionado al máximo posible, de forma permanente. B. DynamoDB Accelerator (DAX) delante de Shipments, con la tabla configurada en modo de capacidad on-demand. C. Amazon ElastiCache para Redis delante de Shipments, con la tabla en modo aprovisionado con auto scaling de RCU. D. Ninguna capa de caché — simplemente aumentar la capacidad aprovisionada (RCU) de la tabla al máximo disponible.

✅ Respuesta correcta: B

Por qué es correcta: DAX, según la documentación oficial ya citada en el Módulo 4, lección 4, es el caso de uso textual para exactamente este patrón — una hot key leída con mucha más frecuencia que el resto de la tabla — y reduce el tiempo de respuesta de milisegundos de un solo dígito a microsegundos. El modo de capacidad on-demand de DynamoDB, por su parte, cobra por solicitud real en vez de por capacidad reservada — la respuesta correcta para un patrón de tráfico impredecible con picos sin aviso previo, sin pagar por una capacidad fija dimensionada para el peor caso que rara vez ocurre.

Por qué las demás fallan:

  • A: combinar DAX con capacidad aprovisionada al máximo, de forma permanente, resuelve el rendimiento pero ignora por completo el objetivo de costo — el escenario pide explícitamente no comprometerse a pagar capacidad fija que no se usa la mayoría de los días.
  • C: ElastiCache es un caché de propósito general para bases de datos relacionales o de propósito general — DAX, compatible con la API nativa de DynamoDB, es la respuesta más directa y con menos cambios de código para una tabla DynamoDB específicamente, según la misma distinción que el Módulo 4, lección 4, ya estableció.
  • D: aumentar la capacidad aprovisionada permite que la tabla acepte más lecturas por segundo, pero no reduce la latencia de cada lectura individual a microsegundos —sigue siendo del orden de milisegundos, el rendimiento nativo de DynamoDB sin caché delante—, y además reintroduce el problema de costo que el escenario pide evitar.

❓ Pregunta 2 — Dominios 3 y 4 (High-Performing + Cost-Optimized) — Escenario nuevo

Escenario: BancoCumbre, una fintech regional, opera una base de datos PostgreSQL para su plataforma de préstamos, con un patrón de tráfico que varía drásticamente entre el cierre de mes (picos de procesamiento de cuotas) y el resto del mes (tráfico bajo y estable). El equipo, además, mantiene un entorno de desarrollo idéntico que solo se usa durante horario laboral, de lunes a viernes.

Pregunta: ¿Cuál configuración de base de datos resuelve ambos entornos —producción variable y desarrollo intermitente— sin sobreaprovisionar capacidad en ningún momento?

A. Amazon Aurora PostgreSQL-Compatible con Aurora Serverless v2 en ambos entornos: producción con un rango de ACU amplio que absorbe el pico de cierre de mes, y desarrollo con un rango que permite auto-pausa a 0 ACU fuera de horario laboral. B. Amazon RDS for PostgreSQL con una instancia de tamaño fijo, dimensionada para el pico de cierre de mes, en ambos entornos de forma idéntica. C. Amazon Aurora PostgreSQL-Compatible provisioned, con el mismo tamaño de instancia fijo en producción y desarrollo, sin ninguna diferencia de configuración entre ambos. D. Amazon RDS for PostgreSQL con Reserved Instances de 3 años en el entorno de desarrollo, para reducir su costo.

✅ Respuesta correcta: A

Por qué es correcta: Aurora Serverless v2 (Módulo 6, lección 2) resuelve exactamente los dos patrones del escenario, cada uno con su propio rango de capacidad: producción, con un rango de ACU que escala hacia arriba durante el pico de cierre de mes sin intervención manual, y hacia abajo el resto del mes; desarrollo, con un rango que permite escalar hasta 0 ACU —la capacidad de auto-pausa que la misma lección ya estableció— durante las noches y fines de semana en que nadie lo usa, eliminando por completo el costo de cómputo ocioso en esas horas.

Por qué las demás fallan:

  • B: una instancia de tamaño fijo, dimensionada para el pico de cierre de mes, paga ese tamaño máximo durante el resto del mes con tráfico bajo — exactamente el sobreaprovisionamiento sostenido que el escenario pide evitar, en ambos entornos.
  • C: usar el mismo tamaño fijo en desarrollo que en producción ignora por completo que desarrollo se usa solo en horario laboral — paga capacidad de producción las 24 horas para un entorno que se usa una fracción de ese tiempo.
  • D: un Reserved Instance de 3 años es un compromiso de uso continuo a cambio de descuento — aplicarlo a un entorno que se apaga fuera de horario laboral desperdicia gran parte de ese compromiso; los RI/Savings Plans tienen sentido para cargas estables y continuas, no intermitentes, la misma distinción del Módulo 5, lección 3.

❓ Pregunta 3 — Dominios 3 y 4 (High-Performing + Cost-Optimized) — Escenario nuevo — Select TWO

Escenario: UniversidadAbierta, una plataforma de educación en línea, almacena miles de horas de video de clases grabadas en S3, servidas a estudiantes en varios países. Las clases del semestre actual se consultan con mucha frecuencia; las de semestres anteriores a veces se consultan (un estudiante repitiendo una materia), pero con un patrón completamente impredecible —nadie puede anticipar cuál clase antigua se va a consultar, ni cuándo—. El equipo quiere reducir la latencia de reproducción para estudiantes en distintos países, y minimizar el costo de almacenamiento de las clases antiguas sin arriesgarse a que una consulta inesperada tarde horas en responder.

Pregunta: ¿Cuáles dos decisiones, combinadas, cumplen ambos objetivos?

A. Amazon CloudFront como capa de distribución frente al bucket de S3, para reducir la latencia de reproducción en todos los países. B. Mover todas las clases —actuales y antiguas— a S3 Glacier Deep Archive, para minimizar el costo total de almacenamiento. C. S3 Intelligent-Tiering para las clases de semestres anteriores, dejando que el servicio decida automáticamente el nivel de acceso según el patrón real, sin cargo de recuperación. D. Servir las clases directamente desde S3 sin ninguna capa de distribución, para simplificar la arquitectura. E. S3 One Zone-IA para todas las clases, actuales y antiguas, para reducir el costo de almacenamiento a la mitad.

✅ Respuesta correcta: A y C

Por qué es correcta: CloudFront resuelve el objetivo de rendimiento —latencia reducida para estudiantes en distintos países, sirviendo desde edge locations cercanas, el mismo patrón de la lección 3 de este módulo—. Para las clases antiguas, con un patrón de acceso explícitamente impredecible, S3 Intelligent-Tiering es, según la decisión de examen ya establecida en el Módulo 4, lección 2, exactamente la respuesta correcta — mueve automáticamente cada objeto entre niveles de acceso según su patrón real, sin cargo de recuperación en los niveles automáticos, evitando el riesgo de que una consulta inesperada golpee un objeto en un nivel de archivo con horas de recuperación.

Por qué las demás fallan:

  • B: Glacier Deep Archive tiene un tiempo de recuperación de horas — moverlo todo ahí, incluidas las clases del semestre actual (consultadas con frecuencia), o incluso las antiguas con acceso impredecible, arriesga exactamente lo que el escenario pide evitar: una consulta inesperada que tarde horas en responder.
  • D: eliminar CloudFront elimina la ventaja de reducir latencia para estudiantes distantes — contradice directamente el objetivo de rendimiento explícito del escenario, y aumenta la carga directa sobre el bucket S3 con cada reproducción.
  • E: S3 One Zone-IA es más barata que Standard-IA, pero no es resiliente a la pérdida de la zona que la almacena (Módulo 4, lección 2) — aplicarla a contenido educativo institucional, sin ninguna copia de respaldo mencionada en el escenario, introduce un riesgo de pérdida de datos que el escenario nunca autorizó, y tampoco resuelve el problema real de patrón de acceso impredecible que Intelligent-Tiering sí resuelve.

❓ Pregunta 4 — Dominios 3 y 4 (High-Performing + Cost-Optimized) — Escenario nuevo — Select TWO

Escenario: AutoPartesXpress, un e-commerce de repuestos automotrices, tiene un catálogo con un patrón de lectura muy desigual: menos del 5% de los productos concentra la mayoría de las consultas (los repuestos más comunes). Por separado, cada noche corre un trabajo por lotes que recalcula precios de todo el catálogo según demanda —un proceso que tarda horas, tolera interrupciones (puede reiniciarse desde el último punto guardado sin problema), y no tiene ningún requisito de horario exacto de finalización.

Pregunta: ¿Cuáles dos decisiones de arquitectura, combinadas, optimizan rendimiento y costo para cada uno de estos dos problemas distintos?

A. Amazon ElastiCache delante de la base de datos del catálogo, para servir las consultas de los productos más leídos desde memoria. B. Ejecutar el trabajo de recálculo nocturno sobre instancias EC2 On-Demand exclusivamente, para garantizar que nunca se interrumpa. C. Ejecutar el trabajo de recálculo nocturno sobre Spot Instances, aprovechando la tolerancia a interrupción del proceso y su capacidad de reiniciarse desde el último punto guardado. D. Aumentar el tamaño de la instancia de base de datos principal, sin ninguna capa de caché, para servir directamente las consultas de productos populares. E. Ejecutar el trabajo de recálculo nocturno sobre Reserved Instances de 1 año, para reducir su costo de cómputo.

✅ Respuesta correcta: A y C

Por qué es correcta: el patrón de lectura desigual —pocos productos concentrando la mayoría de las consultas— es, con precisión, el caso de uso de un caché en memoria delante de la base de datos (Módulo 4, lección 4): ElastiCache absorbe esas lecturas repetidas sin golpear la base de datos principal en cada solicitud, mejorando el rendimiento percibido. El trabajo de recálculo nocturno, explícitamente tolerante a interrupción y sin requisito de horario exacto, es exactamente el caso de uso textual de Spot Instances (Módulo 5, lección 3) — el descuento más profundo de las opciones de cómputo, apropiado precisamente porque el escenario ya confirma que una interrupción no representa ningún riesgo real.

Por qué las demás fallan:

  • B: usar exclusivamente On-Demand para un trabajo explícitamente tolerante a interrupción ignora el ahorro real que Spot ofrece para ese perfil exacto de carga — el escenario ya eliminó el riesgo que On-Demand estaría pagando de más por evitar.
  • D: aumentar el tamaño de la instancia de base de datos resuelve el síntoma con un costo creciente y sostenido, en vez de resolver la causa —el patrón de lectura desigual— con un caché, que es notablemente más barato que escalar verticalmente la base de datos completa.
  • E: un Reserved Instance de 1 año es un compromiso de uso continuo — aplicarlo a un trabajo que corre unas horas cada noche desperdicia la mayor parte del compromiso pagado; RI/Savings Plans tienen sentido para cómputo que corre de forma sostenida, no por lotes nocturnos puntuales.

❓ Pregunta 5 — Dominios 3 y 4 (High-Performing + Cost-Optimized) — Andes Cargo

Escenario: Las instancias EC2 de la capa de aplicación de Andes Cargo, en subred privada, consultan la tabla Shipments de DynamoDB con mucha frecuencia durante el horario laboral. Actualmente, ese tráfico sale a través de un NAT Gateway hacia el endpoint público de DynamoDB. El equipo quiere reducir tanto la latencia de esas consultas como el costo de transferencia de datos asociado, sin sacrificar el requisito de que el tráfico nunca salga a internet público.

Pregunta: ¿Cuál cambio de arquitectura cumple los tres objetivos a la vez —menor latencia, menor costo, y tráfico que nunca toca internet público?

A. Un Gateway VPC Endpoint hacia DynamoDB, configurado en la tabla de rutas de la subred privada — el tráfico hacia DynamoDB deja de pasar por el NAT Gateway por completo. B. Un NAT Gateway adicional, dedicado exclusivamente al tráfico hacia DynamoDB, para distribuir la carga entre dos NAT Gateways. C. Un Interface VPC Endpoint hacia DynamoDB, con una tarifa por hora y por gigabyte procesado, más barata que la ruta actual por NAT Gateway. D. Habilitar AWS PrivateLink directamente en la tabla Shipments, sin ningún cambio en la configuración de red de la VPC.

✅ Respuesta correcta: A

Por qué es correcta: como ya estableció el Módulo 5, lección 5, un Gateway Endpoint —disponible únicamente para S3 y DynamoDB— no tiene ningún costo por hora ni por gigabyte procesado, y saca el tráfico hacia esos dos servicios por completo de la ruta del NAT Gateway, eliminando tanto el cargo por GB de NAT Gateway como el salto de red adicional que ese servicio representa — cumpliendo los tres objetivos del escenario a la vez: menor latencia (menos saltos de red), menor costo (cero cargo del endpoint, cero cargo de NAT Gateway para ese tráfico específico), y sin tocar internet público en ningún momento.

Por qué las demás fallan:

  • B: un segundo NAT Gateway dedicado sigue cobrando por hora y por GB procesado — no elimina el costo, solo lo distribuye; tampoco reduce la latencia de forma significativa frente a la alternativa de endpoint, que elimina el salto por completo.
  • C: DynamoDB usa específicamente un Gateway Endpoint, sin ningún costo — un Interface Endpoint es el tipo correcto para la mayoría de los demás servicios de AWS, pero no es la opción más barata disponible cuando el servicio de destino es S3 o DynamoDB, que sí tienen la alternativa gratuita.
  • D: PrivateLink es la tecnología subyacente de los Interface Endpoints — no es algo que se "habilite en la tabla" directamente; y, como en la opción C, no es la ruta más barata disponible para DynamoDB específicamente, que tiene el Gateway Endpoint sin costo como alternativa superior.

❓ Pregunta 6 — Dominios 3 y 4 (High-Performing + Cost-Optimized) — Escenario nuevo — Select TWO

Escenario: ContadoresPro, una firma de contabilidad, ejecuta un proceso de cierre contable mensual sobre EC2: cálculos intensivos de CPU que duran aproximadamente 8 horas, el mismo patrón exacto, cada mes, durante los últimos dos años, sin señales de que vaya a cambiar. El proceso actualmente corre sobre instancias de la familia M (propósito general) bajo demanda, y el equipo financiero pregunta por qué el costo mensual de cómputo no ha bajado a pesar de que el patrón es completamente predecible.

Pregunta: ¿Cuáles dos cambios, combinados, optimizan rendimiento y costo para este proceso específico?

A. Migrar el proceso a instancias de la familia C (compute-optimized), dado que el cuello de botella descrito es explícitamente de CPU. B. Comprometerse a un Compute Savings Plan de 1 año, dado que el patrón de uso es predecible y se repite cada mes desde hace dos años. C. Migrar el proceso a instancias de la familia R (memory-optimized), para tener margen adicional de memoria durante el cierre. D. Ejecutar el proceso sobre Spot Instances exclusivamente, sin ninguna capacidad On-Demand de respaldo, dado que Spot siempre es más barato. E. Mantener la familia M actual, pero solicitar un descuento manual directamente con el equipo de cuentas de AWS.

✅ Respuesta correcta: A y B

Por qué es correcta: el escenario da dos señales textuales explícitas, cada una con su respuesta ya establecida en el Módulo 4, lección 3, y el Módulo 5, lección 3. "Cálculos intensivos de CPU" apunta, sin ambigüedad, a la familia compute-optimized (C) — el recurso que el escenario nombra como cuello de botella, no la familia de propósito general que corre actualmente. "El mismo patrón exacto, cada mes, durante los últimos dos años, sin señales de cambio" es, con precisión, la definición de carga predecible que justifica un compromiso de Savings Plan — el descuento por compromiso solo tiene sentido cuando el patrón de uso es previsible, exactamente lo que este escenario confirma con dos años de historial.

Por qué las demás fallan:

  • C: el escenario nombra explícitamente CPU como el cuello de botella, no memoria — migrar a una familia optimizada para memoria (R) no ataca el recurso real que el proceso satura, el mismo error que el Módulo 4, lección 3, ya advirtió sobre elegir una familia "por si acaso".
  • D: Spot Instances no garantizan disponibilidad — pueden interrumpirse con un aviso de dos minutos; un proceso de cierre contable mensual, con presión de completarse en un plazo de negocio, sin ninguna capacidad de respaldo On-Demand, arriesga que el cierre no termine a tiempo, un riesgo que el escenario no autoriza explícitamente a asumir sin mitigación.
  • E: no existe ningún mecanismo estándar de "descuento manual" pedido directamente al equipo de cuentas fuera de los programas de descuento por compromiso ya documentados (RI, Savings Plans) — no es una opción real de arquitectura.

❓ Pregunta 7 — Dominios 3 y 4 (High-Performing + Cost-Optimized) — Andes Cargo

Escenario: Andes Cargo evalúa permitir que sus socios logísticos en distintos países de Sudamérica suban manifiestos de envío directamente a andes-cargo-shipment-docs desde sus propias oficinas, en vez de que Andes Cargo los recolecte manualmente. Un socio en Chile reporta que sus subidas de archivos grandes (varios cientos de megabytes) tardan varios minutos, un tiempo que afecta su flujo operativo diario. Un segundo socio, en una ciudad cercana a us-east-1, no reporta ningún problema de velocidad.

Pregunta: ¿Cuál es la decisión más ajustada al problema descrito, sin incurrir en un costo innecesario para el socio sin problema de velocidad?

A. Habilitar S3 Transfer Acceleration en andes-cargo-shipment-docs para todas las subidas, sin distinción de origen geográfico. B. Habilitar S3 Transfer Acceleration únicamente para los socios que reportan problemas de velocidad reales, usando el punto de acceso acelerado solo en esos casos, dejando el punto de acceso estándar (sin cargo adicional) para el resto. C. Mover el bucket completo a una Región más cercana a Chile, para reducir la latencia de todos los socios por igual. D. Pedirle al socio en Chile que comprima los archivos antes de subirlos, como única solución.

✅ Respuesta correcta: B

Por qué es correcta: S3 Transfer Acceleration, según ya estableció el Módulo 5, lección 1, acelera la velocidad de subida usando la red de CloudFront, pero agrega un cargo adicional propio sobre la transferencia — la decisión de examen correcta no es "encenderlo para todo el bucket", sino aplicarlo específicamente donde el problema real de distancia geográfica lo justifica. El socio cercano a us-east-1, sin ningún problema reportado, no necesita pagar ese cargo adicional — usar el punto de acceso estándar para él, y el acelerado solo para el socio distante, optimiza rendimiento donde hace falta sin costo innecesario donde no.

Por qué las demás fallan:

  • A: habilitar Transfer Acceleration para todas las subidas, sin distinción, cobra el cargo adicional también al socio que no reporta ningún problema — un costo que el escenario no justifica para ese caso específico.
  • C: mover el bucket completo de Región es un cambio de infraestructura mucho más disruptivo, que además introduce una pregunta de residencia de datos y afecta a todos los sistemas de Andes Cargo que ya dependen de andes-cargo-shipment-docs en us-east-1, no solo a este socio — desproporcionado frente al problema descrito.
  • D: comprimir archivos puede ayudar parcialmente, pero no ataca la causa real del problema —la distancia de red entre el origen de la subida y la Región del bucket—, y depende de que el socio externo cambie su propio flujo de trabajo, algo que Andes Cargo no controla directamente.

❓ Pregunta 8 — Dominios 3 y 4 (High-Performing + Cost-Optimized) — Escenario nuevo

Escenario: AeropuertoCentral, la autoridad que administra un aeropuerto internacional, opera un sistema de seguimiento de vuelos en tiempo real que combina datos de radar de múltiples fuentes usando un protocolo UDP propietario, no HTTP. El sistema exige una dirección IP fija —los sistemas de radar externos están configurados para enviar datos a una IP específica, sin capacidad de resolver DNS dinámicamente— y necesita conmutar automáticamente hacia una Región secundaria en segundos, no minutos, ante cualquier degradación de la Región primaria, dado que la seguridad aérea depende de este sistema.

Pregunta: ¿Cuál servicio, aunque más costoso que una alternativa más simple, se justifica por la criticidad del sistema descrito?

A. Un Application Load Balancer estándar con un registro DNS de Route 53 apuntando a su nombre. B. AWS Global Accelerator, con direcciones IP anycast estáticas y conmutación de tráfico basada en health checks, dirigiendo hacia el endpoint saludable en segundos. C. Amazon CloudFront, con orígenes configurados en ambas regiones y failover de origen automático. D. Un Network Load Balancer regional simple, sin ningún mecanismo de conmutación entre regiones.

✅ Respuesta correcta: B

Por qué es correcta: el escenario da dos señales que, combinadas, apuntan sin ambigüedad a Global Accelerator (Módulo 4, lección 5): un protocolo que no es HTTP/HTTPS (UDP propietario, algo que ni ALB ni CloudFront soportan) y el requisito explícito de una IP estática que los sistemas de radar externos ya tienen configurada de forma fija — exactamente la pieza más citada de Global Accelerator, sus direcciones anycast estáticas. La conmutación en segundos, basada en health checks sobre la red troncal privada de AWS, cumple el requisito de criticidad de seguridad aérea. El costo adicional de Global Accelerator frente a una alternativa más simple se justifica, con precisión, por la magnitud de la consecuencia de una falla en este sistema específico — la misma lógica de "el escenario justifica explícitamente el gasto mayor" que domina cualquier decisión de costo bien razonada.

Por qué las demás fallan:

  • A: un ALB no soporta protocolos no-HTTP como UDP, y no ofrece una IP estática nativa — ninguna de las dos señales del escenario encaja con esta opción, sin importar cómo se combine con Route 53.
  • C: CloudFront es un acelerador de contenido con caché, diseñado para HTTP/HTTPS — no tiene ningún soporte para un protocolo UDP propietario de datos de radar en tiempo real; es la herramienta equivocada para este tipo de tráfico.
  • D: un Network Load Balancer regional sí soporta UDP y puede tener una IP estática dentro de una Región, pero no ofrece, por sí solo, ningún mecanismo de conmutación automática entre regiones en segundos — el escenario exige explícitamente esa conmutación multi-región, que NLB regional no resuelve sin una capa adicional.

❓ Pregunta 9 — Dominios 3 y 4 (High-Performing + Cost-Optimized) — Escenario nuevo — Select TWO

Escenario: LogiCarga, una empresa de logística de última milla, ejecuta cada noche un cálculo de optimización de rutas para el día siguiente — un proceso intensivo de CPU que corre sobre un Auto Scaling Group. El proceso tolera que instancias individuales se interrumpan (el trabajo se redistribuye automáticamente entre las instancias restantes), pero el equipo necesita garantizar que el cálculo siempre termine antes de las 5 a.m., sin excepción, incluso si AWS interrumpe una parte significativa de la capacidad Spot disponible esa noche.

Pregunta: ¿Cuáles dos decisiones de configuración del Auto Scaling Group cumplen ambos objetivos —costo optimizado y garantía de finalización— para este trabajo?

A. Configurar el Auto Scaling Group con una política de instancias mixtas: una base mínima de capacidad On-Demand que garantiza que el trabajo siempre pueda avanzar, y el resto de la capacidad en Spot Instances para el ahorro adicional. B. Usar instancias de la familia C (compute-optimized), dado que el cuello de botella del proceso es explícitamente de CPU. C. Usar exclusivamente Spot Instances, sin ninguna base On-Demand, confiando en que la interrupción de Spot nunca afecta a todas las instancias del grupo al mismo tiempo. D. Usar instancias de la familia R (memory-optimized), para maximizar la memoria disponible durante el cálculo. E. Configurar el Auto Scaling Group con capacidad fija, sin ninguna política de escalado dinámico, dimensionada para el peor caso de carga posible.

✅ Respuesta correcta: A y B

Por qué es correcta: la política de instancias mixtas (Módulo 5, lección 3) resuelve exactamente la tensión del escenario: una base On-Demand garantiza que el trabajo siempre tenga capacidad mínima para avanzar hacia la fecha límite de las 5 a.m., mientras el resto en Spot captura el ahorro adicional para la carga que sí tolera interrupción — ni el costo máximo de todo On-Demand, ni el riesgo de todo Spot sin ninguna garantía. La familia compute-optimized (C) es, de nuevo, la respuesta correcta al cuello de botella explícito de CPU que el escenario describe, el mismo razonamiento de la Pregunta 6 de este banco aplicado a un escenario distinto.

Por qué las demás fallan:

  • C: confiar en que Spot "nunca afecta a todas las instancias a la vez" no es una garantía que AWS ofrezca — una interrupción de capacidad Spot puede, en principio, afectar una porción significativa de la flota simultáneamente; sin ninguna base On-Demand, el escenario arriesga exactamente lo que el equipo dice no poder tolerar: que el cálculo no termine a tiempo.
  • D: el cuello de botella descrito es de CPU, no de memoria — la misma corrección de la Pregunta 6, aplicada aquí de nuevo.
  • E: una capacidad fija dimensionada para el peor caso paga ese tamaño máximo todas las noches, incluso las que no lo necesitan — el opuesto exacto de un Auto Scaling Group bien configurado, y no resuelve por sí sola ni el requisito de costo ni aprovecha ningún descuento de Spot.

❓ Pregunta 10 — Dominios 3 y 4 (High-Performing + Cost-Optimized) — Andes Cargo

Escenario: El equipo de analítica de Andes Cargo quiere mantener un entorno de reportes que replica el contenido de Shipments hacia una base de datos relacional, para ejecutar consultas complejas de agregación que DynamoDB no modela bien. Ese entorno de reportes se consulta activamente solo un par de horas al final de cada mes, cuando se genera el reporte ejecutivo — el resto del mes, nadie lo toca. Cuando sí se usa, el equipo necesita que responda con buen rendimiento, sin esperar a que una instancia "despierte" desde cero.

Pregunta: ¿Cuál configuración cumple el objetivo de costo (nada de gasto sostenido los 28-29 días sin uso) y el de rendimiento (buena respuesta durante las pocas horas de uso real)?

A. Amazon RDS for PostgreSQL con una instancia de tamaño fijo, corriendo de forma permanente durante todo el mes. B. Amazon Aurora PostgreSQL-Compatible con Aurora Serverless v2, con un rango de capacidad configurado desde un mínimo bajo (o auto-pausa a 0 ACU cuando no hay conexiones activas) hasta un máximo que cubre el pico del reporte ejecutivo. C. Amazon DynamoDB con DAX delante, replicando el contenido de Shipments sin ningún cambio de motor. D. Amazon RDS for PostgreSQL con Reserved Instances de 3 años, para el menor costo por hora posible.

✅ Respuesta correcta: B

Por qué es correcta: Aurora Serverless v2 (Módulo 6, lección 2) resuelve exactamente este patrón de uso intermitente y predecible en su ventana de actividad: escala hacia 0 ACU (o un mínimo bajo) durante los días sin uso, eliminando el costo de cómputo sostenido, y escala hacia arriba, dentro del rango configurado, cuando las consultas del reporte ejecutivo llegan — sin que nadie tenga que "encender" nada manualmente ni esperar un arranque en frío largo, cumpliendo el objetivo de rendimiento durante las pocas horas reales de uso.

Por qué las demás fallan:

  • A: una instancia de tamaño fijo corriendo de forma permanente paga ese costo los 28-29 días que nadie la usa — el opuesto exacto del objetivo de costo explícito del escenario.
  • C: DAX acelera lecturas de DynamoDB, pero el escenario pide explícitamente una base de datos relacional para consultas complejas de agregación que DynamoDB no modela bien — mantener el mismo motor NoSQL no resuelve el requisito funcional del equipo de analítica, sin importar cuánto acelere las lecturas.
  • D: un Reserved Instance de 3 años es un compromiso de uso continuo — aplicado a una base de datos que se usa un par de horas al mes, desperdicia la inmensa mayoría del compromiso pagado, el mismo error de costo ya identificado en preguntas anteriores de este banco.

Resumen y siguiente paso

Con este banco cierras la segunda y última ronda de práctica mixta del módulo: diez preguntas originales que cruzan High-Performing y Cost-Optimized en un mismo escenario —DAX y capacidad on-demand, Aurora Serverless v2 con auto-pausa, Intelligent-Tiering junto a CloudFront, Spot para cargas tolerantes, Gateway Endpoints sin costo, familias de instancia por el recurso correcto, y Global Accelerator justificado por criticidad—, siempre verificando que ninguna respuesta maximizara un dominio sacrificando el otro sin que el escenario lo pidiera.

Antes de avanzar, revisa cualquier pregunta donde hayas dudado, y confirma si tu primera respuesta optimizó rendimiento ignorando costo, o costo ignorando un requisito de rendimiento explícito del escenario.

La lección 8 cierra el módulo con el proyecto final: tu propio diagrama de arquitectura de referencia, para un escenario que no has visto en ningún lugar de este ecosistema — la prueba real de transferencia, antes del examen de práctica completo del Módulo 8.

Recursos

  1. AWS Certification — SAA-C03 Domain 3: Design High-Performing Architectures y Domain 4: Design Cost-Optimized Architectures — fuente oficial de ambos task statements, combinados en las diez preguntas de este banco.
  2. Amazon RDS — Aurora Serverless v2 — fuente oficial del mecanismo de auto-pausa citado en las Preguntas 2 y 10.
  3. Amazon S3 — VPC endpoints for Amazon S3 y Gateway endpoints for Amazon DynamoDB — fuente oficial del Gateway Endpoint citado en la Pregunta 5.
  4. Módulos 4, 5 y 6 de esta guía — cada explicación de este banco remite a la lección exacta donde el concepto correspondiente se estableció con su fuente oficial completa.
← Anterior6. Práctica mixta: Dominios 1 y 2 combinadosSiguiente →8. Proyecto: tu propio diagrama de arquitectura, escenario nuevo