Has terminado el proyecto. Tienes un sistema construido, probado, medido, documentado y defendido. Y ahora aparece la pregunta que llega siempre al final de un curso largo: ¿y ahora qué?

Esta lección responde a eso con la mayor honestidad posible, que incluye decirte cosas que no siempre se dicen: lo que este curso te ha dado y lo que no, para qué sirven realmente las certificaciones y para qué no, cuánto tarda de verdad en llegar el primer trabajo en la nube, y por qué la mitad de lo que has aprendido caducará en tres años mientras que la otra mitad no caducará nunca.

No es una lección de teoría. Es un mapa: dónde estás, qué caminos hay, cuánto cuesta cada uno y cuál tiene sentido según lo que quieras hacer.

Y es la última lección del curso.

1. Dónde estás ahora: el mapa honesto
2. El itinerario de certificaciones de Google Cloud
3. Cómo preparar la Associate Cloud Engineer
4. Qué valen y qué no valen las certificaciones
5. Construir experiencia real sin un trabajo en la nube
6. Especializarse: los cinco perfiles
7. Mantenerse al día cuando la plataforma cambia cada mes
8. Una palabra sobre la multinube, AWS y Azure
9. El cierre

Estas cosas las sabes hacer solo, sin tutorial, y sabrías repetirlas en un entorno distinto:

Es más de lo que parece. Y sobre todo: has hecho todo eso junto, en un solo sistema, que es la parte difícil.

Aquí conviene ser preciso, porque confundir "lo he visto" con "lo sé" es la vía rápida a una entrevista incómoda:

Y esto es igual de importante saberlo:

• Migraciones reales: mover una empresa con sistemas heredados, dependencias no documentadas y ventanas de corte. Es la mitad del trabajo real de un arquitecto.
• FinOps a escala: descuentos por compromiso, atribución en organizaciones grandes, negociación con el proveedor.
• Cumplimiento normativo serio: ENS, ISO 27001, SOC 2, esquemas sectoriales. Se menciona el RGPD; no se ha trabajado.
• Trabajo en equipo sobre la misma infraestructura: revisiones de código de Terraform entre varias personas, entornos compartidos, gestión de conflictos de estado.
• Guardias y operación 24×7: rotaciones, escalados, fatiga de alertas.
• Contratación y contratos: soporte, SLA contractuales, cuentas de facturación de empresa.

Estar en "practicante" tras un curso es exactamente donde hay que estar. Y hay un dato que conviene tener presente: mucha gente con dos años de experiencia en la nube nunca ha escrito un módulo de Terraform ni ha definido un SLO, porque en su empresa eso lo hace otro equipo. Tú lo has hecho.

⚠️ Los nombres, temarios, precios, duraciones y periodos de validez cambian. Todo lo que sigue es orientativo a la fecha de escritura; verifica siempre en cloud.google.com/learn/certification antes de inscribirte.

Tres reglas sobre el orden:

1. No te saltes la ACE para ir directo a una profesional. Se puede —no hay requisitos formales— y es mala idea: las profesionales asumen que sabes operar la plataforma y preguntan sobre decisiones, no sobre mecánica.
2. Cloud Digital Leader no es un paso previo a la ACE. Es un camino distinto, para perfiles no técnicos. Si has terminado este curso, empezar por ahí es perder tiempo y dinero.
3. Una profesional cada vez, y con experiencia real entre medias. Coleccionar certificaciones sin proyectos detrás produce un currículum que se desmonta en la primera entrevista técnica.

Dos cosas del formato que importan: no publican la nota de corte, así que no hay forma de calcular cuánto margen llevas; y el examen no penaliza los fallos, así que nunca dejes una pregunta en blanco.

Es el siguiente paso natural tras este curso, así que va con detalle.

Cinco áreas, todas orientadas a hacer, no a diseñar:

Diagnóstico honesto: este curso cubre bien entre el 70 y el 80 % del temario. Los tres huecos claros son Compute Engine en profundidad (discos, instantáneas, grupos de instancias gestionados), GKE con kubectl de verdad y la sintaxis exacta de los comandos. El examen pregunta cosas del tipo "¿cuál de estos cuatro comandos hace X?", y ahí no vale entender el concepto: hay que haberlos escrito.

Sobre los volcados de preguntas ("dumps"): existen, circulan, y usarlos incumple el acuerdo del examen —te pueden invalidar la certificación—. Además de eso, hay un motivo práctico: aprobar memorizando respuestas produce una certificación que no sostienes en una entrevista técnica, que es exactamente el peor resultado posible.

Asumiendo 6-8 horas por semana:

La semana 7 es la que decide. Y la regla que la hace útil: por cada pregunta fallada, no basta con ver la respuesta correcta; hay que entender por qué las otras tres son incorrectas. Ese ejercicio es el que enseña de verdad.

Sobre la renovación: las certificaciones caducan a los dos años y se renuevan volviendo a examinarse (a veces con un examen de renovación más corto, según el programa vigente — verifícalo). Merece la pena saberlo antes de invertir: no es un título permanente, es una suscripción.

Dicho sin rodeos, porque hay mucha exageración en las dos direcciones.

• Pasan el filtro. Muchos procesos de selección filtran currículums automáticamente. Una certificación te mete en la pila que alguien lee.
• Estructuran el estudio. El temario oficial es una lista concreta de lo que hay que saber, lo cual es enormemente valioso cuando estudias solo.
• Cubren huecos que no sabías que tenías. Estudiar para la ACE te obliga a mirar Compute Engine en detalle aunque tu proyecto usara Cloud Run.
• Valen dinero a las consultoras. Los partners de Google necesitan un número de certificados para mantener su nivel de partnership. En ese mercado concreto, una certificación es un activo con valor directo.
• Dan confianza. No es un argumento menor cuando llevas meses estudiando solo.

• No sustituyen a la experiencia. Nadie contrata a un arquitecto por tener la Professional Cloud Architect. La certificación abre la conversación; la experiencia la sostiene.
• No garantizan un puesto. El mercado pide "2 años de experiencia" con o sin certificación.
• No demuestran que sepas construir. Un examen de opción múltiple mide reconocimiento, no capacidad. Tu proyecto demuestra más que tu certificación.
• Caducan. Dos años. Es una suscripción, con su coste recurrente en dinero y en tiempo.
• No enseñan lo difícil. Ninguna certificación te enseña a decir que no a un requisito imposible, a negociar un plazo o a llevar una migración con gente asustada.

Certificación + proyecto propio + capacidad de explicarlo.

Las tres cosas juntas. Con solo la primera, eres un candidato entre muchos. Con solo el segundo, no pasas el filtro automático. Con las tres, estás por delante de la mayoría de perfiles junior, porque la mayoría tiene una o dos.

Y si tuvieras que elegir una sola —porque el dinero o el tiempo no dan para más—: el proyecto. Es lo que sostiene una entrevista técnica de cuarenta minutos.

El círculo vicioso clásico: piden experiencia para dar trabajo, y hace falta trabajo para tener experiencia. Se rompe por cuatro sitios.

Ya tienes uno. Haz dos más, cada uno atacando un hueco distinto de la sección 1:

El criterio de "no es de juguete": tiene IaC, tiene CI/CD, tiene observabilidad y está documentado. Un tutorial seguido no cuenta; una decisión tomada, sí.

• Documentación de proyectos abiertos. Es la puerta de entrada más accesible y la más agradecida: corregir un ejemplo que ya no funciona en el proveedor de Terraform para Google es una contribución real.
• Módulos de Terraform. Publicar un módulo bien hecho, con README, ejemplos y pruebas, es un artefacto profesional.
• Responder preguntas. Explicar algo a otro es la mejor forma de descubrir si lo sabes.
• Escribir. Un artículo contando un problema que resolviste y cómo. No hace falta que sea original: hace falta que sea concreto.

Google Cloud ofrece un crédito inicial de prueba (~300 USD/90 días, verifícalo) y un nivel gratuito permanente con cuotas mensuales de varios servicios. Con disciplina, se puede practicar durante meses sin pagar.

Las siete reglas de no gastar dinero:

1. Presupuesto con alertas antes que nada, siempre.
2. Nada que no escale a cero, salvo que lo hayas decidido: Cloud Run, Functions, Firestore y BigQuery son tus aliados.
3. terraform destroy al terminar cada sesión. Si tu IaC es buena, cuesta un comando.
4. Nunca dejes GKE estándar encendido. Un clúster de tres nodos son ~100 €/mes.
5. Nunca dejes Dataflow en streaming encendido. Factura 24 horas al día.
6. Cuidado con las IP estáticas reservadas y sin usar, que cuestan aunque no hagan nada.
7. Revisa la facturación dos veces por semana. Treinta segundos.

Y una advertencia que hay que decir claramente: una clave de cuenta de servicio filtrada en un repositorio público puede ser usada por terceros para minar criptomonedas en tu proyecto, con facturas de miles de euros en horas. Es un incidente documentado y frecuente. Por eso RNF-3 de este módulo era cero claves JSON: no es purismo, es tu tarjeta de crédito.

Lo que hace destacar un portafolio no es la cantidad, es la profundidad de uno solo. Un proyecto con arquitectura documentada, ADR, pruebas, SLO y coste medido vale más que ocho repositorios con un hello world desplegado.

Y el atajo más eficaz, que casi nadie usa: si ya trabajas en tecnología, propón en tu empresa el primer proyecto en la nube. Migrar un servicio interno, montar un entorno de pruebas, automatizar algo con Terraform. Experiencia real, en tu currículum, sin cambiar de trabajo. Es la vía más rápida con diferencia.

Pregúntate qué parte del proyecto del módulo 8 disfrutaste:

Y no te agobies con la elección: los perfiles no son jaulas. La mayoría de la gente cambia una o dos veces, y todo lo aprendido transfiere.

Google Cloud publica cambios constantemente. Es imposible seguirlo todo, y tampoco hace falta.

La regla práctica: para un proyecto que vaya a durar, usa servicios en GA con al menos un año de vida. La novedad es divertida y cara.

La consola cambia. Los nombres cambian —Stackdriver pasó a ser Cloud Operations, AI Platform pasó a ser Vertex AI—. Los servicios se deprecan: Deployment Manager, Cloud Source Repositories.

Lo que no cambia:

• El principio de mínimo privilegio.
• La diferencia entre plano operativo y plano analítico.
• Que el estado hay que guardarlo en algún sitio con bloqueo.
• Que un sistema sin observabilidad es un sistema que no sabes si funciona.
• Que la reversión es más valiosa que el despliegue perfecto.
• Que el coste es un requisito de diseño.
• Que las decisiones se documentan porque las personas se olvidan.

Eso es lo que se transfiere entre nubes, entre empresas y entre décadas. Si de este curso te quedas con siete cosas, que sean esas siete.

Prácticamente todo lo conceptual, con nombres distintos:

Y transfiere entero todo lo que no es un producto: mínimo privilegio, IaC, SLO, presupuestos de error, canario, ciclo de vida del dato, atribución de coste, ADR. Aprender la segunda nube cuesta una fracción de lo que costó la primera, típicamente unas semanas para ser productivo.

• La mecánica. Comandos, nombres de roles, límites, comportamientos concretos. Se reaprende.
• Los modelos de red. La VPC de GCP es global; la de AWS es regional. Es una diferencia conceptual real, no cosmética.
• Los modelos de identidad. El IAM de AWS con políticas JSON y el de GCP con roles y jerarquía se parecen menos de lo que parece.
• La filosofía. GCP tiende a lo gestionado y opinado; AWS ofrece más piezas y más responsabilidad. Ninguna es mejor: son enfoques distintos.

Para tu carrera: especialízate en una y conoce las otras. Ser bueno en una nube vale más que ser mediocre en tres.

Para una arquitectura: la multinube real —la misma carga funcionando en dos proveedores— es cara y compleja, y casi nunca compensa. Lo que sí es habitual y razonable es usar servicios distintos de proveedores distintos para cosas distintas.

Es exactamente el razonamiento del ADR-004 de AlpinaShop, cuando decidió no adoptar la plataforma híbrida: la portabilidad tiene un precio, y hay que estar seguro de que se va a usar.

Vuelve al principio, por un momento.

En el módulo 1, AlpinaShop era una tienda de material de montaña con cuarenta personas, una tienda física en Sabadell y una plataforma alojada en un servidor alquilado que se caía los días de campaña. Marta administraba ese servidor a mano. Dani desplegaba subiendo ficheros. Lucía sacaba informes exportando a hojas de cálculo. Nadie sabía cuánto costaba realmente atender un pedido.

Y mira dónde acabaron.

La plataforma corre en Cloud Run, sin una sola máquina virtual en la ruta de servicio —la promesa que se hizo en el módulo 2 con DA-001 y que tardó cinco módulos en cumplirse—. Los datos viven en una base gestionada con alta disponibilidad y en un almacén analítico que Lucía consulta sin pedir permiso a nadie. La red es una VPC compartida con conectividad híbrida real hacia Sabadell y un perímetro que impide que los datos salgan. Cada despliegue pasa por pruebas, se promociona con aprobación y se puede deshacer en segundos. Hay paneles, alertas, trazas y SLO con presupuesto de error, que es lo que convirtió "va lento" en una conversación con números. Hay un plan de recuperación probado, que encontró cinco problemas que nadie sospechaba. Y hay políticas de organización que convierten los acuerdos en controles: hoy, en AlpinaShop, no se puede crear una clave permanente aunque se quiera.

La factura pasó de 1.058 € a 425 € al mes. El coste por pedido, de 0,88 € a 0,35 €. Pero lo que de verdad cambió no fue el número: fue que ahora se entiende.

Y por el camino viste algo que los cursos rara vez enseñan: decisiones que se deshacen. App Engine se descartó. GKE se retiró. Anthos se rechazó, con sus condiciones de revisión escritas. Un endpoint de recomendaciones se apagó porque los lotes salían más baratos. Una heurística de tres líneas resultó ser mejor línea base de lo que nadie esperaba. Un balanceador se destruyó porque costaba más que el proyecto entero.

Eso es la ingeniería real. No es acertar a la primera: es decidir con la información que hay, escribir por qué, y tener el criterio de cambiar de opinión cuando el contexto cambia.

Y después está lo que has hecho tú.

Elegiste un problema. Lo acotaste, con exclusiones escritas que te salvaron de un alcance imposible. Lo diseñaste antes de teclear, porque el projectId no se cambia. Estimaste el coste antes de gastar un euro y, probablemente, esa estimación te obligó a cambiar la arquitectura — que es exactamente para lo que sirve. Construiste en orden: red antes que aplicación, identidad antes que datos, un despliegue a mano antes de automatizarlo. Escribiste una prueba que falló y te obligó a hacerlo bien. Destruiste tu entorno entero y lo volviste a levantar. Auditaste tu propia seguridad y encontraste algo. Provocaste una alerta para comprobar que llegaba. Ensayaste una reversión con cronómetro. Y lo contaste, con números, incluyendo lo que no funcionó.

Nada de eso es un ejercicio. Es el trabajo. Es literalmente lo que hace un ingeniero de la nube un martes por la tarde, con la única diferencia de que allí hay más gente, más presión y más dinero en juego. La mecánica es la que acabas de practicar.

Queda muchísimo por delante. Kubernetes de verdad, migraciones reales, equipos, guardias, sistemas que llevan diez años funcionando y que nadie se atreve a tocar. La plataforma cambiará: algunos servicios que has estudiado se llamarán de otra manera dentro de tres años y alguno habrá desaparecido. Eso no es un problema, es la profesión.

Porque lo que se queda no son las pantallas. Lo que se queda es saber que el mínimo privilegio duele al principio y no duele nunca más; que un log que el administrador puede borrar no sirve como prueba; que la restauración que no se ha ensayado no existe; que un SLO sin presupuesto de error es un número decorativo; que el coste es un requisito de diseño y no una factura que llega; y que la decisión que no escribiste el día que la tomaste, no la vas a recordar.

Sabes construir un sistema completo en la nube, de principio a fin, y sabes explicar por qué está hecho así.

Eso no te lo quita nadie.

Ahora ve y constrúyelo otra vez, con algo que importe.

Coleccionar certificaciones sin proyectos. Un currículum con tres certificaciones y ningún repositorio se desmonta en la primera pregunta técnica. Alterna: certificación, proyecto, certificación.

Ir directo a una profesional saltándose la ACE. Las profesionales asumen que sabes operar la plataforma. Sin esa base, se estudia el doble y se aprueba peor.

Estudiar solo con vídeos. El examen pregunta comandos. Los comandos se aprenden escribiéndolos.

Usar volcados de preguntas. Incumple el acuerdo del examen y produce una certificación que no puedes sostener.

Dejar recursos encendidos mientras estudias. El laboratorio de la semana 3 con un GKE olvidado cuesta más que el examen.

Esperar a "estar preparado" para buscar trabajo. Nunca lo estarás del todo. Con este curso y un proyecto ya puedes optar a puestos junior.

Descuidar el proyecto una vez terminado. Un README con números y un repositorio ordenado siguen trabajando por ti meses después.

Consejo: apunta la fecha del examen antes de sentirte listo. Una fecha concreta organiza ocho semanas de estudio como no lo hace ninguna buena intención.

Consejo: si ya trabajas en tecnología, propón el primer proyecto de nube en tu empresa. Es la vía más rápida a experiencia real que existe, y casi nadie la usa.

Consejo: escribe sobre lo que has hecho. Un artículo contando cómo resolviste el peering de Cloud SQL o por qué elegiste Cloud Run vale como demostración pública de criterio, y a ti te obliga a entenderlo mejor.

Consejo: repite la reconstrucción desde cero cada pocos meses. Es el mejor recordatorio de que tu proyecto sigue vivo, y descubrirás lo que ha cambiado en la plataforma.

Haz tu propio mapa honesto usando las tres tablas de la sección 1: lo que dominas, lo que has visto pero no dominas y lo que ni se ha tocado, adaptado a lo que tú has hecho de verdad en tu proyecto (no a lo que aparece en el temario). Sitúate en la escala de calibración y justifícalo con evidencia concreta de tu propio trabajo.

Después, decide y escribe: qué certificación vas a hacer y por qué esa, con qué fecha objetivo, y qué perfil profesional te encaja según qué parte del proyecto disfrutaste.

Descarga la guía oficial del examen que hayas elegido y cruza su temario, área por área, con lo que has visto en este curso, marcando qué está cubierto, qué está parcial y qué falta. Haz el examen de muestra oficial sin estudiar y apunta tu porcentaje y tus áreas más débiles.

Con eso, adapta el plan de ocho semanas de la sección 3 a tus huecos reales y a tu disponibilidad, semana a semana, con actividades concretas y verificables (no "estudiar redes", sino "crear un balanceador de cada tipo y anotar en qué se diferencian").

Repasa tu repositorio como lo vería un desconocido: README con los números arriba, deuda técnica visible y priorizada, instrucciones que funcionan copiadas y pegadas, y los enlaces a la demostración —o al vídeo, si lo apagaste— visibles.

Escribe tu descripción profesional de dos líneas y los 90 segundos memorizados. Y elige un problema concreto que resolviste durante el proyecto —el peering, la deduplicación de eventos, el pool de conexiones, el bucket público— y escribe sobre él quinientas palabras: qué pasaba, qué probaste, qué era en realidad y qué aprendiste.

Solución 1 — El diagnóstico del autor de RefugioReserva

Mapa honesto, ajustado a lo hecho de verdad:

Calibración: practicante, sin duda. La evidencia es que construí un sistema completo solo, pero también que si mañana me piden depurar un clúster de GKE en producción, no sabría por dónde empezar.

Decisión: Associate Cloud Engineer, fecha objetivo en diez semanas (ocho de estudio más dos de colchón), inscripción hecha en la semana 2 para que la fecha sea real.

Perfil: lo que más disfruté fue el Terraform, el pipeline y el momento de ver llegar la alerta. Lo que menos, la interfaz de la aplicación. SRE / DevOps, y a medio plazo la Professional Cloud DevOps Engineer.

Solución 2 — Diagnóstico y plan de estudio

Examen de muestra sin estudiar: 62 % (13 de 21). Los fallos, agrupados:

Coincide casi exactamente con el diagnóstico de la tabla de correspondencia de la sección 3: los huecos son Compute Engine, GKE y la sintaxis de comandos.

Plan adaptado (7 semanas, 6 h/semana, con Compute Engine y GKE reforzados):

La regla que hace funcionar este plan: cada semana termina con un terraform destroy o el borrado manual de lo creado. En siete semanas de estudio, el coste total fue de 4,10 €, casi todo del clúster de GKE de las semanas 3 y 4.

Resultado del segundo simulacro: 88 %. Del tercero: 91 %. Examen aprobado.

Solución 3 — El portafolio

Descripción profesional (dos líneas):

Construyo y opero plataformas en Google Cloud: Terraform, Cloud Run, Cloud SQL, BigQuery y CI/CD sin claves. Proyecto propio completo, documentado y medido: 10 €/mes, reconstruible desde cero en 14 minutos → github.com/usuario/refugioreserva

Lo que se corrigió al revisar el repositorio con ojos ajenos:

1. El enlace de la demostración apuntaba a un sistema apagado. Sustituido por el vídeo, con una nota explicando que se apagó a propósito y que se reconstruye en 14 minutos.
2. El bloque de "levantarlo desde cero" no decía que hacen falta una cuenta de facturación y un dominio. Añadida una sección de requisitos previos.
3. Los números estaban en la sección 5 del README. Subidos justo debajo del título.
4. Las 14 capturas estaban en docs/evidencias/ sin ningún índice. Añadido un README en ese directorio explicando qué demuestra cada una.

El artículo elegido: "Mis eventos llegaban duplicados a BigQuery y el cuadro de mando mentía un 12 %". Se eligió ese entre los cuatro candidatos por tres razones: el síntoma era invisible (nada fallaba), la causa es un concepto fundamental y mal entendido (la entrega "al menos una vez" de Pub/Sub), la solución es una línea de código (row_ids), y la lección es general —contrasta siempre el almacén analítico contra el operativo—. Quinientas palabras, un fragmento de código, una tabla con las cifras antes y después.

Es exactamente el tipo de artículo que un entrevistador lee entero: concreto, con un problema real y una lección transferible.

Aquí termina el curso.

Sabes dónde estás: en el nivel de practicante, capaz de construir un sistema completo tú solo, con un mapa honesto de lo que dominas, de lo que has visto sin dominar —GKE, Dataflow, Vertex AI, redes avanzadas— y de lo que ni se ha tocado: migraciones reales, FinOps a escala, cumplimiento normativo, trabajo en equipo sobre la misma infraestructura y guardias.

Conoces el itinerario de certificaciones completo, con para quién es cada una, qué mide, qué experiencia asume y en qué orden tienen sentido, con sus tres reglas: no saltarse la ACE, no confundir Cloud Digital Leader con un paso previo, y una profesional cada vez con experiencia real entre medias.

Tienes el plan detallado de la Associate Cloud Engineer: sus cinco áreas con su peso, la tabla de correspondencia que dice qué cubre este curso —entre el 70 y el 80 %— y cuáles son los tres huecos reales (Compute Engine en profundidad, GKE con kubectl de verdad y la sintaxis exacta de los comandos), los recursos que valen la pena, el plan de ocho semanas con la semana de simulacros como la que decide, y los consejos de formato, incluida la advertencia de que caduca a los dos años.

Sabes qué valen y qué no valen las certificaciones: pasan filtros, estructuran el estudio, cubren huecos y valen dinero a las consultoras; pero no sustituyen a la experiencia, no garantizan un puesto, no demuestran que sepas construir y caducan. Y sabes cuál es la combinación que funciona —certificación, proyecto y capacidad de explicarlo— y cuál elegirías si solo pudieras tener una.

Sabes construir experiencia real sin un trabajo en la nube: proyectos propios que no son de juguete, contribuciones, escritura, el nivel gratuito con sus siete reglas de no gastar dinero —incluida la razón por la que las claves JSON son tu tarjeta de crédito—, un portafolio con profundidad en lugar de cantidad, y el atajo que casi nadie usa: proponer el primer proyecto de nube en la empresa donde ya trabajas.

Conoces los cinco perfiles con lo que hace cada uno realmente en el día a día, qué estudiar para cada camino y cómo elegir mirando qué parte de tu proyecto disfrutaste. Y sabes que los perfiles no son jaulas.

Sabes mantenerte al día sin ahogarte: las notas de versión de lo que usas como única fuente obligatoria, los avisos de deprecación como los que obligan a actuar, cómo distinguir un anuncio en preview de una herramienta madura, y por qué conviene aprender conceptos y no pantallas —porque la consola cambia, los nombres cambian y los servicios se deprecan, pero el mínimo privilegio, la separación entre plano operativo y analítico, la reversión, el coste como requisito y la decisión documentada no cambian nunca.

Y sabes qué transfiere a AWS y Azure y qué no: todo lo conceptual con nombres distintos, nada de la mecánica; que la segunda nube cuesta una fracción de la primera; y que para una carrera vale más ser bueno en una que mediocre en tres.

Has recorrido ocho módulos. Has seguido a AlpinaShop desde un servidor alquilado que se caía los días de campaña hasta una plataforma que se construye sola, se observa sola y se gobierna con controles en lugar de con buena voluntad. Has visto tomar decisiones y también deshacerlas. Y después has construido lo tuyo, de principio a fin, con tus manos, tus decisiones y tus números.

Lo que te llevas no es una lista de servicios de Google Cloud. Es la forma de pensar que hay detrás: decidir con la información disponible, escribir por qué, medir en lugar de opinar, aceptar restricciones como parte del diseño, probar lo que afirmas y reconocer lo que no funcionó.

Eso sirve en esta nube, en la siguiente y en la que venga después.

Suerte. Y a construir.