Este desafío técnico evalúa tus habilidades en arquitectura cloud, containerización y CI/CD a través de tres pruebas prácticas que simulan escenarios reales de producción en entornos empresariales.
Tiempo estimado: 5-7 días
Diseñar una arquitectura de red completa para una aplicación web moderna desplegada en AWS o GCP.
La aplicación debe soportar:
- ✅ Cargas variables con auto-scaling
- ✅ Alta Disponibilidad (HA) - Multi-AZ o Multi-Region
- 🎨 Frontend en JavaScript (React, Vue, Angular, etc.)
- ⚙️ Backend con:
- Base de datos relacional (PostgreSQL, MySQL, etc.)
- Base de datos no relacional (MongoDB, DynamoDB, etc.)
- 🔌 Consumo de 2 microservicios externos (APIs de terceros)
El diagrama debe:
- Hacer el mejor uso de soluciones distribuidas
- Implementar mejores prácticas de seguridad (redes privadas, bastión hosts, security groups)
- Incluir balanceadores de carga
- Considerar CDN para contenido estático
- Implementar estrategias de backup y recuperación
- Mostrar zonas de disponibilidad y subnets
-
Diagrama de Red
- Formato: Lucidchart, Draw.io, Cloudcraft o similar
- Debe mostrar claramente todos los componentes y sus conexiones
- Incluir flujos de tráfico y comunicación entre servicios
-
Documento Descriptivo (½ a 1 página)
- Justificación de las decisiones arquitectónicas
- Explicación de cómo se logra alta disponibilidad
- Estrategia de escalabilidad
- Consideraciones de seguridad
- Estimación aproximada de costos (opcional)
Elaborar el deployment completamente dockerizado de la aplicación AWS Retail Store Sample App.
Repositorio de la aplicación:
https://github.com/aws-containers/retail-store-sample-app
La AWS Retail Store es una aplicación de ejemplo que simula una tienda online con arquitectura de microservicios:
| Componente | Tecnología | Descripción |
|---|---|---|
| UI | Java (Spring Boot) | Interfaz web de la tienda |
| Catalog | Go | API del catálogo de productos |
| Cart | Java (Spring Boot) | API de carritos de compra |
| Orders | Java (Spring Boot) | API de gestión de órdenes |
| Checkout | Node.js | Orquestación del proceso de pago |
| Assets | Nginx | Servidor de archivos estáticos |
-
Todos los servicios en un solo docker-compose
- Debe incluir todas las dependencias (bases de datos, cache, etc.)
- Debe poder levantarse con un solo comando
- Networking apropiado entre contenedores
-
Dockerfiles pertinentes
- Un Dockerfile por cada componente
- Optimizados con multi-stage builds
- Imágenes lo más ligeras posible
- Health checks configurados
-
Justificación de la estrategia de deployment
- Explicar por qué se eligió docker-compose vs otras opciones
- Comparar con alternativas: Kubernetes, Docker Swarm, supervisor, systemd, etc.
- Ventajas y desventajas de la solución propuesta
Repositorio Git (GitHub, GitLab o Bitbucket) que contenga:
-
Código de la aplicación (puede ser fork del repositorio original)
-
Dockerfiles para cada servicio
-
docker-compose.yml completo y funcional
-
README.md con instrucciones detalladas para:
- Compilar la aplicación
- Desplegar en PC local (Linux/Mac/Windows)
- Desplegar en la nube (AWS o GCP)
- Variables de entorno necesarias
- Prerequisitos y dependencias
- Troubleshooting común
-
Documentación adicional (opcional pero recomendado):
- Diagrama de arquitectura del deployment
- Scripts de automatización
- Configuraciones de infraestructura (Terraform, CloudFormation)
- ✅ Completitud: todos los servicios funcionando
- 🚀 Facilidad de uso: simplicidad del proceso de deployment
- 📚 Calidad de documentación
- 🔧 Optimización de imágenes Docker
- 🔒 Manejo de secrets y configuraciones
- 🏗️ Arquitectura del deployment
Elaborar un pipeline de CI/CD completo que automatice el build y deployment de un contenedor Nginx.
Dockerizar un Nginx con el index.html por defecto.
El pipeline debe activarse automáticamente ante cada cambio realizado sobre el index.html y:
- Validar el código (linting, tests básicos)
- Construir la nueva imagen Docker
- Etiquetar la imagen apropiadamente (versioning)
- Ejecutar security scans
- Publicar la imagen en un registry (Docker Hub, ECR, GCR)
- Actualizar la aplicación en la plataforma elegida
- Verificar el deployment
CI/CD:
- GitLab CI/CD
- GitHub Actions
- CircleCI
- Bitbucket Pipelines
- Jenkins
- Otra de tu elección
Deployment Target:
- Docker Compose
- Kubernetes
- Docker Swarm
- AWS ECS/Fargate
- GCP Cloud Run
- Azure Container Instances
- Otra plataforma de contenedores
Obligatorios:
- ✅ Automatización completa (trigger en push)
- ✅ Build de imagen Docker
- ✅ Versionado de imágenes
- ✅ Push a registry
- ✅ Deployment automatizado
- ✅ Zero-downtime deployment
Deseables:
- 🔒 Security scanning (Trivy, Snyk, etc.)
- 🧪 Tests automatizados
- 📊 Health checks post-deployment
- 🔔 Notificaciones (Slack, Email)
- ⏮️ Rollback automático en caso de fallo
- 🎯 Deploy a múltiples ambientes (dev, staging, prod)
Repositorio Git que incluya:
-
Código fuente
index.htmlDockerfile- Configuración de Nginx (si aplica)
-
Configuración del Pipeline
.gitlab-ci.ymlo.github/workflows/*.ymlo equivalente- Scripts de deployment
- Scripts de testing/validación
-
Infrastructure as Code (opcional)
- Manifiestos de Kubernetes
- Configuración de Terraform
- CloudFormation templates
- Helm charts
-
README.md detallado que explique:
- Arquitectura del pipeline
- Cómo funciona cada stage
- Variables de entorno y secrets necesarios
- Cómo replicar el setup
- Estrategia de deployment elegida
- Diagrama de flujo del CI/CD
Debes poder demostrar:
- El pipeline ejecutándose automáticamente
- Un cambio en
index.htmlsiendo desplegado - La aplicación actualizada corriendo
- Rollback en caso de fallo (opcional)
- 🏗️ Arquitectura: Diseño escalable y mantenible
- 💻 Código: Calidad, organización y buenas prácticas
- 🔒 Seguridad: Manejo de secrets, principio de mínimo privilegio
- 🚀 Automatización: Nivel de automatización alcanzado
- 📦 Containerización: Optimización de imágenes y configuraciones
- 🔄 CI/CD: Robustez y completitud del pipeline
- 📊 Observabilidad: Logging, monitoring, health checks
- 🎯 IaC: Uso de Infrastructure as Code
- 🧪 Testing: Estrategia de pruebas automatizadas
- 📚 Claridad: Documentación clara y completa
- 🎨 Presentación: Profesionalismo en la entrega
- 💡 Justificación: Explicación de decisiones técnicas
- 🔍 Atención al detalle: Completitud de las soluciones
Los siguientes elementos no son obligatorios pero serán valorados positivamente:
- 🔐 GitOps: Implementación con ArgoCD o Flux
- 🌍 Multi-region: Deployment en múltiples regiones
- 📊 Observabilidad avanzada: Dashboards de Grafana, Datadog, etc.
- 🧪 Testing avanzado: Load testing, chaos engineering
- 💰 Cost optimization: Análisis y optimización de costos
- 🏆 Managed services: Uso inteligente de servicios cloud managed
- 🔄 Disaster Recovery: Plan de recuperación ante desastres
- 📱 Monitoring: Alertas y métricas configuradas
- 🎯 Advanced deployment: Blue/Green, Canary deployments
- Prueba 1: Puede ser un repositorio con el diagrama y documento, o links a Lucidchart/Draw.io
- Prueba 2: Repositorio completo con código y documentación
- Prueba 3: Repositorio completo con pipeline funcional
- ✅ README.md profesional y completo
- ✅ Commits descriptivos y organizados
- ✅ .gitignore apropiado
- ✅ Branching strategy clara (opcional)
- ✅ Sin secretos ni credenciales
Si se requiere presentación:
- 10-15 minutos explicando las soluciones
- Demo en vivo de deployments
- Q&A técnico
- Lee todo el desafío primero antes de comenzar
- Empieza simple: MVP primero, luego itera
- Documenta mientras trabajas: No dejes la documentación para el final
- Testea continuamente: Valida cada componente antes de avanzar
- Pregunta si tienes dudas: Es mejor preguntar que asumir incorrectamente
- Gestiona tu tiempo: No busques la perfección, busca funcionalidad
- Backup frecuente: Commitea y pushea regularmente
- AWS Well-Architected Framework
- Google Cloud Architecture Center
- Docker Best Practices
- Kubernetes Documentation
- 12-Factor App
- GitLab CI/CD Docs
- GitHub Actions Docs
P: ¿Puedo usar herramientas que no están mencionadas?
R: Sí, puedes usar cualquier herramienta que consideres apropiada, pero debes justificar tu elección.
P: ¿Necesito desplegar realmente en la nube o puede ser todo local?
R: Para la Prueba 2, debes proporcionar instrucciones para ambos casos (local Y cloud), pero el deployment real puede ser solo local si no tienes acceso a cloud.
P: ¿Cuánto tiempo tengo?
R: El tiempo recomendado es 5-7 días, pero puede variar según las indicaciones específicas.
P: ¿Puedo usar soluciones existentes o templates?
R: Puedes usar templates como base, pero debes demostrar que entiendes lo que estás implementando y adaptarlo a los requisitos específicos.
P: ¿Es necesario hacer las tres pruebas?
R: Sí, las tres pruebas son obligatorias salvo indicación contraria.
Para consultas o aclaraciones sobre el desafío, contactar a: [roxs.dev]
¡Buena suerte! 🚀
Este desafío está diseñado para evaluar habilidades reales de DevOps/SRE utilizadas en entornos de producción modernos.
Versión: 1.0
Última actualización: Diciembre 2025