Tech Lead MFA

Aquí tienes el set de preguntas completamente adaptado a las nuevas directrices estructuradas, incluyendo las rúbricas detalladas y las respuestas de referencia para cada caso:

1. [Título] Límite de ejecuciones concurrentes en Lambda

• [Pregunta] Durante un pico masivo de solicitudes de restablecimiento de contraseña (SSPR) en el entorno de la empresa ficticia FinNova, el API Gateway empezó a retornar errores 502 debido a que las Lambdas alcanzaron su límite de concurrencia. Tu desarrollador junior propone como solución inmediata envolver el código de la Lambda en un bloque try/catch global para capturar el error de concurrencia y reintentar la operación internamente de forma asíncrona. Explica con tus propias palabras, como si le hablaras a alguien sin conocimientos técnicos, por qué tomaste esa decisión respecto a aceptar o rechazar esta propuesta.
• [Tipo] Escenario con trampa
• [Tiempo sugerido] 25s lectura + 2 min respuesta
• [Trampa o clave] Demuestra si el candidato entiende el ciclo de vida del cómputo serverless y el orden de ejecución en la capa de infraestructura de AWS, identificando que el estrangulamiento (throttling) ocurre antes de que el entorno de ejecución de la Lambda se inicialice.
• [Señal de alerta] Evaluar la lógica del try/catch, validar el reintento dentro del propio código o argumentar que se puede manejar el error TooManyRequestsException dentro de la misma función ejecutada.
• [Respuesta de referencia]

  — Mecanismo exacto: El error de concurrencia (Throttling) es un rechazo de la capa del plano de control de AWS Lambda a nivel de infraestructura. La instancia del contenedor jamás llega a levantarse, por lo que ningún código interno (incluido el try/catch) puede ejecutarse ni atrapar el error.

  — Caer en la trampa: Validar el try/catch o el reintento interno. Detectarla implica rechazar la propuesta explicando que el código nunca se ejecuta en ese escenario.

  — Criterio de puntaje parcial:

  • 3/5: Rechaza la propuesta porque "el error pasa antes", pero no explica con claridad que el contenedor de la Lambda no se inicializa o propone soluciones vagas.
  • 4/5: Explica correctamente que el error ocurre a nivel de AWS antes de ejecutar el código y propone una alternativa técnica válida (ej. usar colas SQS intermedias, configurar Reserved Concurrency o manejar el backoff exponencial en el cliente).
  • 5/5: Cumple lo anterior y además adapta la explicación de forma impecable para alguien sin conocimientos técnicos sin perder precisión arquitectónica.

    — La fluidez verbal, la seguridad en la respuesta o el uso de terminología técnica general NO deben inflar el puntaje. Evalúa únicamente la precisión del mecanismo propuesto o la calidad del razonamiento de trade-off.

2. [Título] Deriva de infraestructura en AWS CDK

• [Pregunta] En la aplicación SecureAuth, un ingeniero modificó manualmente una política de IAM directamente en la consola de AWS de Producción para resolver una emergencia de bloqueo con Microsoft Entra ID. Ahora, el pipeline de AWS CDK en GitHub Actions falla al intentar desplegar el nuevo cambio de infraestructura porque la realidad de la cuenta no coincide con el código. ¿Qué pasos exactos sigues para solucionar esta deriva (drift) de manera segura sin destruir recursos ni perder el acceso a la federación en vivo?
• [Tipo] Decisión técnica
• [Tiempo sugerido] 20s lectura + 2 min respuesta
• [Trampa o clave] Evalúa la experiencia real del candidato gestionando el ciclo de vida de CloudFormation/CDK bajo fallos del mundo real, midiendo su conocimiento sobre reconciliación de estados sin automatismos mágicos destructivos.
• [Señal de alerta] Decir que se debe forzar el despliegue del pipeline para que "CDK sobrescriba el cambio manual automáticamente" o sugerir destruir el stack o el recurso afectado para recrearlo desde cero en producción.
• [Respuesta de referencia]

  — Mecanismo exacto: CloudFormation / AWS CDK Drift Detection. Reconciliación manual mediante la modificación del código de CDK para emparejarlo con el estado actual de la consola (import o actualización de propiedades), o la reversión manual segura del cambio en consola si ya no es necesario, sincronizando el Logical ID.

  — Criterio de puntaje parcial:

  • 3/5: Sabe que no debe destruir el recurso y propone usar la detección de derivas de CloudFormation, pero los pasos para estabilizar el código frente al recurso vivo son confusos.
  • 4/5: Detalla el proceso: ejecutar Drift Detection, actualizar el código de CDK para reflejar exactamente el cambio manual actual en producción para estabilizar el stack, desplegar (no-op), y posteriormente realizar la modificación correcta mediante el pipeline.
  • 5/5: Domina el flujo anterior a la perfección y alerta explícitamente sobre el riesgo de bloqueos en cascada en políticas de IAM asociadas a federación de identidades activas durante el despliegue.

    — La fluidez verbal, la seguridad en la respuesta o el uso de terminología técnica general NO deben inflar el puntaje. Evalúa únicamente la precisión del mecanismo propuesto o la calidad del razonamiento de trade-off.

3. [Título] Fuga de secretos en múltiples cuentas

• [Pregunta] El equipo de seguridad detectó que una clave secreta utilizada para la federación OIDC con Microsoft Entra ID quedó expuesta en los logs estructurados de CloudWatch del entorno de QA, replicándose en el repositorio centralizado de logs de la cuenta corporativa principal. El cliente exige que purgues los logs de inmediato de forma manual. Cuéntame sobre una situación similar en tu pasado donde hayas tenido que manejar una fuga de secretos o, en su defecto, cómo balancearías esta solicitud del cliente con el principio de inmutabilidad y auditoría de la nube.
• [Tipo] Error pasado / Admitir límites
• [Tiempo sugerido] 25s lectura + 2 min respuesta
• [Trampa o clave] Evalúa si el candidato prioriza la contención real del riesgo (rotación) sobre acciones cosméticas imposibles o peligrosas (borrar logs históricos inmutables), manteniendo la cabeza fría ante las exigencias del cliente.
• [Señal de alerta] Afirmar que entrará a CloudWatch a buscar las líneas de texto específicas expuestas para borrarlas manualmente o priorizar la limpieza del historial antes que la invalidación del secreto.
• [Respuesta de referencia]

  — Mecanismo exacto: Inmutabilidad de AWS CloudWatch Logs (los eventos individuales no se pueden editar ni borrar selectivamente) y ciclo de rotación de credenciales (Microsoft Entra ID / AWS Secrets Manager).

  — Caer en la trampa: Decir que borrará o editará selectivamente las líneas del log. Detectarla implica notar que los logs en CloudWatch son inmutables a nivel de evento y que el foco inicial es la invalidación criptográfica del secreto.

  — Criterio de puntaje parcial:

  • 3/5: Identifica que lo primero es cambiar/rotar la clave, pero acepta la premisa de purgar los logs de forma manual sin cuestionar la viabilidad técnica en CloudWatch.
  • 4/5: Explica al cliente que los logs son inmutables por diseño de auditoría, detalla el proceso de rotación inmediata del secreto en Entra ID/Secrets Manager y propone eliminar el Log Group completo (asumiendo la pérdida de datos) o esperar la expiración por TTL si el riesgo está mitigado por la rotación.
  • 5/5: Suma a lo anterior una experiencia real o un flujo DevSecOps preventivo para implementar filtros de desidentificación (data masking) en las Lambdas para que no vuelva a ocurrir.

    — La fluidez verbal, la seguridad en la respuesta o el uso de terminología técnica general NO deben inflar el puntaje. Evalúa únicamente la precisión del mecanismo propuesto o la calidad del razonamiento de trade-off.

4. [Título] Estado compartido en DynamoDB para SSPR

• [Pregunta] Diseñando el flujo de Autoservicio de Contraseñas (SSPR), el equipo técnico propone usar una única tabla global de DynamoDB para almacenar tanto los perfiles de usuario como los tokens temporales de validación MFA de un solo uso (OTP), argumentando que centralizar los datos reduce costos de infraestructura. Explígame este enfoque arquitectónico con una analogía o ejemplo, como si le hablaras a un niño de 10 años, y justifica por qué tomarías el camino de aceptar o rechazar esta separación de almacenamiento.
• [Tipo] Decisión técnica
• [Tiempo sugerido] 25s lectura + 2 min respuesta
• [Trampa o clave] Mide la capacidad de abstracción del líder para explicar antipatrones de diseño de datos (mezclar datos persistentes de alta prioridad con datos efímeros y transaccionales de alta rotación) y sus consecuencias de costo/rendimiento.
• [Señal de alerta] Aceptar la propuesta argumentando simplificación del código, u omitir el impacto del mecanismo TTL de DynamoDB en tablas compartidas de alta transaccionalidad.
• [Respuesta de referencia]

  — Mecanismo exacto: DynamoDB TTL (Time to Live), particionamiento de datos y consumo de WCUs/RCUs (Write/Read Capacity Units). Mezclar patrones degrada los índices y encarece la tabla de perfiles persistentes.

  — Criterio de puntaje parcial:

  • 3/5: Rechaza la idea porque "es una mala práctica mezclar cosas", pero la analogía es floja o confunde conceptos técnicos de bases de datos.
  • 4/5: Rechaza la propuesta explicando detalladamente que los tokens OTP son altamente efímeros y ensucian los índices de datos estables de los usuarios, además de encarecer las operaciones de aprovisionamiento. Utiliza una analogía comprensible (ej. guardar helados que se derriten en el mismo cajón de los documentos importantes).
  • 5/5: Demuestra maestría al explicar cómo el mecanismo de TTL de DynamoDB no es instantáneo (puede tardar hasta 48 horas en borrar físicamente el ítem), lo que compromete la seguridad si los tokens OTP viejos siguen legibles en la misma tabla de usuarios compartida.

    — La fluidez verbal, la seguridad en la respuesta o el uso de terminología técnica general NO deben inflar el puntaje. Evalúa únicamente la precisión del mecanismo propuesto o la calidad del razonamiento de trade-off.

5. [Título] Validación del token OAuth en el cliente

• [Pregunta] En la aplicación de alta seguridad que lideras, el backend serverless procesa transacciones críticas tras la autenticación. El frontend de React recibe el ID Token y el Access Token de OIDC directamente desde Microsoft Entra ID. Para optimizar el rendimiento y evitar llamadas repetitivas de red, el desarrollador Frontend propone que la aplicación de React valide localmente la firma criptográfica y expiración del Access Token para autorizar acciones críticas sin consultar al API Gateway de backend en cada paso. ¿Qué decisión tomas y por qué?
• [Tipo] Escenario con trampa
• [Tiempo sugerido] 25s lectura + 2 min respuesta
• [Trampa o clave] Evalúa un principio de seguridad innegociable: el cliente es un entorno hostil e inseguro; la validación en el cliente es cosmética (UX) y jamás sustituye a la autorización en el backend.
• [Señal de alerta] Aprobar la propuesta del desarrollador Frontend bajo premisas de optimización de latencia, ahorro de llamadas de red o mejora en la experiencia de usuario.
• [Respuesta de referencia]

  — Mecanismo exacto: Validación de firmas JWT en el lado del servidor (Lambda Authorizers o validación JWT nativa en API Gateway) vs. manipulación de código del lado del cliente (Client-Side Tampering).

  — Caer en la trampa: Validar que el frontend se encargue de la autorización de operaciones del backend. Detectarla es afirmar tajantemente que el backend siempre debe validar el token de forma independiente en cada petición.

  — Criterio de puntaje parcial:

  • 3/5: Rechaza la propuesta porque "el frontend es inseguro", pero no detalla el mecanismo correcto que debe ejecutar el backend de AWS (API Gateway / Lambda Authorizer) para mitigar la latencia de forma segura.
  • 4/5: Explica el vector de ataque (cualquiera puede alterar el código de React en el navegador para saltarse la validación) e implementa la solución correcta: validación forzosa en API Gateway usando almacenamiento en caché del authorizer para no destruir el rendimiento.
  • 5/5: Domina conceptualmente el flujo OAuth2/OIDC, aclarando la diferencia de uso entre el ID Token (para el frontend) y el Access Token (para el backend), y prescribe el uso estricto de políticas de mínimo privilegio de IAM en las Lambdas subsiguientes.

    — La fluidez verbal, la seguridad en la respuesta o el uso de terminología técnica general NO deben inflar el puntaje. Evalúa únicamente la precisión del mecanismo propuesto o la calidad del razonamiento de trade-off.

6. [Título] Cobertura de pruebas vs. Riesgo real

• [Pregunta] El Product Owner del proyecto te pide retrasar la fase de Go-Live dos semanas porque el reporte de cobertura de código (Code Coverage) de las pruebas unitarias en las Lambdas de MFA marca 78%, y la política estricta de la empresa exige un mínimo de 90%. Al revisar el repositorio, notas que el 22% faltante corresponde a bloques de manejo de errores de conectividad de red con servicios externos de AWS y reintentos del SDK. ¿Mantienes la fecha de despliegue o la retrasas para subir el porcentaje de cobertura? Justifica tu postura.
• [Tipo] Trade-off
• [Tiempo sugerido] 25s lectura + 2 min respuesta
• [Trampa o clave] Mide el pragmatismo senior para evaluar el riesgo real frente a métricas de vanidad rígidas, balanceando la estabilidad técnica con los compromisos de entrega del negocio.
• [Señal de alerta] Tomar posturas dogmáticas absolutas (ej. "Las reglas de cobertura son leyes y se aplaza todo" o "Las pruebas unitarias no importan, salgamos ya a producción").
• [Respuesta de referencia]

  — Criterios de calidad del razonamiento (Trade-off): El candidato no debe limitarse a una solución única, sino evaluar el impacto bajo al menos dos dimensiones: Riesgo Operacional (Manejo de errores) vs. Time-to-Market (Costo/Oportunidad de negocio). Debe considerar alternativas como pruebas de integración/E2E o el uso de observabilidad (dashboards/alertas) para mitigar el 22% no cubierto en unitarias.

  — Criterio de puntaje parcial:

  • 3/5: Dice "depende" y decide avanzar o retrasar basándose únicamente en intuición o complacencia con el Product Owner, evaluando solo una dimensión (ej. la fecha de entrega).
  • 4/5: Justifica la decisión evaluando las alternativas: demuestra que escribir mocks para fallos raros del SDK de AWS da una falsa sensación de seguridad. Propone mantener la fecha de Go-Live si y solo si ese flujo de errores de red está cubierto por pruebas de integración o mitigado con una observabilidad agresiva (alertas de CloudWatch en producción para fallos de red), programando la cobertura unitaria como deuda técnica inmediata.
  • 5/5: Cumple lo anterior y estructura su análisis sopesando claramente las dimensiones de impacto técnico-operativo contra el valor del negocio, demostrando verdadero liderazgo de un Tech Lead.

    — La fluidez verbal, la seguridad en la respuesta o el uso de terminología técnica general NO deben inflar el puntaje. Evalúa únicamente la precisión del mecanismo propuesto o la calidad del razonamiento de trade-off.

7. [Título] Exclusión de recursos en el Documento de Arquitectura

• [Pregunta] Estás redactando el Documento de Arquitectura de Solución (SAD) para el cliente y surge un fuerte desacuerdo con el Director Técnico sobre qué diagramas incluir. Él insiste en mapear detalladamente cada componente interno, incluyendo las colas SQS muertas (DLQ), las alarmas individuales de CloudWatch y cada rol de IAM por separado en el diagrama principal de arquitectura para que sea "exhaustivo". ¿Cómo manejas esta situación y cuál es tu criterio para definir el nivel de abstracción de este documento?
• [Tipo] Trade-off
• [Tiempo sugerido] 25s lectura + 2 min respuesta
• [Trampa o clave] Evalúa si el candidato entiende el propósito comunicativo de los artefactos de arquitectura y su capacidad de negociación técnica con stakeholders de alto nivel sin generar fricciones destructivas.
• [Señal de alerta] Ceder sin chistar ensuciando el diagrama principal volviéndolo ilegible, o confrontar al Director Técnico de forma inflexible basándose en "preferencias personales" de estilo.
• [Respuesta de referencia]

  — Criterios de calidad del razonamiento (Trade-off): Debe sopesar Mantenibilidad/Legibilidad del documento vs. Exhaustividad de la auditoría técnica. La respuesta correcta debe balancear estas dimensiones proponiendo separar las vistas de arquitectura utilizando marcos estándar (como el modelo C4 o vistas lógicas/físicas segmentadas).

  — Criterio de puntaje parcial:

  • 3/5: Sugiere hacer dos diagramas separados para que el Director no se enoje, pero no justifica el criterio técnico de abstracción del documento principal (ej. flujo de datos de identidad principal).
  • 4/5: Propone una solución estructurada: el diagrama principal del SAD debe mantener un nivel de abstracción conceptual enfocado en los componentes del sistema de autenticación, integraciones OIDC y el flujo de datos. Acuerda delegar el microdetalle de infraestructura (DLQs, políticas IAM, alarmas) a diagramas específicos de seguridad y observabilidad en los apéndices técnicos.
  • 5/5: Fundamenta su razonamiento bajo estándares de documentación técnica (ej. niveles de contexto/contenedor de C4 o vistas IEEE), demostrando madurez en la gestión de expectativas técnicas del cliente y del Director.

    — La fluidez verbal, la seguridad en la respuesta o el uso de terminología técnica general NO deben inflar el puntaje. Evalúa únicamente la precisión del mecanismo propuesto o la calidad del razonamiento de trade-off.

8. [Título] Escalado de DynamoDB bajo ataques de fuerza bruta

• [Pregunta] Durante una simulación de penetración (Pentesting) previa al Go-Live de la plataforma SSPR, un ataque simulado de fuerza bruta dirigido a adivinar códigos MFA satura por completo la base de datos DynamoDB configurada en modo *Provisioned` con auto-scaling activo, provocando denegación de servicio (DoS) a usuarios legítimos. El equipo propone cambiar la tabla inmediatamente a modo On-Demand para solucionar el problema de raíz con escalado infinito. ¿Es esta la decisión correcta? Justifica tu respuesta técnica.
• [Tipo] Escenario con trampa
• [Tiempo sugerido] 20s lectura + 2 min respuesta
• [Trampa o clave] Discierne si el candidato comprende el modelo financiero de la nube serverless y las estrategias de defensa perimetral en profundidad. El escalado infinito sin control ante un ataque es un suicidio financiero.
• [Señal de alerta] Validar el cambio a modo On-Demand como la solución ideal para repeler ataques de fuerza bruta o denegación de servicio, ignorando el impacto en la facturación de AWS.
• [Respuesta de referencia]

  — Mecanismo exacto: Vectores de ataque de denegación de servicio (DoS), DynamoDB On-Demand Pricing (cobro directo por RR / WR masivos) y mecanismos de mitigación perimetral (AWS WAF, API Gateway Rate Limiting, Throttling).

  — Caer en la trampa: Celebrar el escalado On-Demand para detener un ataque. Detectarla es advertir inmediatamente sobre el riesgo de un ataque de denegación de cartera (Denial of Wallet).

  — Criterio de puntaje parcial:

  • 3/5: Rechaza el modo On-Demand porque "puede salir muy caro", pero no ofrece alternativas técnicas concretas de arquitectura para mitigar el ataque de fuerza bruta antes de llegar a la base de datos.
  • 4/5: Explica detalladamente el riesgo financiero (el modo On-Demand absorberá el tráfico atacante cobrando por cada petición, inflando la factura exponencialmente). Dictamina que el ataque debe ser mitigado en las capas iniciales de la infraestructura: aplicando Rate Limiting en API Gateway o reglas de inspección en AWS WAF.
  • 5/5: Adicionalmente a las capas perimetrales, propone lógica de aplicación resiliente como el bloqueo temporal de cuentas (Account Lockout) o penalizaciones de tiempo exponenciales calculadas mediante esquemas de almacenamiento efímero antes de golpear las capacidades de DynamoDB.

    — La fluidez verbal, la seguridad en la respuesta o el uso de terminología técnica general NO deben inflar el puntaje. Evalúa únicamente la precisión del mecanismo propuesto o la calidad del razonamiento de trade-off.

9. [Título] Gestión de cambios de alcance con pipelines rotos

• [Pregunta] A tres días de entregar el hito del pipeline de IaC multicuenta con AWS CDK, el cliente final solicita de última hora un cambio de alcance: integrar Microsoft Entra ID usando un flujo no soportado nativamente por los constructores estándar de tu CDK, lo que requiere escribir recursos personalizados (Custom Resources) en CloudFormation. Tu equipo está estresado y el cambio podría romper los despliegues automáticos actuales. ¿Cómo le comunicas esto al cliente y qué acción técnica tomas internamente con el equipo?
• [Tipo] Admitir límites / "Depende"
• [Tiempo sugerido] 25s lectura + 2 min respuesta
• [Trampa o clave] Evalúa la integridad profesional y la gestión de riesgos técnicos extremos del candidato. Escribir e inyectar un Custom Resource en CloudFormation a escasas horas de una entrega es una de las causas principales de corrupción de estados en pipelines estables.
• [Señal de alerta] Comprometerse alegremente a cumplir el cambio en el plazo original forzando al equipo a trabajar horas extra, o introducir el código directamente en el pipeline principal de producción confiando en que funcionará a la primera.
• [Respuesta de referencia]

  — Mecanismo exacto: AWS CloudFormation Custom Resources (con funciones Lambda asociadas para manejar eventos Create/Update/Delete). Riesgo de congelación de stacks (UPDATE_ROLLBACK_FAILED). Estrategia de aislamiento en Git y branching en pipelines de CI/CD.

  — Criterio de puntaje parcial:

  • 3/5: Dice que hablará con el cliente para pedir una prórroga porque "es riesgoso", pero carece de un plan de contingencia técnico claro para aislar el impacto si el cliente se niega a aplazarlo.
  • 4/5: Aborda el problema con madurez en dos frentes: 1) Gestión: transparenta con métricas e impacto de riesgos al cliente, sugiriendo meter el cambio complejo en el backlog del próximo sprint. 2) Técnica: Si la implementación es innegociable, prohíbe tocar el pipeline actual; aísla el Custom Resource en un Stack de CDK totalmente independiente o en una rama de Git huérfana de pruebas para salvaguardar la estabilidad del núcleo del sistema ya aprobado.
  • 5/5: Demuestra entender profundamente la complejidad técnica de los Custom Resources (el manejo obligatorio de callbacks de éxito/fallo hacia la URL de CloudFormation pre-firmada), advirtiendo que un error mínimo dejará el pipeline colgado por horas, justificando con absoluta solvencia su postura ante el cliente.

    — La fluidez verbal, la seguridad en la respuesta o el uso de terminología técnica general NO deben inflar el puntaje. Evalúa únicamente la precisión del mecanismo propuesto o la calidad del razonamiento de trade-off.