DevOps - Junior | Evaluación Técnica

Información del candidato

Nombre completo

Email

Teléfono (opcional)

Años de experiencia

CV / Currículum Formatos aceptados: PDF, DOC, DOCX. Máximo 5MB

Preguntas de conocimiento

Este Dockerfile tiene varios problemas: `FROM ubuntu:latest RUN apt-get update RUN apt-get install -y python3 pip COPY . /app RUN pip install -r /app/requirements.txt CMD python3 /app/main.py`. ¿Cuáles son?

El único problema es que falta declarar `WORKDIR /app` antes del COPY, lo que causa que los paths relativos no funcionen correctamente en el contenedor

El problema principal es usar Ubuntu como imagen base en vez de Alpine, ya que Alpine es siempre más segura y rápida independientemente del caso de uso

Usa `latest` (no reproducible), capas innecesarias separadas (cada RUN crea capa), no usa multi-stage build, corre como root, no tiene `.dockerignore`, y no combina RUN para reducir capas

CMD debería ser ENTRYPOINT porque CMD no permite pasar argumentos al contenedor y ENTRYPOINT es la única forma correcta de definir el proceso principal

¿Cuál es la diferencia entre CMD y ENTRYPOINT, y entre COPY y ADD en Docker?

CMD define comando por defecto (sobrescribible al ejecutar). ENTRYPOINT define el ejecutable fijo (CMD pasa como argumentos). COPY solo copia archivos locales. ADD además descomprime tars y acepta URLs (pero se recomienda COPY por claridad)

Son pares de sinónimos completamente intercambiables mantenidos por retrocompatibilidad con versiones anteriores del formato Dockerfile

ENTRYPOINT es una directiva obsoleta que fue reemplazada por CMD en Docker 2.0 y no debería usarse en Dockerfiles modernos

ADD es más seguro que COPY porque valida checksums de los archivos copiados y previene la inclusión de archivos maliciosos en la imagen

¿Cuándo elegir EC2 vs ECS vs Lambda vs Fargate en AWS?

Siempre usar Lambda porque es más barato en todos los escenarios posibles y no tiene limitaciones de tiempo de ejecución ni de recursos disponibles

ECS y Fargate son exactamente el mismo servicio con diferente nombre comercial; AWS los mantiene separados solo por razones de marketing y facturación

Lambda puede ejecutar cualquier tipo de aplicación sin límites de tiempo, memoria o estado, reemplazando completamente la necesidad de contenedores o servidores

EC2: control total del servidor (apps legacy, GPU). ECS/Fargate: contenedores orquestados (Fargate = serverless containers sin gestionar instancias). Lambda: funciones cortas event-driven (<15min, sin estado). Elección según control necesario vs overhead operacional

¿Cuál es la diferencia entre Security Group y NACL (Network ACL) en AWS?

Son exactamente el mismo mecanismo de seguridad con diferente nombre, aplicados al mismo nivel de la infraestructura de red de AWS

Security Group: stateful (respuesta automática permitida), a nivel de instancia/ENI, solo reglas ALLOW. NACL: stateless (requiere reglas explícitas para entrada Y salida), a nivel de subnet, permite ALLOW y DENY, se evalúa por número de regla

NACL es siempre más seguro que Security Group en todos los escenarios porque opera a un nivel más bajo de la pila de red y filtra antes

Security Group solo funciona con instancias EC2 y no es compatible con ECS, Fargate, Lambda ni ningún otro servicio gestionado de AWS

¿Cuáles son los equivalentes de S3, Lambda y RDS en Azure?

S3 → Azure Files (almacenamiento de archivos), Lambda → Azure Virtual Machines (cómputo), RDS → CosmosDB (base de datos global distribuida)

S3 → Azure Queue Storage (colas de mensajes), Lambda → Azure Logic Apps (workflows), RDS → Azure Table Storage (NoSQL de clave-valor)

Azure no tiene servicios equivalentes a los de AWS; cada plataforma cloud tiene una arquitectura completamente diferente e incompatible

S3 → Azure Blob Storage, Lambda → Azure Functions, RDS → Azure SQL Database / Azure Database for PostgreSQL/MySQL — servicios con funcionalidad equivalente en cada categoría

¿Cuál es la diferencia entre Cloud Run, Cloud Functions y GKE en Google Cloud?

Cloud Functions: funciones event-driven (similar a Lambda). Cloud Run: contenedores serverless con auto-scaling a cero (similar a Fargate). GKE: Kubernetes gestionado para orquestación completa de contenedores (máximo control)

Son tres nombres comerciales diferentes para el mismo servicio de cómputo serverless de Google Cloud Platform, diferenciados solo por el plan de precios

GKE es completamente serverless como Cloud Run y no requiere gestión de nodos ni configuración de infraestructura por parte del usuario

Cloud Functions puede ejecutar contenedores Docker completos con múltiples procesos, lo que lo hace equivalente a GKE para la mayoría de casos de uso

En Kubernetes, ¿qué son Pod, Deployment y Service y cómo se relacionan?

Son tres formas alternativas de desplegar la misma aplicación en un cluster, y se elige una según el tamaño del equipo de desarrollo

Un Pod contiene múltiples Deployments dentro de sí, y cada Deployment gestiona un Service independiente para exponer sus endpoints

Pod: unidad mínima de ejecución (uno o más contenedores). Deployment: gestiona réplicas de Pods con rolling updates y rollbacks. Service: expone Pods como endpoint de red estable (ClusterIP, NodePort, LoadBalancer) con service discovery

Service es un recurso exclusivamente diseñado para bases de datos y no se puede usar para exponer aplicaciones web o APIs al tráfico externo

Este código Terraform tiene un error: `resource "aws_instance" "web" { ami = aws_ami.custom.id } resource "aws_ami" "custom" { source_instance_id = aws_instance.web.id }`. ¿Cuál es?

Falta el bloque `provider "aws" {}` con la configuración de región y credenciales, sin el cual Terraform no puede comunicarse con la API de AWS

El problema es únicamente que falta el atributo `instance_type` en el recurso `aws_instance`, que es un campo obligatorio para crear instancias EC2

Falta ejecutar `terraform init` antes de `terraform plan`, lo que causa que los providers no estén descargados y los recursos no se reconozcan

Referencia circular: la instancia depende del AMI y el AMI depende de la instancia. Terraform no puede resolver el orden de creación. Solución: romper la dependencia usando un AMI existente o recursos intermedios

¿Qué es el state de Terraform y por qué no se debe commitear al repositorio?

El state es solo un log informativo de cambios históricos que Terraform genera para debugging y no tiene impacto funcional en la gestión de infraestructura

El state (terraform.tfstate) mapea recursos reales a la configuración, contiene IDs, IPs y potencialmente secrets. No se commitea porque: contiene datos sensibles, causa conflictos en equipo, y puede corromperse. Se usa remote backend (S3 + DynamoDB lock)

El state se regenera automáticamente en cada ejecución de `terraform plan` y no necesita ser guardado ni gestionado de ninguna forma especial

Se puede commitear al repositorio sin problemas siempre que el repo sea privado, ya que la encriptación de Git protege los datos sensibles contenidos

¿Cuáles son las etapas típicas de un pipeline CI/CD y la diferencia entre CI y CD?

CI y CD son exactamente lo mismo expresado con diferentes siglas; ambos términos se refieren al proceso completo de automatización de software

CI es un concepto exclusivo para proyectos frontend (JavaScript/TypeScript) y CD es exclusivamente para proyectos backend (Java/Python/Go)

Un pipeline de CI/CD solo necesita dos etapas: build y deploy directo a producción, sin pasos intermedios de validación o testing

CI (Continuous Integration): lint → build → unit tests → integration tests (en cada push). CD (Continuous Delivery/Deployment): deploy a staging → smoke tests → deploy a producción (manual o automático). CI valida código, CD lo entrega

¿Qué es Ansible y en qué se diferencia de Terraform?

Son herramientas completamente idénticas con diferente sintaxis (HCL vs YAML) que realizan exactamente las mismas funciones de infraestructura

Ansible reemplaza completamente a Terraform en todos los casos de uso, haciendo innecesario usar ambas herramientas en el mismo proyecto

Terraform: infraestructura declarativa (crear/destruir recursos cloud — IaC). Ansible: configuración y aprovisionamiento de servidores (instalar software, configurar servicios — Configuration Management). Terraform para "qué existe", Ansible para "cómo está configurado"

Terraform es exclusivamente para configuración de software dentro de servidores y Ansible es para crear infraestructura cloud como VPCs y bases de datos

¿Cómo automatizar un despliegue tras un push a la rama main usando webhooks?

Configurar un webhook en GitHub/GitLab que envíe POST al servidor/CI al hacer push a main. El receptor valida la firma (secret), verifica la rama, y ejecuta el pipeline de deploy. Alternativa: GitHub Actions/GitLab CI con trigger on push to main

Los webhooks no tienen la capacidad técnica de triggear despliegues automáticos porque son unidireccionales y no pueden ejecutar comandos en servidores remotos

El despliegue siempre debe ser manual con aprobación humana; la automatización completa del deploy es una mala práctica que introduce riesgos de seguridad

La automatización de deploys solo funciona con Jenkins como herramienta de CI/CD; GitHub Actions y GitLab CI no soportan triggers basados en eventos de push

Desafío de código

Crea un pipeline CI/CD completo usando GitHub Actions o GitLab CI que incluya todas las etapas desde lint hasta deploy a staging. Incluye también un docker-compose.yml para desarrollo local.

Requisitos

Pipeline con etapas: lint, tests unitarios, build Docker multi-stage, push a registry, deploy a staging
Dockerfile multi-stage optimizado (builder + runtime)
docker-compose.yml para desarrollo local con hot-reload
Secrets gestionados como variables de entorno del CI (no hardcodeados)
Notificación de estado del pipeline (Slack, email o similar)

Ejemplos

Entrada: Push a rama main con cambios en src/

Salida:

Pipeline ejecuta: lint (ESLint/Flake8) → tests → build imagen Docker → push a ECR/GHCR → deploy a staging con health check

Tecnologías aceptadas

GitHub Actions
GitLab CI
Docker + Docker Compose
Terraform (opcional para infra)
Cualquier lenguaje para la app de ejemplo

Envío de solución

URL del repositorio * Plataformas soportadas: GitHub, GitLab, Bitbucket Introduce una URL válida de repositorio (https://github.com, gitlab.com o bitbucket.org seguido de usuario/repositorio)

DevOps - Junior