Durante siete módulos has seguido a Marta, a Dani y a Lucía. Has visto cómo AlpinaShop pasó de un servidor alquilado en un proveedor español a una plataforma en Google Cloud con entrega continua, observabilidad, SLO, gobierno y una factura un 60 % más baja. Has visto las decisiones y también los errores: el MIG que se arrastró cinco módulos, el endpoint de recomendaciones que hubo que apagar, la clave de cuenta de servicio perdida durante catorce meses.

Pero has visto decidir a otros.

Este módulo es distinto. Aquí no hay una AlpinaShop a la que seguir: hay un folio en blanco, un conjunto de restricciones y una fecha. Vas a elegir un problema, diseñar una solución, construirla, probarla, desplegarla, medirla, pagarla y defenderla. De principio a fin, tú solo.

Y hay una razón práctica por la que esto importa más que cualquier lección anterior: nadie te va a contratar por haber leído sobre Cloud Run. Te van a contratar porque puedes enseñar una URL que funciona, un repositorio con la infraestructura escrita como código, un panel con métricas reales y una factura de 14 € al mes que sabes explicar línea a línea. Eso es un portafolio. Lo demás son apuntes.

Esta primera lección es el pliego de condiciones del proyecto. Define qué se te pide, con qué requisitos mínimos, bajo qué límite de coste, con qué entregables, con qué rúbrica te vas a evaluar y en qué plazo. Léela entera antes de escribir una línea de código o de crear un solo proyecto de GCP. Es literalmente la lección que evita que dentro de tres semanas tengas medio sistema y ninguna idea de si está bien.

1. Qué se te pide exactamente y por qué así
2. Cómo elegir el problema: criterios de un proyecto de portafolio que funciona
3. Cuatro propuestas desarrolladas
4. Traer tu propio problema (y la advertencia que no puedes saltarte)
5. Requisitos funcionales mínimos obligatorios
6. Requisitos no funcionales obligatorios
7. La restricción de coste: el requisito que más te va a enseñar
8. Entregables y su formato
9. La rúbrica de evaluación
10. Planificación: esfuerzo por fase y cronograma
11. Gestión del riesgo: los cinco errores que hunden un proyecto final
12. Cómo trabajar con la documentación oficial
13. Qué hacer cuando algo no funciona
14. Tu decisión de hoy

El encargo, en una frase:

Construye en Google Cloud, de principio a fin y con tus propias manos, una plataforma completa para un problema que tú elijas, recorriendo las mismas etapas que has visto recorrer a AlpinaShop, y déjala documentada, medida, segura y reproducible desde cero.

No es "haz una demo". Una demo es un contenedor desplegado en Cloud Run con gcloud run deploy y una captura de pantalla. Eso lo hace cualquiera en veinte minutos y no demuestra nada, porque el trabajo real no está en desplegar: está en todo lo que rodea al despliegue.

Lo que sí demuestra criterio es esto:

El proyecto está diseñado para tocar todas las capas del curso, no para profundizar en una. Es deliberado: un proyecto que solo demuestra BigQuery compite con miles de proyectos que demuestran BigQuery. Un proyecto que demuestra que sabes conectar cómputo, datos, identidad, red, entrega y observabilidad —y explicar por qué cada pieza está donde está— compite con muy pocos.

Cuánto tiempo cuesta. Entre 40 y 60 horas de trabajo real si vas por primera vez. Repartidas en 4-6 semanas a ritmo de tarde suelta y fin de semana, es perfectamente factible. Si te salen 15 horas, es que estás haciendo una demo. Si te salen 150, es que el alcance se te ha ido de las manos, y hay una sección entera sobre eso más abajo.

Qué NO se te pide. Conviene decirlo pronto, porque la mitad del riesgo de este módulo es hacer de más:

• No se te pide una aplicación bonita. Una interfaz fea pero funcional puntúa igual que una preciosa.
• No se te pide un modelo de machine learning propio. Una API preentrenada cumple el requisito de IA.
• No se te pide alta disponibilidad multirregión. Una región basta y sobra.
• No se te pide Kubernetes. Cloud Run es la opción recomendada por defecto.
• No se te pide un volumen de datos grande. Mil filas ficticias demuestran lo mismo que diez millones y cuestan cero.
• No se te pide que esté "terminado" en el sentido de un producto. Se te pide que esté completo en el sentido de que todas las capas existen y funcionan juntas.

La elección del problema es la decisión con más consecuencias de todo el módulo, y se toma en la primera hora. Un mal problema convierte el proyecto en una tortura de seis meses; uno bueno lo convierte en cuatro fines de semana entretenidos.

Cinco criterios, en orden de importancia:

Si eliges "plataforma de trading algorítmico" y no sabes qué es un libro de órdenes, vas a gastar el 70 % del tiempo aprendiendo finanzas en lugar de aprendiendo GCP. El dominio debe ser tan obvio para ti que puedas escribir los requisitos funcionales de memoria en veinte minutos.

Buenos dominios: reservas, catálogos, inventarios, incidencias, seguimiento de flotas, cursos, citas, gestión de socios. Todo el mundo entiende cómo funciona una reserva.

Malos dominios: cualquier cosa con normativa compleja (sanidad real, banca, seguros), cualquier cosa con algoritmos que son el producto (motores de recomendación de verdad, optimización de rutas óptima), cualquier cosa que dependa de una integración externa que no controlas.

Prueba a describir tu proyecto en una frase. Si necesitas dos "y", ya es demasiado grande.

• ✅ "Una plataforma donde los usuarios reservan plazas en refugios de montaña."
• ⚠️ "Una plataforma donde los usuarios reservan plazas en refugios y los guardas gestionan disponibilidad y hay un marketplace de guías."
• ❌ "Un ERP para la gestión integral de refugios."

El alcance se recorta antes de empezar, no a mitad. Recortar a mitad significa tirar trabajo hecho.

Vas a necesitar datos para la base de datos operativa, para el almacén analítico y para el componente de IA. Si tu dominio necesita datos que no puedes inventar de forma creíble (imágenes médicas etiquetadas, transacciones bancarias reales), cambia de dominio.

Un buen proyecto se puede sembrar con un script de 60 líneas de Python que genere 2.000 filas coherentes: fechas que tienen sentido, importes en un rango razonable, distribución con algo de estacionalidad para que el cuadro de mando no salga plano.

El requisito de "aplicación + almacenamiento + base de datos + datos + analítica + IA" debe salir del problema, no forzarse encima. Si tienes que inventar una excusa para meter Pub/Sub, el proyecto está mal elegido.

Pregúntate: ¿hay algo que ocurra de forma asíncrona? ¿Hay ficheros que subir? ¿Hay algo que analizar históricamente? Si las tres respuestas son sí, el proyecto encaja solo.

Vas a pasar 50 horas con esto, muchas de ellas depurando permisos IAM a las once de la noche. Si el tema te aburre el primer día, el proyecto no se termina. Este criterio parece blando y es el que más proyectos mata.

Puntúa cada idea que se te ocurra de 1 a 5 en cada criterio. Si alguna columna saca menos de 3, descártala:

Si no tienes una idea propia clara, usa una de estas cuatro. Están dimensionadas para el módulo, tienen datos inventables y ejercitan todas las capas obligatorias. Las cuatro son ficticias.

El problema. Una federación ficticia de montañismo gestiona 12 refugios en el Pirineo. Hoy las reservas se hacen por teléfono y se apuntan en una hoja de cálculo por refugio. Hay sobreventa, no se sabe la ocupación real hasta que llega el fin de semana, y no hay forma de saber qué refugios funcionan mejor.

Qué construyes.

• Web pública donde un excursionista busca refugio y fecha, ve plazas libres y reserva.
• Zona privada donde el guarda de cada refugio consulta las reservas del día.
• Subida de fotos del refugio a un bucket, con generación de miniaturas.
• Cada reserva publica un evento que alimenta el almacén analítico.
• Cuadro de mando de ocupación por refugio, mes y tipo de plaza.
• Componente de IA: análisis de sentimiento de las opiniones que dejan los excursionistas (API preentrenada) o etiquetado automático de las fotos.

Datos ficticios. 12 refugios con nombre, coordenadas y capacidad; 2.000 reservas repartidas en 18 meses con estacionalidad de verano; 400 opiniones en texto libre.

Dificultad: media-baja. Es la propuesta de referencia de este módulo y la que se usa en todas las soluciones de los ejercicios.

Lo interesante que enseña. La gestión de la disponibilidad tiene una condición de carrera real (dos personas reservando la última plaza), lo que da pie a una transacción de verdad y a una prueba de integración con sentido.

El problema. Una cadena ficticia de tres clínicas veterinarias necesita gestionar las fichas de los animales, las citas y las historias clínicas. Hoy usan un programa de escritorio instalado en un ordenador por clínica, sin acceso remoto.

Qué construyes.

• Web autenticada donde el personal da de alta animales y propietarios, y agenda citas.
• Subida de radiografías y fotos de la evolución de una lesión a un bucket con clase de almacenamiento por antigüedad.
• Recordatorios de cita: la creación de una cita publica un mensaje que dispara un envío simulado.
• Cuadro de mando de ocupación de agenda, motivos de consulta más frecuentes y facturación por clínica.
• Componente de IA: extracción de entidades del texto libre de la historia clínica (API de lenguaje natural) para etiquetar diagnósticos, o clasificación de las imágenes subidas.

Datos ficticios. 3 clínicas, 8 veterinarios, 600 animales, 3.500 citas históricas, 1.200 notas clínicas en texto libre.

Dificultad: media.

⚠️ Aviso importante para esta propuesta. Aunque los datos de animales no son datos personales, los de sus propietarios sí lo son. Trabaja exclusivamente con nombres, teléfonos, correos y direcciones inventados. No copies una base de datos real de ninguna clínica, ni "anonimizada": la anonimización mal hecha es reidentificable y te mete en un problema de RGPD que no tiene nada que ver con aprender GCP.

El problema. Una empresa ficticia de reparto de última milla con 30 furgonetas quiere saber dónde están sus vehículos, qué entregas llevan hechas y cuánto tarda cada ruta.

Qué construyes.

• Ingesta de posiciones: un simulador publica cada 30 segundos la posición de cada furgoneta en un topic.
• Servicio web con un mapa que muestra el estado actual de la flota y el detalle de cada ruta.
• Almacenamiento de los albaranes firmados (imágenes) en un bucket.
• Base de datos operativa con vehículos, rutas, paradas y entregas.
• Cuadro de mando de puntualidad, kilómetros por ruta y entregas fallidas por motivo.
• Componente de IA: OCR sobre los albaranes escaneados (API de visión) para extraer el número de pedido.

Datos ficticios. 30 vehículos, 12 rutas, 90 días de histórico con unas 400 entregas diarias, y un generador de posiciones GPS que sigue trayectorias plausibles.

Dificultad: media-alta. Es la propuesta con más volumen de datos y la que más ejercita el streaming, pero también la que más fácilmente se dispara de coste si dejas el simulador encendido. Léelo como una advertencia: aquí el requisito de coste es parte del reto.

⚠️ La posición geográfica de una persona identificable es un dato personal de categoría sensible. Trabaja con vehículos y conductores inventados, nunca con datos reales de una flota.

El problema. Una escuela ficticia de formación técnica quiere sustituir su montaje de vídeos en un disco compartido y matrículas por correo por una plataforma propia.

Qué construyes.

• Catálogo público de cursos y zona privada del alumno con su progreso.
• Materiales (PDF, vídeos) en un bucket, servidos con CDN y URL firmadas.
• Base de datos operativa con cursos, lecciones, matrículas y progreso.
• Eventos de "lección completada" que alimentan el almacén analítico.
• Cuadro de mando de tasa de finalización por curso, lecciones donde la gente abandona y actividad semanal.
• Componente de IA: generación de un resumen automático de cada lección con un modelo generativo, o búsqueda semántica sobre el contenido mediante embeddings.

Datos ficticios. 20 cursos, 250 lecciones, 800 alumnos y 40.000 eventos de progreso.

Dificultad: media. Es la propuesta que más se parece a este mismo curso, lo que la hace fácil de razonar y difícil de que te sorprenda.

Traer un problema propio es la mejor opción si cumples los cinco criterios de la sección 2. Un proyecto que resuelve algo que tú entiendes y te importa se defiende mucho mejor en una entrevista que una plantilla, porque en cuanto te preguntan "¿y por qué esto?" tienes una respuesta de verdad.

Pero hay una línea que no se cruza:

⚠️ No uses datos reales de tu empresa, ni de la empresa de nadie.

Ni una exportación "que ya está anonimizada". Ni un volcado de la base de datos de desarrollo. Ni el fichero de clientes con los nombres cambiados. Ni las conversaciones del sistema de soporte "que no llevan nombres".

Tres motivos, cualquiera de ellos suficiente:

1. Legal. El RGPD no distingue entre "producción" y "un proyecto que estoy haciendo para aprender". Si tratas datos personales necesitas base jurídica, finalidad, minimización y una relación contractual con el encargado del tratamiento. Un proyecto de portafolio en tu cuenta personal de GCP no tiene nada de eso.
2. Contractual. Casi cualquier contrato laboral o de confidencialidad prohíbe sacar datos de la empresa a un entorno que la empresa no controla. Tu proyecto de GCP es exactamente eso.
3. Práctico. Un proyecto de portafolio se enseña. Se pone en GitHub, se comparte la URL, se proyecta en una entrevista. Si contiene datos reales, acabas de publicarlos.

Lo que sí puedes hacer: replicar la estructura del problema real con datos inventados. El esquema, los flujos, las reglas de negocio y las dificultades técnicas son tuyos y no son confidenciales; los datos, no. Un generador de datos sintéticos de 80 líneas resuelve esto en una tarde.

Y si aun así tu proyecto va a tratar datos que se parecen a datos personales (nombres, correos, direcciones, aunque inventados), aplica desde el principio lo que viste en 04-07 y en 07-04: cifrado en reposo con claves gestionadas, mínimo privilegio, retención definida con borrado real, y logs que no escriban esos campos. No porque tus datos inventados lo necesiten, sino porque el hábito es el entregable.

Antes de aceptarla, rellena esto. Si alguna casilla queda vacía, la idea no está lista:

La sección de alcance excluido es la más importante del documento y la que todo el mundo deja en blanco. Escribir "no habrá pagos", "no habrá app móvil", "no habrá multiidioma", "no habrá roles más allá de admin y usuario", "no habrá notificaciones por correo reales" es lo que te salva dentro de tres semanas, cuando te apetezca añadir cualquiera de esas cosas.

Estos seis son obligatorios. Sea cual sea tu problema, deben existir. Están formulados como lista verificable: cada uno tiene un criterio de "hecho" comprobable con un comando.

Detalle de cada uno:

RF-1 — Aplicación web contenedorizada. Contenedorizada significa que existe un Dockerfile y que la imagen se construye en CI, no en tu portátil. La recomendación por defecto es Cloud Run (07-02): escala a cero, no pagas cuando nadie la usa, y el contrato es sencillo. Si eliges GKE, que sea porque tienes un motivo escrito, no por lucirte: un clúster encendido se come el presupuesto del proyecto entero.

RF-2 — Almacenamiento de objetos. No vale un bucket vacío creado para cumplir. Debe formar parte del flujo: el usuario sube algo, o la aplicación sirve algo desde ahí. Aplica lo de 02-02: acceso uniforme a nivel de bucket, nada público salvo lo que deba serlo, y una regla de ciclo de vida aunque sea trivial.

RF-3 — Base de datos gestionada. Gestionada, no un contenedor con PostgreSQL dentro. El árbol de decisión de 02-06 te dice cuál: relacional con transacciones → Cloud SQL; documentos con acceso por clave y escalado a cero → Firestore. Para la mayoría de estos proyectos, Cloud SQL PostgreSQL en la instancia más pequeña o Firestore son las respuestas correctas.

RF-4 — Ingesta o procesamiento. Es el requisito que más gente interpreta de menos. No basta con que la app escriba en la BD. Debe haber un flujo asíncrono o programado que lleve datos de un sitio a otro: un topic de Pub/Sub que recoge eventos, un job de Cloud Run que cada noche vuelca a BigQuery, una función que se dispara al subir un fichero. Es la pieza que demuestra que entiendes la diferencia entre el plano operativo y el analítico (04-01, 04-04).

RF-5 — Cuadro de mando. Cuatro visualizaciones que respondan preguntas, no cuatro gráficos bonitos. "¿Qué refugio tiene más cancelaciones?" es una pregunta. "Distribución de reservas" no lo es. Looker Studio sobre BigQuery es gratis y suficiente (04-07).

RF-6 — Componente de IA. Empieza siempre por una API preentrenada. Vision, Natural Language o Gemini resuelven el requisito en dos horas y funcionan. Entrenar un modelo propio con Vertex AI es opcional, cuesta dinero y es la fuente número uno de proyectos que no se terminan. Si te sobra tiempo al final, entonces sí: sustituye la API por un modelo tuyo y documenta la comparación con la línea base, exactamente como hizo Lucía en DA-003.

Aquí es donde este proyecto se separa de una demo. Ocho requisitos, todos obligatorios, todos verificables:

Los tres que la gente se salta y no debería:

RNF-1 (IaC de verdad). El criterio no es "tengo unos ficheros .tf". El criterio es que el sistema se reconstruye desde cero. La prueba se hace en 08-04 y es implacable: destruyes el entorno de desarrollo entero y lo vuelves a crear. Si no arranca, tu IaC no era IaC: era documentación con sintaxis de Terraform.

RNF-3 (sin claves JSON). Esta es la que más te va a diferenciar. La mayoría de proyectos de portafolio tienen un credentials.json en el repositorio o, en el mejor caso, en .gitignore. Configurar Workload Identity Federation entre GitHub Actions o Cloud Build y GCP cuesta media hora la primera vez y es exactamente lo que hace un profesional. Y recuerda el caso de AlpinaShop: una clave perdida durante catorce meses.

RNF-7 (SLO). Un SLO no es "quiero que vaya rápido". Es: "el 99 % de las peticiones a /api/* responden en menos de 800 ms, medido sobre ventana de 28 días". Con su presupuesto de error calculado y visible. Ocupa una tarde y es de lo que más impresiona en una entrevista, porque casi nadie de nivel junior sabe formularlo.

Fija ahora un límite mensual y escríbelo. El proyecto debe poder construirse y mantenerse dentro del crédito de prueba de Google Cloud (300 USD / 90 días en el momento de escribir esto — verifícalo, las condiciones cambian) o, si el crédito se te ha agotado, por debajo de un límite mensual que tú fijas.

Valores de referencia razonables:

Por qué la restricción es parte del ejercicio y no un inconveniente. Cualquiera puede construir una arquitectura que funcione con dinero infinito. Lo que distingue a un buen ingeniero de la nube es construirla con el dinero que hay. La restricción de coste te va a forzar a tomar exactamente las decisiones que se toman en una empresa real:

• Escalar a cero en lugar de tener capacidad reservada (Cloud Run vs. MIG).
• Elegir la instancia más pequeña que cumple, y medir si cumple.
• Apagar los entornos de desarrollo por la noche.
• Particionar las tablas de BigQuery para no escanear 1,2 TB cada vez que se abre el panel.
• No dejar un clúster de GKE encendido "para probar".
• Poner ciclo de vida en los buckets desde el día uno.
• Retener logs 30 días y no 400.

Todo eso es 07-05 aplicado a tu bolsillo, que es la mejor forma de aprenderlo.

Antes de crear un solo recurso. Literalmente el primer día, antes que nada:

Y el aviso que hay que repetir siempre: un presupuesto avisa, no impide. Si dejas encendido algo caro, el presupuesto te manda un correo mientras el contador sigue subiendo. Lo que impide de verdad son las cuotas (07-07) y la costumbre de mirar el informe de facturación cada pocos días. Ponte un recordatorio: cada martes y cada sábado, abrir el informe de costes. Treinta segundos.

⚠️ Todos los precios de este módulo son órdenes de magnitud, no tarifas. Los precios de Google Cloud cambian, varían por región y dependen de descuentos y del nivel gratuito. Consulta siempre la calculadora oficial y la página de precios del servicio antes de comprometer una cifra en tu documento de arquitectura.

Siete entregables. Los tres primeros son el proyecto; los cuatro siguientes son lo que hace que el proyecto se pueda evaluar y defender.

Estructura del repositorio (se detalla en 08-03, pero decídela ya):

Crea este esqueleto hoy, aunque esté vacío. Los directorios vacíos con un README.md de una línea que diga qué irá ahí valen más que la mejor intención de organizarlo luego.

Esta es la rúbrica con la que te vas a autoevaluar en 08-05. Léela ahora, porque saber cómo te van a puntuar cambia lo que construyes.

100 puntos, repartidos en siete bloques:

A. Diseño y decisiones (20 puntos)

B. Implementación funcional (20 puntos) — 3 puntos por requisito funcional cumplido (18) + 2 puntos si el flujo completo funciona de extremo a extremo sin intervención manual.

C. Infraestructura como código (15 puntos)

D. Seguridad e identidad (15 puntos)

E. Entrega y pruebas (10 puntos)

F. Observabilidad, SLO y coste (10 puntos)

G. Documentación y presentación (10 puntos)

Ese último renglón no es una broma. La autoevaluación honesta es parte de la nota: en 08-05 verás que reconocer y priorizar la deuda técnica suma puntos, y esconderla los resta.

Estimación para un proyecto de dificultad media, primera vez, trabajando solo:

Multiplica por 1,5 si es tu primer proyecto en la nube. No es pesimismo: es la observación empírica de que la primera vez que configuras Workload Identity Federation tardas dos horas y la segunda, quince minutos.

Los cuatro hitos son puntos de control, no adornos. En cada uno te paras y compruebas:

Si vas con retraso, recorta funcionalidad, nunca requisitos no funcionales. Una aplicación con dos pantallas, IaC completa y seguridad impecable puntúa muy por encima de una con ocho pantallas y un credentials.json en el repositorio.

Estos cinco no son "errores comunes". Son las cinco causas por las que los proyectos de portafolio no se terminan. Reconócelos ahora y tendrás la mitad del trabajo hecho.

Cómo se manifiesta. La semana 2 añades "sería fácil meter también pagos". La semana 3, notificaciones. La semana 4, una app móvil. La semana 6 tienes nueve cosas a medias y ninguna terminada.

Por qué pasa. Porque añadir funcionalidad es divertido y terminar no lo es. Y porque el alcance excluido no estaba escrito.

La contramedida. La lista de exclusiones de la sección 4, escrita y firmada por ti el primer día. Cuando se te ocurra algo nuevo, no lo descartes: apúntalo en una sección ## Siguientes pasos del README. Eso convierte la tentación en un entregable de la presentación, donde puntúa.

Cómo se manifiesta. El día uno abres el editor y empiezas la aplicación. Tres semanas después tienes una app bonita y ninguna infraestructura, ningún IaC, ninguna seguridad. Y entonces intentas "meterle Terraform" a algo que ya existe, que es el doble de trabajo.

Por qué pasa. Porque programar es lo que sabes hacer y lo demás da pereza.

La contramedida. El orden de 08-03: organización → red → identidad → estado → datos → aplicación. La aplicación es la fase 4 de 8, no la 1. Y hay una razón técnica dura: el projectId no se puede cambiar y la red no se puede rehacer sin destruirlo todo. Lo que se decide primero es lo que es caro de cambiar.

Cómo se manifiesta. Todo con roles/owner "para que funcione ahora", una clave JSON descargada "temporalmente", la contraseña de la BD en una variable del código. La última semana intentas arreglarlo, rompes todo y acabas dejándolo como estaba.

Por qué pasa. Porque el mínimo privilegio duele al principio: cada permiso que falta es un error 403 y media hora de depuración.

La contramedida. Empezar restrictivo y abrir sólo lo que falla. gcloud policy-troubleshoot te dice exactamente qué permiso falta (lo tienes en 03-04). Duele la primera semana y no duele nunca más. Y el bloque D de la rúbrica vale 15 puntos que se pierden enteros si haces esto mal.

Cómo se manifiesta. Dejas un clúster de GKE encendido un fin de semana. O un job de Dataflow en streaming. O una instancia de Cloud SQL grande "para que vaya rápido". El lunes tienes 180 € gastados y el crédito de prueba a la mitad.

Por qué pasa. Porque en la nube no ves el hardware. Un servidor apagado en tu casa no consume; una VM encendida en la nube sí, aunque no la uses.

La contramedida. Tres cosas, todas de la sección 7: el presupuesto creado antes que nada, la revisión del informe de costes dos veces por semana, y la costumbre de destruir el entorno de desarrollo cuando no lo uses. Esto último es un superpoder que sólo tienes si tu IaC es de verdad:

Si eso funciona, tu proyecto de desarrollo cuesta cero cuando no trabajas. Y de paso estás ejecutando la prueba más dura de RNF-1 cada semana, gratis.

Cómo se manifiesta. La última semana te sientas a escribir el documento de arquitectura y no te acuerdas de por qué elegiste Firestore en lugar de Cloud SQL. Escribes una justificación inventada a posteriori, que se nota, y que además puede que no sea la razón real.

Por qué pasa. Porque documentar parece que no avanza el proyecto.

La contramedida. El docs/diario.md. Cada sesión de trabajo, tres líneas:

Tres líneas por sesión, veinte sesiones: sesenta líneas que se convierten solas en el documento de arquitectura, en los ADR y en la mitad de la presentación. Es la inversión con mejor retorno de todo el módulo.

El último es el riesgo de verdad. La mitigación real contra el abandono es que el proyecto sea pequeño y te apetezca, que es lo que decían los criterios 2 y 5.

Vas a pasar una parte sustancial del proyecto leyendo documentación. Hacerlo bien es una habilidad, y estas son las reglas:

1. La documentación oficial es la fuente. Todo lo demás es contexto. Un blog de 2021, una respuesta de Stack Overflow de 2019 o un vídeo de YouTube pueden ayudarte a entender un concepto, pero no para copiar comandos: la CLI cambia, los roles se renombran, los servicios se deprecan. El curso mismo, por muy actualizado que esté a 2026, es una foto de un momento.

2. Las cuatro secciones que hay que conocer de cada servicio:

La sección de cuotas y límites es la que menos gente lee y la que más disgustos evita. Saber que Cloud Run tiene un límite de tiempo de petición, o que BigQuery tiene un máximo de operaciones de tabla al día, cambia el diseño.

3. El registro de Terraform es tan importante como la documentación de GCP. Para cada recurso que crees, registry.terraform.io/providers/hashicorp/google/latest/docs te da los argumentos exactos, cuáles son obligatorios, cuáles fuerzan recreación del recurso (ForceNew) y qué se puede importar. Ese ForceNew es la diferencia entre un apply de 20 segundos y uno que destruye tu base de datos.

4. Las notas de versión existen. Cada servicio tiene su página de release notes. Antes de dar por perdida una funcionalidad, mira si salió el mes pasado.

5. Cuando la documentación y el mensaje de error se contradicen, gana el mensaje de error. Y cuando el mensaje de error dice "permission denied", casi siempre tiene razón: no es un bug, te falta un permiso.

Te vas a atascar. Varias veces. El método siguiente resuelve la gran mayoría de bloqueos en menos de veinte minutos, y lo importante es aplicarlo en orden en vez de probar cosas al azar:

Paso 1 — Lee el error entero. Completo, hasta el final, incluido el details y el enlace que a veces incluye. La mitad de los errores de GCP dicen literalmente qué permiso falta o qué API hay que activar.

Paso 2 — ¿Está la API activada? Es la causa número uno de errores inexplicables la primera semana:

Paso 3 — ¿Es un permiso? Si el error contiene 403, PERMISSION_DENIED o does not have permission, es un permiso, sin excepción:

Paso 4 — ¿Es la red? Si el síntoma es un tiempo de espera agotado y no un rechazo, es red:

Paso 5 — ¿El recurso es como crees que es? Un describe desmonta la mitad de las hipótesis equivocadas:

Y si tras veinte minutos sigues igual: cambia de tarea. Documenta el bloqueo en docs/diario.md con el error exacto y lo que ya has probado, y vete a otra fase. Volver al día siguiente con la cabeza fría resuelve más bloqueos que insistir tres horas seguidas. Este consejo parece de autoayuda y es puramente estadístico.

Antes de pasar a 08-02, cinco cosas. No son opcionales y no llevan más de dos horas:

• [ ] Elegir el problema. Una de las cuatro propuestas o el tuyo, validado con la plantilla de la sección 4.
• [ ] Escribir la frase. Una frase sin "y". Pégala en la primera línea del README.
• [ ] Escribir las cinco exclusiones. Lo que tu proyecto no va a hacer.
• [ ] Fijar el límite de coste. Un número en euros al mes, escrito en el README.
• [ ] Crear el repositorio con el esqueleto de carpetas y el primer commit.

Si no puedes hacer las cinco hoy, tu problema no está elegido todavía. Vuelve a la sección 2.

Elegir un problema que no entiendes porque suena impresionante. "Plataforma de análisis de riesgo crediticio con IA" suena mejor que "reservas de refugios" hasta que te toca modelar el riesgo crediticio. En una entrevista, un proyecto sencillo bien explicado gana siempre a uno complejo que balbuceas.

Confundir "completo" con "grande". El proyecto se evalúa por capas cubiertas, no por funcionalidad. Dos pantallas con IaC, CI/CD, SLO y seguridad valen 80 puntos; quince pantallas sin nada de eso valen 45.

Crear los proyectos de GCP antes de haber leído 08-02. El projectId es inmutable. Si creas test-1234 porque tenías prisa, lo vas a enseñar en la entrevista. Espera a la lección de diseño, donde se decide la convención de nombres.

Usar el crédito de prueba como si fuera infinito. 300 USD parecen mucho hasta que dejas un GKE encendido: un clúster estándar de tres nodos se come unos 100 € al mes él solo. Cloud Run escala a cero; GKE Autopilot no cuesta cero pero cuesta poco; GKE estándar cuesta desde el minuto uno.

Dejar el componente de IA para el final y elegir entrenar un modelo. Es el orden inverso al correcto: pon la API preentrenada en la fase 6 (dos horas, funciona) y sólo si sobra tiempo, sustitúyela por un modelo propio. Un componente de IA sencillo que funciona vale los 3 puntos; uno ambicioso a medias vale 0.

No leer la rúbrica hasta el final. La rúbrica es el pliego. Todo lo que hagas que no esté en la rúbrica es tiempo que no puntúa. Tenla abierta en una pestaña durante todo el módulo.

Consejo: haz un git commit al final de cada sesión, aunque no funcione. El historial de commits es un entregable en sí mismo: un repositorio con 60 commits distribuidos en seis semanas cuenta una historia de trabajo real. Uno con 3 commits gigantes cuenta otra.

Consejo: guarda todas las capturas y todos los números desde el principio. La captura del panel el día que funcionó, el resultado de la primera prueba de carga, la factura del primer mes. En 08-05 los vas a necesitar y reconstruirlos es imposible.

Consejo: pon una alarma real en el calendario. Dos sesiones fijas por semana, en el calendario, con nombre. Los proyectos personales no mueren por dificultad técnica: mueren porque nunca hay un momento.

Los ejercicios de este módulo son hitos de tu propio proyecto. Las soluciones muestran el mismo hito resuelto sobre RefugioReserva, el proyecto de referencia, para que tengas un modelo sin poder copiar el tuyo.

Elige tu problema y rellena la plantilla de validación de la sección 4 completa: nombre, frase de una línea sin "y", el problema con su usuario, alcance incluido (máximo 5 puntos), alcance excluido (mínimo 5 puntos), la tabla de cómo cumples los seis requisitos funcionales, el origen y volumen de los datos ficticios y el riesgo principal.

Después, puntúa tu idea con la tabla de decisión de los cinco criterios. Si algún criterio saca menos de 3, cambia de idea o ajústala hasta que suba.

Decide tu límite mensual, justifícalo en dos líneas y crea el presupuesto real en tu cuenta de facturación con umbrales al 50, 90 y 100 %. Documenta en una tabla qué servicios esperas usar, con qué configuración mínima y qué orden de magnitud de coste tienes en la cabeza (lo afinarás en 08-02 con la calculadora).

Además, escribe la respuesta a esta pregunta: si dentro de tres semanas descubres que vas al 200 % de tu límite, ¿qué es lo primero que apagas? Ese orden de prioridad escrito de antemano es lo que te salva de decidir con prisa.

Adapta el cronograma de la sección 10 a tu disponibilidad real (horas por semana que puedes dedicar de verdad, no las que te gustaría). Produce un diagrama mermaid con tus fechas y tus cuatro hitos, y para cada hito escribe su criterio de paso y qué recortarías si no lo cumples.

Crea el repositorio con el esqueleto de carpetas de la sección 8, el README.md con la frase del proyecto, las exclusiones y el límite de coste, y el docs/diario.md con su primera entrada. Haz el primer commit.

Solución 1 — Definición y acotación de RefugioReserva

Puntuación con la tabla de decisión:

Solución 2 — Restricción de coste de RefugioReserva

Límite fijado: 12 € al mes. Justificación: el crédito de prueba ya está consumido, y quiero que el proyecto pueda quedarse encendido indefinidamente como pieza de portafolio sin que me duela. 12 € es aproximadamente lo que cuesta un dominio (prorrateado) más una instancia mínima de base de datos.

Todas estas cifras son órdenes de magnitud a fecha de escritura y para europe-west1. Hay que rehacerlas con la calculadora oficial en 08-02 antes de dar el diseño por bueno.

Si llego al 200 % (24 €/mes), este es el orden de apagado, decidido de antemano:

1. Apagar Cloud SQL fuera del horario de trabajo con un job programado (arranca a las 9, para a las 23). Ahorro inmediato: ~60 % de la partida grande. Riesgo: la demo no funciona de madrugada; asumible.
2. Reducir la retención de logs a 7 días y desactivar los logs de acceso a datos si los hubiera activado.
3. Vaciar Artifact Registry dejando sólo las 3 últimas imágenes.
4. Migrar de Cloud SQL a Firestore. Es la medida nuclear: elimina el 80 % del coste pero implica rehacer la capa de datos. Sólo si las tres anteriores no bastan, y sería un ADR nuevo con sus consecuencias.
5. Destruir el entorno de desarrollo y trabajar sólo contra producción, con más cuidado.

Lo que no haría: quitar el balanceador o el certificado (rompe RNF-5), ni desactivar la monitorización (rompe RNF-6). Recortar requisitos no funcionales para ahorrar 2 € es cambiar 15 puntos de rúbrica por el precio de un café.

Solución 3 — Plan y terreno de RefugioReserva

Disponibilidad real declarada: 8 horas por semana (dos tardes de 2 h entre semana + 4 h el sábado). Sobre una estimación de 50 horas, salen 7 semanas con algo de margen, no 6. Es preferible reconocerlo ahora que ir con retraso desde la semana 1.

El terreno preparado:

Fíjate en dos detalles del .gitignore: *.tfvars y *credentials*.json. El primero evita subir valores por entorno que a veces llevan secretos; el segundo es una red de seguridad por si algún día, con prisa, descargas una clave. No deberías descargar ninguna —RNF-3—, pero la red de seguridad no estorba.

Y fíjate sobre todo en la última línea del diario: no crear todavía ningún proyecto de GCP. Es la disciplina que separa este módulo de un tutorial.

Ya tienes el pliego de condiciones completo.

Sabes qué se te pide: una plataforma completa de principio a fin, no una demo, con todas las capas del curso conectadas y explicadas. Y sabes qué no se te pide, que es igual de importante: ni belleza, ni escala, ni modelos propios, ni alta disponibilidad.

Sabes elegir el problema con cinco criterios en orden —dominio conocido, alcance en una frase sin "y", datos inventables, varias capas naturales y que te apetezca— y tienes cuatro propuestas desarrolladas con sus datos, su dificultad y sus riesgos, además de la opción de traer la tuya con una regla que no se negocia: datos reales, nunca, ni "anonimizados", ni de tu empresa, por motivos legales, contractuales y prácticos.

Tienes los seis requisitos funcionales con su criterio de "hecho" y el comando que lo verifica, y los ocho no funcionales que separan un proyecto de una demo: IaC reproducible, CI/CD con prueba, mínimo privilegio sin claves JSON, secretos gestionados, HTTPS propio, panel y alerta, un SLO medido y un presupuesto con aviso.

Tienes la restricción de coste entendida como lo que es: no un inconveniente, sino el requisito que te obliga a tomar las mismas decisiones que se toman en una empresa —escalar a cero, la instancia más pequeña que cumple, particionar, apagar lo que no se usa— y con el recordatorio de que un presupuesto avisa pero no impide.

Tienes los siete entregables con su formato y su ubicación, la rúbrica de 100 puntos repartida en siete bloques con criterios verificables uno a uno, y la lectura honesta de la puntuación, incluido el aviso de que un 98 probablemente significa que te has puntuado con benevolencia.

Tienes la planificación: 48-75 horas repartidas en diez fases, un cronograma de referencia con cuatro hitos y, en cada uno, su criterio de paso y qué recortar si no llegas —siempre funcionalidad, nunca requisitos no funcionales.

Y tienes los cinco errores que hunden un proyecto final, con su síntoma, su causa y su contramedida: alcance excesivo (exclusiones escritas), empezar por el código (el orden de fases, porque el projectId no se cambia), seguridad al final (restrictivo desde el día uno y policy-troubleshoot como aliado), olvidar el coste (presupuesto primero y destroy los viernes) y no documentar sobre la marcha (tres líneas de diario por sesión, la inversión con mejor retorno del módulo).

En la próxima lección, 08-02, pasas del pliego al plano: traducir cada requisito a un servicio concreto con su justificación y su alternativa descartada, dibujar los tres diagramas que sirven, decidir la estructura de proyectos y la convención de nombres antes de crear nada, diseñar la red y la identidad sobre papel, modelar los datos con su ciclo de vida, estimar el coste con la calculadora y compararlo con tu límite, definir tus SLO y escribir tus primeros ADR.

Y no toques la consola de GCP hasta entonces. El projectId no se cambia.