Aprobé el Exam Lab "AWS Serverless Demostrado" y acá te cuento todo lo que rompí en el camino
Soy Roxs 👩💻| Software Developer | DevOps | DevSecOps | en @295DevOps 🖼 Content Creator. No se puede crecer si no estas dispuesto a saltar a la zona de peligro 🔥
Hay una diferencia enorme entre saber cómo funciona algo en teoría y tener que arreglarlo cuando está roto, en producción, con un timer corriendo.
Eso es exactamente lo que propone el Exam Lab "AWS Serverless Demostrado" de AWS Skill Builder: una arquitectura de e-commerce serverless preconfigurada, parcialmente rota, y 7 desafíos para dejarla funcionando. Sin múltiple choice. Sin trampa. Solo vos, la consola de AWS, y el CLI.
Acá te cuento qué aprendí, qué me trabó, y por qué recomiendo hacer este tipo de evaluaciones si querés validar skills reales.
La arquitectura del lab
Antes de hablar de los desafíos, hay que entender qué se estaba evaluando. La arquitectura era un e-commerce serverless completo:
Frontend: CloudFront + S3
Autenticación: Amazon Cognito
API: API Gateway con integración Lambda proxy
Backend: Lambda functions (Python y Node.js) para productos, carrito, pedidos y notificaciones
Base de datos: DynamoDB (ProductTable, CartTable, OrderTable)
Orquestación: AWS Step Functions para el flujo de pedidos
CI/CD: CodePipeline + CodeBuild
Seguridad: AWS WAF + Cognito Authorizer
Mensajería: SNS + SQS para notificaciones y manejo de errores
Todo esto junto. Todo parcialmente roto. 7 desafíos para arreglarlo.
Los 7 desafíos qué había que hacer y qué aprendí
A — Establecer límites de red VPC para funciones Lambda
El primer desafío pedía mover getProduct_function y manageCart_function dentro de una VPC, usando subnets privadas y un security group específico (sg-xxxxxxxxxxxxxx).
Lo que aprendí: cuando una Lambda entra a una VPC, pierde acceso a internet por defecto. Si necesita salir, necesitás NAT Gateway o VPC Endpoints. En este caso, con DynamoDB como destino, un VPC Endpoint es la solución más limpia y económica.
B — Crear un pipeline de CI/CD para actualizar la Lambda dañada
Este desafío tenía varios pasos: revisar el pipeline existente en CodePipeline, agregar una etapa de Manual Approval con un SNS topic para notificar al equipo de Ops, preparar el source.zip con la estructura correcta (src/ + buildspec.yml) y subirlo al bucket S3 para disparar el pipeline.
Lo que aprendí: la etapa de Manual Approval en CodePipeline es más poderosa de lo que parece. Podés requerir un comentario obligatorio al aprobar (Require approval summary: True), lo que crea un audit trail natural para deployments en producción.
C — Arreglar la configuración de Amazon API Gateway
La API estaba sin recursos. Había que crear tres endpoints desde cero:
| Recurso | Métodos | Lambda |
|---|---|---|
/products |
GET | getProduct_function |
/cart |
GET, POST | manageCart_function |
/place-order |
POST | placeOrder_function |
Todo con integración Lambda Proxy y CORS habilitado en cada recurso.
El error más común: olvidarse de hacer el Deploy a la etapa prod después de los cambios. Los cambios en API Gateway no se aplican hasta que deployás.
D — Arreglar la configuración de Amazon Cognito
Los usuarios que se registraban no recibían emails de confirmación de suscripción al SNS topic. El problema: el Lambda trigger no estaba configurado.
Había que agregar subscribeSNS_function como Post Confirmation trigger en el User Pool de Cognito.
E — Implementar seguridad con AWS WAF y Cognito Authorizer
Doble capa de seguridad:
Cognito Authorizer en API Gateway: token source
Authorization, integrado conecommerce-user-pool. Se adjunta a cada método de la API.Web ACL en AWS WAF con dos managed rules gratuitas:
AWSManagedRulesAmazonIpReputationListAWSManagedRulesAnonymousIpList
Asociada al stage prod de API Gateway.
Lo que aprendí: WAF puede tardar 3-5 minutos en propagar los cambios. Si hacés el Check inmediatamente después de configurar, puede fallar. Esperá antes de comprobar.
F — Arreglar la funcionalidad del carrito
El carrito no persistía entre recargas de página. La razón: la tabla CartTable no existía en DynamoDB. Solo existía ProductTable.
Solución: crear la tabla con username como partition key y configurar la variable de entorno CART_TABLE=CartTable en manageCart_function.
Lo que aprendí: siempre verificar que las tablas DynamoDB existen antes de debuggear el código. aws dynamodb list-tables es el primer comando a correr en este tipo de problemas.
G — Arreglar el sistema de realizar pedidos (el más complejo)
Este fue el desafío más profundo del lab. Tenía múltiples capas de problemas:
Problema 1 — OrderTable inexistente: igual que con CartTable, la tabla de órdenes no existía.
Problema 2 — Step Functions sin manejo de errores: la state machine order-processing-state-machine tenía tres estados (OrderUpdate, SendNotification, SendFullfillment) pero ninguno tenía Catch. Había que:
Agregar
CatchconStates.ALLen cada estado apuntando a un nuevo estadoSendErrorToSQSCrear una cola SQS
order-errors-queuepara capturar los erroresEliminar el
ResultSelectorque estaba descartando el input entre estadosUsar
ResultPathpara preservar el contexto original del pedido
Problema 3 — El payload vacío: este me tuvo un buen rato. La Lambda orderUpdate_function recibía {} como evento. La causa raíz: el ResultSelector: {"Payload.\(": "\).Payload"} en el ASL estaba reemplazando todo el input del estado con solo el payload de la respuesta Lambda anterior — que en el primer estado era vacío porque venía directo de placeOrder_function.
La solución fue reemplazar ResultSelector por ResultPath: "$.orderUpdateResult", que guarda el resultado del estado sin pisar el input original.
Problema 4 — SNS topic equivocado en sendNotification_function: la función tenía configurado el topic de ops-deployment-approval (el del pipeline) en vez del topic de notificaciones a clientes.
Lo que aprendí: en Step Functions, la diferencia entre ResultSelector, ResultPath y OutputPath es crítica. Un error ahí y el contexto se pierde entre estados sin ningún mensaje de error obvio.
El error que más me hizo perder tiempo
Sin dudas: el payload vacío en orderUpdate_function.
Pasé varios intentos cambiando el código de la Lambda (agregando while 'Payload' in payload, manejando múltiples niveles de anidamiento, etc.) cuando el problema real estaba en el ASL de Step Functions. El ResultSelector estaba descartando todo el contexto.
La lección: cuando una Lambda recibe datos inesperados en un flujo orquestado, el primer lugar donde mirar es la definición de la state machine, no el código de la función.
Resultado final
¿Por qué recomiendo hacer Exam Labs?
Los Exam Labs de AWS Skill Builder son distintos a cualquier otra certificación que hayas hecho. No memorizás respuestas. No adivinás entre opciones. Tenés que hacer funcionar la arquitectura.
Eso implica:
Leer CloudWatch Logs cuando algo falla
Entender la diferencia entre un error en el código y un error en la configuración
Saber qué comando correr para diagnosticar antes de cambiar algo
Trabajar con un timer — porque en producción los problemas tampoco esperan
Si trabajás en plataformas, DevOps, o cualquier rol que toque AWS, este formato te va a enseñar más en 2 horas que una semana de tutoriales.
Stack de comandos que más usé
# Diagnóstico rápido de Lambdas
aws logs tail /aws/lambda/FUNCION --follow
# Ver qué tablas existen
aws dynamodb list-tables
# Ver variables de entorno de una Lambda
aws lambda get-function-configuration \
--function-name FUNCION \
--query 'Environment.Variables'
# Ver ejecuciones de Step Functions
aws stepfunctions list-executions \
--state-machine-arn ARN \
--status-filter FAILED
# Ver el input de una ejecución
aws stepfunctions describe-execution \
--execution-arn ARN \
--query 'input'
El badge 🏅
Esto es el primero de 4 y todos están disponibles ahora
AWS tiene una serie de Exam Labs de microcredenciales que podés hacer hoy mismo. Cada uno es un escenario , hands-on, con tiempo limitado y badge al finalizar:
| # | Microcredencial | Link |
|---|---|---|
| 1 | 🧪 AWS Serverless Demonstrated ✅ | Ir al lab |
| 2 | 🌐 AWS Application Networking Demonstrated | Ir al lab |
| 3 | 🤖 AWS Agentic AI Demonstrated | Ir al lab |
| 4 | 🚨 AWS Incident Response Demonstrated | Ir al lab |
Cada lab cubre un área distinta:
Serverless → deploy, debug y optimización de apps serverless en AWS
Application Networking → redes y arquitectura en acción real
Agentic AI → construir y operar soluciones de IA con agentes autónomos
Incident Response → responder a incidentes como en producción
Modo Roxs 🔥
Hoy no gana quien más estudia.
Gana quien resuelve.
👉 Saber AWS ≠ usar AWS
👉 Usar AWS en escenarios = VALOR real en tu perfil
La diferencia entre alguien que "conoce Lambda" y alguien que debuggeó una state machine de Step Functions con el payload vacío a las 10 de la noche no está en el CV. Está en el badge. Está en la experiencia. Está en que la próxima vez que pase en producción, ya sabés exactamente qué comando correr.
Tu desafío
Elegí UNA microcredencial de las 4 y metele esta semana.
No mañana. Esta semana.
Después quiero ver ese badge en tu perfil. 😏
→ Empezá por AWS Serverless Demonstrated si querés seguir mis pasos, o elegí la que más se acerque a tu stack actual.
