Portfolio Projects for Cloud Engineer

Tienes tres certificados de cloud y ni una sola entrevista. El problema casi nunca es la certificación en sí, sino que tu CV no demuestra que sepas construir nada. Quien revisa candidaturas junior o de nivel medio mira primero los proyectos, y los certificados después.

Los proyectos responden preguntas que un examen no puede. ¿Sabes diseñar una solución completa? ¿Entiendes los costes? ¿Puedes explicar una decisión técnica a otra persona? Un proyecto bien hecho contesta todo eso en dos minutos.

Qué mira realmente quien revisa tu portfolio#

No busca el proyecto más grande. Busca tres cosas, y las tres se pueden entrenar.

La primera es que el proyecto resuelva un problema concreto. "Practiqué con EC2" no es un problema. "Necesitaba desplegar una app con alta disponibilidad gastando menos de 20 dólares al mes" sí lo es.

La segunda es que se vean tus decisiones. Por qué usaste una base de datos gestionada y no una en EC2. Por qué elegiste Terraform y no CloudFormation. El razonamiento importa más que el servicio de moda.

La Tercera es que el proyecto se pueda ejecutar. Un README claro, un despliegue repetible, costes estimados. Si otra persona clona el repositorio y lo levanta en una tarde, ya estás por encima de la media.

Tres proyectos que funcionan mejor que un curso más#

1. Infraestructura como código para una aplicación de tres capas

Monta una aplicación web simple, con base de datos, red privada y balanceador, y define todo en Terraform o CloudFormation. El valor no está en la app: está en que la infraestructura se pueda crear y destruir con un comando.

Añade entornos separados, staging y producción, con módulos reutilizables. Documenta por qué la base de datos está en una subred privada y qué reglas de seguridad tiene cada grupo. Este proyecto demuestra que entiendes redes, seguridad y automatización a la vez.

2. Pipeline CI/CD con pruebas, escaneo y despliegue por etapas

Crea un repositorio con una aplicación pequeña y un pipeline que compile, ejecute pruebas, escanee dependencias y despliegue primero a un entorno de pruebas. Después, un paso manual o automático que promueva a producción.

Añade rollback. Documenta un fallo real que tuvieras durante el desarrollo y cómo lo solucionaste. Los revisores adoran los pipelines que fallan y se arreglan, porque eso es el trabajo diario de un cloud engineer.

3. Observabilidad y control de costes en una arquitectura serverless

Despliega una función que procese eventos, con colas, alarmas y dashboards. Configura alertas de errores, latencia y coste. Incluye una tabla con el coste mensual estimado y qué ajustaste para reducirlo.

Este proyecto habla un idioma que los gerentes entienden: fiabilidad y dinero. Si además muestras cómo escalonaste la solución o cómo manejas picos de tráfico, tienes material para media hora de conversación técnica.

Cómo presentar los proyectos en tu CV#

Una línea por proyecto, máximo dos. Escribe qué construiste, con qué tecnologías y qué resultado tuvo. Nada de "participé en" ni "expuesto a".

Ejemplo de bullet reescrito:

Antes: "Realicé prácticas con servicios AWS y adquirí conocimientos en la nube."

Después: "Definí en Terraform una arquitectura web de tres capas en AWS con red privada, RDS y balanceador, desplegada en entornos de staging y producción, con coste mensual estimado de 28 dólares."

La segunda versión da tecnología, alcance y una cifra verificable. Si no tienes cifras exactas, pon rangos realistas y di cómo los mediste. La honestidad se nota, y en entrevistas te preguntarán por ellas.

Si necesitas comprobar que tu CV pasa los filtros automáticos antes de que lo lea una persona, usa el comprobador de CV compatible con ATS de jobrise.

Cómo montar el repositorio en GitHub#

Cada proyecto necesita su propio repositorio, con un nombre descriptivo, no "proyecto-final-curso". Dentro, mantén el mismo orden siempre.

• README con el problema, la arquitectura y cómo desplegarlo en menos de 15 minutos
• Diagrama de la arquitectura, aunque sea simple y hecho a mano
• Instrucciones de despliegue con los comandos exactos, no solo un enlace a la documentación del proveedor
• Sección de costes estimados y cómo los calculaste
• Registro de decisiones: qué alternativas descartaste y por qué
• Sección de errores conocidos o mejoras pendientes

Ese último punto sorprende a mucha gente. Un repositorio que admite sus limitaciones parece escrito por alguien con experiencia, no por alguien que copió un tutorial.

Errores que hacen que tu proyecto parezca un tutorial#

El error más común es seguir un curso paso a paso y subir el resultado sin cambiar nada. Si tu README dice exactamente lo mismo que el vídeo, el revisor lo detecta en diez segundos.

Otros errores frecuentes:

• Nombres genéricos como "proyecto-aws" o "final-curso"
• Sin diagrama de arquitectura ni explicación de decisiones
• Credenciales o claves dentro del repositorio, un fallo que descarta candidaturas al instante
• Costes sin estimar, cuando el proyecto deja recursos activos que pagan la factura
• Un único commit gigante, sin historial que muestre cómo trabajaste
• Tecnologías de moda sin que aporten nada al problema

Para evitar el último punto, antes de añadir un servicio nuevo pregúntate qué problema resuelve. Si no tienes respuesta clara, no lo añadas.

Cómo hablar de los proyectos en la entrevista#

Prepara una explicación de dos minutos por proyecto: problema, arquitectura, decisión difícil y resultado. Después, espera preguntas de seguimiento sobre costes, seguridad o escalado.

Ejemplo de respuesta:

"Monté una arquitectura de tres capas en AWS con Terraform para una app de reservas. La decisión más difícil fue la base de datos. Descarté una instancia EC2 con PostgreSQL por el mantenimiento y elegí RDS en una subred privada, aunque subía el coste en unos 15 dólares al mes. Prefirí pagar más y reducir el riesgo de que alguien dejara el puerto abierto. Luego ajusté el tamaño de instancia tras revisar las métricas de uso durante dos semanas."

Esa respuesta muestra criterio, no solo tecnología. Si te preguntan qué harías distinto, di la verdad: casi todos los proyectos tienen una mejora clara, y reconocerla es señal de madurez.

Si estás preparando entrevistas, te conviene leer más guías sobre entrevistas técnicas y negociación en el blog de jobrise.

Dónde buscar inspiración y referencias#

Mira ofertas reales de cloud engineer para ver qué tecnologías se piden en tu zona. Los anuncios cambian según el mercado y la fecha, así que revísalos cada pocas semanas en el buscador de empleo de jobrise.

También ayuda leer el análisis de ofertas de empleo para entender qué piden las empresas más allá de los requisitos técnicos.

Herramientas gratis#

• jobrise.io/es/free-ats-checker/
• jobrise.io/es/free-jd-decoder/
• jobrise.io/es/jobs/
• jobrise.io/es/blog/

Preguntas frecuentes#

¿Cuántos proyectos necesito en el portfolio?

Tres bien documentados valen más que diez a medias. Empieza por uno y llévalo hasta el final antes de empezar el siguiente.

¿Necesito certificaciones además de los proyectos?

Ayudan en procesos con filtros automáticos o en consultoras que exigen credenciales. Pero sin proyectos que demuestren que sabes aplicar lo estudiado, pierden fuerza.

¿Sirven los proyectos personales si no he trabajado en cloud?

Sí, y son la vía principal de entrada. Lo que importa es que el proyecto se pueda ejecutar, tenga decisiones documentadas y refleje un problema real.

¿Cuánto debería gastar en la nube para estos proyectos?

La mayoría se puede hacer con niveles gratuitos o por menos de 30 dólares al mes si apagas los recursos cuando no trabajas. Revisa siempre la página oficial de tu proveedor de nube antes de desplegar, porque los precios y las condiciones cambian.

¿Puedo usar un proyecto de un curso como portfolio?

Puedes usarlo como base si lo adaptas: cambia el caso, añade tus propias decisiones, documenta costes y errores. Si el resultado es idéntico al del curso, no aporta nada.