Semana 1 · Módulo 1 de 12

Fundamentos de Google Cloud: jerarquía, facturación, IAM y herramientas

Montas la base de todo el curso. Cómo se organiza Google Cloud (regiones, zonas, organización, carpetas y proyectos), cómo se paga y se vigila el gasto, cómo funciona IAM, con qué herramientas se trabaja y cómo razona un arquitecto ante una pregunta del examen.

Reparto de la semana

Por qué importa

Este módulo no es «relleno de introducción». Casi todas las preguntas del examen dan por hecho que dominas cuatro ideas que se ven aquí:

1. Dónde vive cada recurso (zona, región o global) y qué pasa si esa ubicación falla.
2. Cómo se organiza una empresa en Google Cloud (organización, carpetas, proyectos) y cómo se heredan los permisos y las políticas.
3. Quién puede hacer qué (IAM) y el principio de mínimo privilegio, que es la respuesta correcta en una cantidad sorprendente de preguntas.
4. Cuánto cuesta y cómo se controla el gasto, porque casi todos los enunciados incluyen «minimizar costes» o «reducir la carga operativa».

Además, la guía del examen dice que el Google Cloud Well-Architected Framework está «implícita y explícitamente» presente en todos los objetivos. Lo introducimos esta semana y lo usaremos como marco en el resto del curso.

El modelo de Google Cloud

Qué es la nube, en una frase útil

La nube pública es alquilar capacidad de cómputo, almacenamiento, red y servicios gestionados a un proveedor, bajo demanda, pagando por uso y a través de APIs. Lo que cambia respecto a un centro de datos propio no es solo «dónde están las máquinas», sino tres cosas que el examen explota continuamente:

• Elasticidad: puedes crecer y decrecer en minutos, así que diseñas para la demanda real y no para el pico del año.
• Gasto operativo (OpEx) en lugar de inversión (CapEx): no compras hardware; pagas lo que consumes. Esto aparece en el apartado 4.2 del examen.
• Responsabilidad compartida: Google protege la infraestructura física, la red global y los servicios; tú eres responsable de la configuración, las identidades, los datos y, según el servicio, del sistema operativo y la aplicación.

Los modelos de servicio de siempre también te sirven para clasificar productos:

Cuanto más a la derecha de la escala (hacia serverless), menos operación y menos control. El examen premia casi siempre la opción más gestionada que cumpla los requisitos.

Regiones, zonas y la red global

• Una región es un área geográfica independiente, por ejemplo europe-southwest1 (Madrid) o europe-west1 (Bélgica).
• Una zona es un área de despliegue dentro de una región, con nombre región-letra: europe-southwest1-a, europe-southwest1-b… Piensa en ella como un dominio de fallo: una avería de zona no debería afectar a las demás zonas de la región.
• Según la página oficial de ubicaciones (actualizada en septiembre de 2026), Google Cloud tiene 43 regiones y 130 zonas, y las regiones tienen normalmente tres o más zonas. Estas cifras cambian a menudo; el examen no te preguntará el número exacto, sino cómo usar zonas y regiones para diseñar alta disponibilidad.

Google Cloud funciona sobre la red privada global de Google: fibra terrestre y submarina propia y más de 200 ubicaciones perimetrales (edge). Dos consecuencias importantes para el examen:

• El tráfico entre regiones de Google Cloud viaja por la red de Google, no por internet público.
• Algunos productos son globales de verdad gracias a esa red: una VPC es global (sus subredes son regionales), y el balanceador de carga de aplicaciones externo global ofrece una única IP anycast para todo el mundo. Lo verás en los módulos de redes.

Recursos globales, regionales y zonales

Cada recurso tiene un ámbito. Es de lo más preguntado, porque determina qué falla junto con qué:

flowchart TB
  G["Global: red VPC, imágenes, balanceador global"]
  G --> R1["Región europe-southwest1 (Madrid)"]
  G --> R2["Región europe-west1 (Bélgica)"]
  R1 --> Z1["Zona europe-southwest1-a: VMs y discos zonales"]
  R1 --> Z2["Zona europe-southwest1-b"]
  R1 --> Z3["Zona europe-southwest1-c"]
  R1 --> S1["Subred regional y MIG regional"]

Cómo se elige una región: latencia hacia los usuarios, requisitos legales de ubicación de los datos (soberanía, RGPD), disponibilidad del producto en esa región (no todos los servicios están en todas) y precio (varía por región).

Jerarquía de recursos

Los cuatro niveles

Google Cloud organiza los recursos en un árbol:

flowchart TB
  O["Organización: ejemplo.com"]
  O --> F1["Carpeta: Producción"]
  O --> F2["Carpeta: No producción"]
  O --> F3["Carpeta: Compartido"]
  F1 --> P1["Proyecto: tienda-prod"]
  F1 --> P2["Proyecto: datos-prod"]
  F2 --> P3["Proyecto: tienda-dev"]
  F3 --> P4["Proyecto: red-host"]
  P1 --> RS1["Recursos: VMs, buckets, bases de datos"]
  P3 --> RS2["Recursos"]

• Organización (organization): el nodo raíz de la empresa. Se asocia a un dominio gestionado con Google Workspace o Cloud Identity. Sin uno de los dos, no hay organización: tus proyectos quedan «sin organización» (lo normal en una cuenta personal de prueba).
• Carpetas (folders): agrupan proyectos y otras carpetas. Sirven para modelar departamentos, entornos (producción, desarrollo) o unidades de negocio, y para aplicar permisos y políticas en bloque.
• Proyectos (projects): la unidad básica. Todo recurso pertenece a exactamente un proyecto. En el proyecto se habilitan las APIs, se asocia la facturación, se aplican las cuotas y se gestionan los permisos.
• Recursos: VMs, buckets, datasets, etc.

Cada recurso tiene un único padre. Esto es lo que permite la herencia: las políticas IAM y las políticas de organización que pones en un nodo se aplican a todo lo que cuelga de él.

Identificadores de un proyecto

Un proyecto tiene tres identificadores y el examen espera que sepas distinguirlos:

Casi todos los comandos gcloud y APIs usan el Project ID.

Borrar un proyecto

Al borrar (shut down) un proyecto entra en eliminación pendiente durante 30 días: los recursos se detienen, se deja de facturar el uso y puedes restaurarlo en ese plazo. Pasado el plazo se elimina de forma definitiva. Mientras está pendiente, sigue contando para tu cuota de proyectos. Es la forma más segura de limpiar un lab: borras el proyecto y desaparece todo lo que contenía.

Cómo diseñar la jerarquía

No hay una única respuesta correcta, pero sí criterios:

• Proyectos separados por entorno y por aplicación (tienda-prod, tienda-dev). Aíslan permisos, cuotas, facturación y el «radio de explosión» de un error.
• Carpetas que reflejen cómo se gobierna la empresa: si los permisos y las políticas se deciden por entorno, carpetas por entorno; si se deciden por unidad de negocio, carpetas por unidad de negocio (y dentro, por entorno).
• Políticas en el nivel más alto que tenga sentido, para no repetirlas proyecto a proyecto.
• Proyectos compartidos para servicios comunes (red compartida, registro centralizado, seguridad).

La jerarquía también es la base de las políticas de organización (Organization Policy Service): restricciones que se heredan, por ejemplo «solo se pueden crear recursos en regiones de la UE» o «prohibido crear claves de cuentas de servicio». Las verás en el módulo de seguridad; por ahora quédate con que IAM dice quién puede hacer qué y las políticas de organización dicen qué se puede hacer, lo haga quien lo haga.

Para clasificar recursos tienes además etiquetas (labels), pares clave-valor que se usan sobre todo para desglosar costes (equipo=pagos, entorno=prod), y tags, que se pueden usar en condiciones de políticas IAM y de firewall.

Facturación y control de costes

Cuentas de facturación

Una cuenta de facturación de Cloud (Cloud Billing account) define quién paga y cómo. Un proyecto se vincula a una cuenta de facturación; una cuenta de facturación puede pagar muchos proyectos. Un proyecto sin cuenta de facturación solo puede usar servicios gratuitos, y si desvinculas la facturación de un proyecto, sus recursos de pago se detienen.

Hay dos modalidades:

• Autoservicio (self-serve / online): pagas con tarjeta o cuenta bancaria. Es la que tendrás en la prueba.
• Facturada (invoiced / offline): factura mensual, para empresas que cumplen ciertos requisitos.

Roles de facturación clave (se conceden sobre la cuenta de facturación, no sobre el proyecto):

Separar quién paga (finanzas) de quién despliega (desarrollo) es un ejemplo clásico de separación de funciones del apartado 3.1.

Presupuestos y alertas

Un presupuesto (budget) compara el gasto con un importe y avisa al superar umbrales. Lo esencial:

• Un presupuesto no detiene el gasto. Solo avisa. Si quieres cortar automáticamente, necesitas notificaciones programáticas: el presupuesto publica en un tema de Pub/Sub y una función (por ejemplo, en Cloud Run functions) reacciona, por ejemplo desvinculando la facturación del proyecto. Ojo: desvincular la facturación para los recursos y puede provocar pérdida de datos.
• Los umbrales predeterminados son 50 %, 90 % y 100 % del importe, sobre gasto real. También puedes usar umbrales sobre gasto previsto (forecasted), que avisan antes de que ocurra.
• Por defecto, los correos llegan a los Billing Account Administrators y Billing Account Users de la cuenta. Para otros destinatarios usas canales de notificación de Cloud Monitoring.
• El ámbito puede ser toda la cuenta, ciertos proyectos, ciertos servicios o recursos con ciertas labels.
• Por defecto el cálculo incluye créditos y descuentos. Puedes excluirlos para vigilar el coste «bruto».
• Los datos de coste llegan con cierto retraso; no esperes una alerta al minuto.

Exportación de facturación a BigQuery

Para análisis de verdad (costes por equipo, por label, por SKU, tendencias) se activa la exportación de datos de Cloud Billing a BigQuery. Tipos principales:

• Standard usage cost: coste por cuenta, servicio, SKU, proyecto, labels.
• Detailed usage cost: añade el detalle por recurso (por ejemplo, por VM).
• Pricing: precios de los SKUs.
• Hay además exportaciones en preview, como la normalizada con el estándar FOCUS de FinOps.

La documentación recomienda activarla al crear la cuenta de facturación, porque apenas hay datos retroactivos: con un dataset multirregional (EU o US) se incluye desde el inicio del mes anterior; con uno regional, solo desde que la activas. Después puedes visualizarlo con Data Studio (antes Looker Studio).

Cuenta de prueba y nivel gratuito

Son dos cosas distintas:

Algunos límites del nivel gratuito (consulta la página oficial antes de fiarte, porque cambian): una VM e2-micro no interrumpible al mes en us-west1, us-central1 o us-east1 con 30 GB-mes de disco estándar; 5 GB-mes de Cloud Storage regional en regiones de EE. UU.; 2 millones de peticiones al mes en Cloud Run y 2 millones de invocaciones en Cloud Run functions; 1 TiB de consultas y 10 GiB de almacenamiento al mes en BigQuery; un cluster Autopilot o Standard zonal de GKE sin tarifa de gestión al mes; y Cloud Shell gratis con 5 GB de disco persistente.

Descuentos: uso sostenido y compromisos

Dos mecanismos que conviene conocer ya (volverás a ellos en cómputo y en optimización de costes):

• Sustained use discounts (SUDs, descuentos por uso sostenido): automáticos, sin hacer nada. Se aplican a algunas series antiguas cuando una VM funciona gran parte del mes: N1, N2, N2D, C2, M1, M2 y nodos sole-tenant. El máximo es del 30 % (N1, M1, M2) o del 20 % (N2, N2D, C2). E2 y las series modernas no los tienen, porque su precio base ya es más bajo.
• Committed use discounts (CUDs, descuentos por compromiso de uso): te comprometes a 1 o 3 años a cambio de descuento. Hay dos tipos:
  • Basados en recursos (resource-based): te comprometes a una cantidad de vCPU, memoria, GPU o SSD local en una región concreta. Solo para Compute Engine. Hasta un 55 % en la mayoría de series y hasta un 70 % en las de memoria optimizada.
  • Basados en gasto (spend-based, «flexibles»): te comprometes a un gasto por hora; se aplican a varios productos (Compute Engine, Cloud Run, Cloud SQL, BigQuery, Spanner…) y son más flexibles en cuanto a series y regiones.
  • Un compromiso no se puede cancelar tras comprarlo.

Regla de examen: carga estable y predecible durante años → CUD; carga variable o tolerante a interrupciones → autoescalado y Spot VMs; no sabes aún cómo será la carga → no te comprometas todavía.

IAM: quién puede hacer qué

Identity and Access Management (IAM) responde a la pregunta «quién (principal) puede hacer qué (rol) sobre qué recurso».

Principales

Un principal es una identidad a la que se concede acceso:

• Cuenta de Google (una persona): ana@ejemplo.com.
• Grupo de Google: devs@ejemplo.com. Es la forma recomendada de conceder acceso a personas: das el rol al grupo y gestionas la pertenencia al grupo, no los permisos de cada persona.
• Cuenta de servicio (service account): identidad para aplicaciones y cargas, no para personas.
• Dominio de Google Workspace o Cloud Identity: todos los usuarios del dominio.
• Identidades federadas (Workforce Identity Federation para personas de un IdP externo, Workload Identity Federation para cargas de otras nubes o CI/CD). Las verás en seguridad.
• Valores especiales como allUsers (cualquiera en internet) y allAuthenticatedUsers (cualquier cuenta de Google). Peligrosos: solo para contenido público de verdad.

Roles y permisos

Un permiso tiene el formato servicio.recurso.verbo, por ejemplo compute.instances.start. Nunca se conceden permisos sueltos: se conceden roles, que son conjuntos de permisos. Hay tres tipos:

Sobre los roles básicos, un matiz de actualidad: la documentación vigente presenta como roles básicos Admin (roles/admin), Writer (roles/writer) y Reader (roles/reader) y califica de legacy a los clásicos Owner (roles/owner), Editor (roles/editor) y Viewer (roles/viewer). En el examen y en la mayoría de materiales verás todavía Owner/Editor/Viewer. La idea que importa es la misma: son demasiado amplios.

Políticas y herencia

Los roles se conceden mediante una política de permiso (allow policy) asociada a un recurso: una lista de bindings «rol → principales», opcionalmente con condiciones (por ejemplo, solo hasta una fecha o solo para recursos con cierto prefijo).

Reglas de la herencia:

• La política efectiva de un recurso es la unión de su política y las de todos sus antecesores (proyecto, carpetas, organización).
• No puedes quitar en un nivel inferior lo que se concede en uno superior con políticas de permiso. Si das roles/editor en la organización, lo tendrás en todos los proyectos.
• Para restringir explícitamente existen las políticas de denegación (deny policies), que se evalúan antes que las de permiso. Son un recurso más avanzado (módulo de seguridad).

Por eso los roles amplios se conceden abajo (proyecto o recurso) y solo los muy concretos arriba (por ejemplo, un grupo de auditoría con permisos de lectura en la organización).

Cuentas de servicio

Una cuenta de servicio es una identidad para software. Su correo tiene la forma nombre@ID-PROYECTO.iam.gserviceaccount.com. Tipos:

• Gestionadas por el usuario: las creas tú. Lo recomendado: una por aplicación o función, con solo los roles que necesita.
• Predeterminadas: se crean al habilitar ciertos servicios, como la de Compute Engine (NÚMERO-compute@developer.gserviceaccount.com). Históricamente reciben el rol Editor en el proyecto, algo demasiado amplio; la política de organización iam.automaticIamGrantsForDefaultServiceAccounts evita esa concesión automática. Buena práctica: no uses la cuenta predeterminada en producción; crea una propia.
• Agentes de servicio (service agents): las gestiona Google para que los servicios actúen en tu nombre.

Una cuenta de servicio es a la vez identidad (tiene roles sobre recursos) y recurso (hay roles sobre ella: quién puede usarla o suplantarla). Dos roles clave sobre la cuenta de servicio:

• roles/iam.serviceAccountUser: permite asignar la cuenta a un recurso (por ejemplo, crear una VM que se ejecute como esa cuenta).
• roles/iam.serviceAccountTokenCreator: permite suplantarla (impersonation) y obtener credenciales de corta duración.

Claves de cuenta de servicio: son ficheros JSON con credenciales de larga duración. Son un riesgo de seguridad (se filtran en repositorios, no caducan). La documentación recomienda usar alternativas siempre que sea posible: la cuenta asignada al recurso (la VM o el servicio de Cloud Run «es» la cuenta), la impersonación para personas y Workload Identity Federation para cargas fuera de Google Cloud.

Mínimo privilegio en la práctica

1. Concede a grupos, no a personas.
2. Usa roles predefinidos lo más concretos posible; personalizados solo si hace falta.
3. Concede en el nivel más bajo de la jerarquía que funcione (recurso o proyecto antes que carpeta u organización).
4. Una cuenta de servicio por carga, sin claves.
5. Revisa permisos sobrantes: el IAM Recommender sugiere quitar permisos no usados.
6. Audita con Cloud Audit Logs: los registros de Admin Activity (cambios de configuración) están siempre activos y se guardan 400 días; los de Data Access (lecturas y cambios de datos) están desactivados por defecto salvo en BigQuery y se guardan 30 días en el bucket _Default.

Formas de interactuar con Google Cloud

Todo en Google Cloud es una API. La consola, gcloud, Terraform y las bibliotecas cliente son solo distintas formas de llamarla.

Consola

La Google Cloud console es la interfaz web. Ideal para explorar, aprender y ver el estado de las cosas. Mala para repetir tareas: no deja rastro reproducible. En el examen, «hacerlo a mano en la consola» casi nunca es la respuesta a un problema operativo recurrente.

Cloud Shell y Cloud Shell Editor

Cloud Shell es un terminal en el navegador sobre una VM Debian temporal que Google gestiona:

• Viene con gcloud, kubectl, bq, git, docker, Terraform, editores y lenguajes habituales ya instalados, y autenticado con tu usuario.
• Tiene 5 GB de disco persistente en $HOME. Si no usas Cloud Shell en 120 días, se borra tu $HOME (avisan antes por correo).
• La sesión termina tras una hora de inactividad y como máximo a las 12 horas; la cuota semanal por defecto es de 50 horas.
• Existe un modo efímero que arranca más rápido pero no guarda nada.
• Cloud Shell Editor es un IDE web (basado en Code OSS) integrado en Cloud Shell, con soporte de Cloud Code para Kubernetes y Cloud Run. Aparece en el apartado 5.2 del examen.

Es gratis y es donde harás todos los labs.

Google Cloud CLI (gcloud) y configuraciones

La Google Cloud CLI incluye gcloud (casi todos los servicios), bq (BigQuery) y gsutil (Cloud Storage, heredado: hoy se recomienda gcloud storage, pero gsutil aparece en la guía del examen). Patrón de los comandos:

gcloud GRUPO [SUBGRUPO] RECURSO VERBO [argumentos] [--flags]
gcloud compute instances list --project=mi-proyecto
gcloud run services describe web --region=europe-southwest1

Las propiedades (proyecto, región, zona, cuenta) se guardan en configuraciones con nombre, que te permiten cambiar de contexto sin repetir flags:

gcloud config configurations create curso-pca
gcloud config set project pca-lab-02
gcloud config set compute/region europe-southwest1
gcloud config set compute/zone europe-southwest1-a
gcloud config configurations list
gcloud config configurations activate default

Autenticación: gcloud auth login autentica la CLI con tu usuario; gcloud auth application-default login crea las Application Default Credentials (ADC) que usan las bibliotecas cliente en tu máquina. En Cloud Shell ambas cosas ya están resueltas.

Bibliotecas cliente y buenas prácticas de acceso a APIs

Las Google Cloud client libraries (Python, Java, Go, Node.js, C#, etc.) son la forma recomendada de llamar a las APIs desde código: gestionan autenticación, reintentos y paginación. Buscan credenciales mediante ADC: en Google Cloud usan la cuenta de servicio asociada al recurso; en tu portátil, las credenciales de gcloud auth application-default login. Así el mismo código funciona en ambos sitios sin claves en ficheros.

Otras buenas prácticas que el examen puede plantear: reintentos con retroceso exponencial ante errores 429 y 5xx, respetar las cuotas, y usar credenciales de corta duración.

Para desarrollo local existen emuladores (Pub/Sub, Firestore, Bigtable, Spanner) que evitan coste y dependencia de la nube en las pruebas. Y para infraestructura, la opción recomendada es infraestructura como código con Terraform (módulo 10).

Habilitar APIs

Cada servicio tiene su API (compute.googleapis.com, run.googleapis.com…) y hay que habilitarla en cada proyecto antes de usarla. Si no, el primer comando falla con un error que te lo indica (a veces gcloud te ofrece habilitarla).

gcloud services list --enabled
gcloud services enable compute.googleapis.com run.googleapis.com

Habilitar una API no cuesta nada por sí mismo; cuestan los recursos que crees.

Cuotas y límites

Google Cloud limita el consumo para proteger a todos los clientes y a ti mismo de gastos accidentales:

• Cuotas (quotas): ajustables. Hay de asignación (número de vCPUs, de IPs, de VMs en una región), de tasa (peticiones a una API por minuto) y de concurrencia (operaciones simultáneas). Se aplican sobre todo por proyecto (y a veces por región).
• Límites del sistema (system limits): fijos, no se pueden cambiar (tamaños máximos, límites de esquema).
• Se consultan en la consola en IAM y administración → Cuotas y límites del sistema (Cloud Quotas). Los aumentos se piden desde ahí; muchos se evalúan de forma automática, y el Quota Adjuster puede pedirlos solo cuando detecta que te acercas al límite.
• En la prueba gratuita no puedes pedir aumentos.

El Well-Architected Framework: el marco del curso

El Google Cloud Well-Architected Framework reúne las recomendaciones de Google para diseñar y operar en su nube. Tiene seis pilares:

Además tiene perspectivas transversales, como la de IA y ML y la de servicios financieros, que aplican los pilares a esos contextos.

Úsalo como checklist mental ante cualquier diseño: si una opción mejora la fiabilidad pero dispara el coste o complica la operación, el enunciado te dirá cuál de esos pilares manda.

Cómo piensa un arquitecto en el examen

El examen no pregunta «¿qué hace el producto X?», sino «dada esta empresa y estos requisitos, qué harías». Casi todas las preguntas se resuelven con el mismo método.

Requisitos de negocio frente a requisitos técnicos

• Requisitos de negocio: lo que la empresa quiere conseguir. «Reducir costes de infraestructura un 30 %», «entrar en el mercado asiático», «cumplir la normativa sanitaria», «que los desarrolladores publiquen más rápido», «no contratar más personal de operaciones».
• Requisitos técnicos: cómo debe comportarse el sistema. «Latencia inferior a 100 ms», «RPO de 15 minutos», «escalar a 10 veces en campañas», «cifrado con claves gestionadas por el cliente».
• Funcionales frente a no funcionales: los funcionales dicen qué hace el sistema; los no funcionales (disponibilidad, rendimiento, seguridad, coste) dicen cómo de bien. El examen se centra en los no funcionales.

Los casos de estudio te dan ambas listas por separado. Aprende a traducir negocio en técnica: «no contratar más personal de operaciones» significa servicios gestionados o serverless; «expandirse a otros continentes» significa multirregión y balanceo global; «auditoría regulatoria» significa logs de auditoría, retención y control de ubicación de datos.

Trade-offs: no hay opción gratis

Cada decisión cambia unas propiedades por otras: disponibilidad por coste, control por operación, latencia por consistencia, rapidez de migración por modernización. El examen te da pistas sobre qué prioriza la empresa: «lo antes posible», «con el mínimo coste», «con mínimos cambios en el código», «sin tiempo de inactividad», «con la menor carga operativa».

Método para cada pregunta

1. Lee la última frase primero: qué se pregunta exactamente (la «mejor», la «más rentable», «dos pasos»).
2. Subraya los requisitos y restricciones: coste, latencia, cumplimiento, operación, plazos, habilidades del equipo.
3. Descarta las opciones que incumplen algún requisito explícito (una opción técnicamente brillante que no cumple la ubicación de datos está mal).
4. Entre las que quedan, elige la más gestionada, más simple y más alineada con las buenas prácticas de Google que cumpla todo.
5. Desconfía de opciones que añaden piezas innecesarias, que requieren desarrollo a medida cuando hay un servicio que lo hace, o que usan roles básicos, claves de cuentas de servicio o intervención manual.

Trampas típicas del examen

• «Presupuesto» no es «límite de gasto». Un budget solo avisa. Para cortar, Pub/Sub + automatización (y asumir sus consecuencias).
• Project ID frente a project name: el ID es único e inmutable; el nombre es solo una etiqueta editable.
• Roles básicos (Owner/Editor/Viewer) en producción casi siempre es la respuesta incorrecta. Busca el rol predefinido.
• Conceder a personas en lugar de a grupos: incorrecto a escala.
• Claves JSON de cuentas de servicio para desarrolladores o para cargas dentro de Google Cloud: incorrecto. Impersonación o cuenta asociada al recurso.
• Quitar un permiso heredado con una política de permiso en un nivel inferior: imposible. O mueves la concesión, o usas políticas de denegación.
• Roles personalizados en una carpeta: no se puede; solo en organización o proyecto.
• Organización sin Workspace ni Cloud Identity: no existe.
• «Resistir la caída de una zona» → recursos regionales o multizona; «de una región» → multirregión.
• SUDs en E2: no existen. Los descuentos automáticos solo aplican a ciertas series (N1, N2, N2D, C2, M1, M2).
• Carga estable durante años → CUD. Tolerante a interrupciones → Spot. Incierta → no te comprometas.
• «Saber cuánto gasta cada equipo» → labels + exportación de facturación a BigQuery, activada cuanto antes.
• Error de «API not enabled» → gcloud services enable, no un problema de permisos.
• Límites de despliegue inesperados → cuotas; planifica aumentos.

Resumen

• Google Cloud se organiza en regiones y zonas; cada recurso es zonal, regional o global, y eso define su dominio de fallo.
• La jerarquía es organización → carpetas → proyectos → recursos; la organización requiere Workspace o Cloud Identity, y todo se hereda hacia abajo.
• El Project ID es único e inmutable; borrar un proyecto lo deja 30 días en eliminación pendiente.
• Cuenta de facturación paga proyectos; presupuestos avisan (50/90/100 % por defecto) pero no cortan; la exportación a BigQuery se activa cuanto antes.
• Prueba gratuita: 300 USD durante 90 días con restricciones; nivel gratuito: límites mensuales permanentes.
• SUDs automáticos en algunas series; CUDs de 1 o 3 años, por recursos o por gasto, no cancelables.
• IAM: principal + rol + recurso; roles predefinidos, grupos, nivel más bajo posible, cuentas de servicio sin claves e impersonación.
• Todo es una API: consola, Cloud Shell, gcloud con configuraciones, bibliotecas cliente con ADC; las APIs se habilitan por proyecto.
• Cuotas ajustables por proyecto y límites del sistema fijos.
• Razona cada pregunta con los seis pilares del Well-Architected Framework y separando requisitos de negocio y técnicos.

Practica lo aprendido

Documentación oficial para ampliar

• Resource hierarchy
• Regions and zones
• Create and manage projects
• Create, edit, or delete budgets and budget alerts
• Export Cloud Billing data to BigQuery
• Free Trial and Free Tier
• IAM roles and permissions overview
• Service accounts overview
• Service account impersonation
• How Cloud Shell works
• Cloud Quotas overview
• Google Cloud Well-Architected Framework