Google ACE: Jerarquía de recursos, IAM y administración de facturación — Guía de estudio

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Forma parte de la Google Associate Cloud Engineer — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Google, o realiza tests cronometrados en ExamRoll.io.

Descripción general

La jerarquía de recursos, la gestión de identidades y accesos (IAM) y la administración de la facturación forman el plano de control de las operaciones de Google Cloud. Un diseño resiliente comienza con una jerarquía clara (organización, carpetas, proyectos) para delimitar las políticas y la responsabilidad; aplica el principio de privilegio mínimo en IAM con una administración centrada en grupos y credenciales de corta duración para las cargas de trabajo; utiliza presupuestos, exportaciones y etiquetas para la atribución de costos; y refuerza la gobernanza con políticas de la organización y registros de auditoría exhaustivos. La excelencia operativa proviene de estandarizar la herencia, centralizar la facturación y los registros, y usar la suplantación de identidad de cuentas de servicio en lugar de claves de larga duración. Esta sección detalla los constructos principales, su uso previsto y los modos de fallo comunes que se deben evitar.

Jerarquía de recursos y modelo de identidad

• Jerarquía de recursos

  • Organización: Nodo raíz, creado con Cloud Identity o Google Workspace. Es propietaria de las políticas globales (IAM, políticas de la organización, tags).
  • Carpetas: Agrupación opcional para departamentos, entornos (p. ej., desarrollo, producción) o aplicaciones. Útiles para la administración delegada y la delimitación de políticas.
  • Proyectos: Límite administrativo para recursos, APIs, cuotas, IAM y asociación de facturación. La mayoría de los recursos de Google Cloud son hijos de proyectos.
  • Herencia: Las políticas de IAM y las políticas de la organización se heredan de arriba hacia abajo. Las denegaciones y restricciones en niveles superiores tienen precedencia. Planifique la ubicación (organización → carpetas → proyectos) para minimizar las excepciones y las necesidades de emergencia (break-glass).

• Principales

  • Cuentas de Google (usuarios), Grupos de Google, cuentas de servicio e identidades externas a través de Workload Identity Federation.
  • Los Grupos de Google deberían ser el objetivo principal de vinculación para el acceso humano, para simplificar los cambios en el ciclo de vida y las revisiones.
  • Las cuentas de servicio representan aplicaciones o servicios; prefiera la identidad de carga de trabajo en lugar de claves.

• Identidades de cargas de trabajo

  • En Google Cloud: GCE/GAE/Cloud Run/GKE usan el servidor de metadatos para acuñar tokens de corta duración para la cuenta de servicio adjunta.
  • Fuera de Google Cloud: Workload Identity Federation mapea identidades externas (OIDC/SAML/AWS) a cuentas de servicio sin claves estáticas.

• Compromisos de diseño y modos de fallo

  • Proyectos descontrolados sin una estructura de carpetas causan duplicación y desviación de políticas.
  • Asignar roles directamente a los usuarios aumenta el trabajo manual; prefiera las vinculaciones basadas en grupos.
  • Usar la cuenta de servicio por defecto de Compute Engine con permisos amplios eleva el riesgo; cree cuentas de servicio con privilegio mínimo por cada carga de trabajo.
  • Colocar un proyecto incorrectamente bajo la carpeta equivocada hereda políticas incorrectas; use tags o mueva los proyectos cuidadosamente con un control de cambios.

Roles de IAM y diseño de políticas

• Tipos de roles

  • Roles básicos (Viewer, Editor, Owner): Amplios, heredados. Evítelos excepto para casos de emergencia (break-glass) estrictamente controlados.
  • Roles predefinidos: Seleccionados por servicio; prefiera para la mayoría de los casos de uso.
  • Roles personalizados: Agregación de permisos a nivel de organización o proyecto para necesidades a medida.
  • Roles condicionales: Las condiciones de IAM (CEL) añaden contexto como el nombre del recurso, la carpeta, los tags o la hora; úselos para restringir roles potentes.

• Principios de políticas

  • Privilegio mínimo: Conceda solo el rol mínimo en el alcance más restringido (recurso/proyecto/carpeta).
  • Separación de funciones: Divida las responsabilidades (p. ej., administrador de redes vs. administrador de seguridad vs. administrador de facturación). No acople las acciones de despliegue y aprobación en una única entidad principal.
  • Conciencia de la herencia: Una vinculación a nivel de organización/carpeta afecta a todos los descendientes; documente el radio de impacto previsto antes de aplicarla.

• Políticas de denegación (Deny)

  • IAM Deny bloquea explícitamente permisos incluso si se han concedido en otro lugar; úselas como barreras de protección (p. ej., denegar iam.serviceAccountKeys.create).
  • La denegación tiene precedencia; asegure procesos de excepción documentados y con límite de tiempo para emergencias (break-glass).

• Ejemplos

  • Copiar un rol personalizado de desarrollo a producción:

undefined

• Conceder administración SSH basada en grupos con OS Login:

undefined

• Modos de fallo
  • Un rol de Editor concedido a nivel de organización o carpeta se propaga en cascada sin querer a todos los proyectos.
  • Los roles condicionales con condiciones demasiado estrictas pueden romper automatizaciones silenciosamente; pruebe con Policy Troubleshooter antes del despliegue.
  • Los roles personalizados se quedan atrás con los nuevos permisos; revíselos periódicamente.

Administración de facturación y costos

• Cuentas de facturación y asociación

  • Un proyecto debe estar vinculado exactamente a una cuenta de facturación para los servicios facturables.
  • Roles: Billing Account Administrator gestiona la cuenta y los métodos de pago; Billing Account User vincula proyectos; Project Billing Manager gestiona el vínculo de facturación de un proyecto.
  • Centralice en una cuenta de facturación corporativa; migre proyectos actualizando la asociación de facturación del proyecto.

• Presupuestos, alertas y atribución

  • Los presupuestos generan alertas, no topes de gasto. Use la remediación programática con Pub/Sub y Cloud Functions/Cloud Run si se necesita forzar el cumplimiento.
  • Exporte los datos de facturación a BigQuery para análisis de costos y previsiones diarias/mensuales; combine con etiquetas y tags de recursos para la atribución.
  • Etiquetas y tags: Estandarice las claves (p. ej., cost_center, env, app). La falta de etiquetas reduce la precisión de la atribución.

• Análisis de costos

  • Use la exportación a BigQuery para calcular previsiones continuas por SKU/servicio con SQL. Únalo con metadatos de recursos (p. ej., etiquetas de GCE) para informes granulares.
  • Para el análisis de múltiples proyectos, agregue a través de todas las exportaciones de proyectos o exporte a un único conjunto de datos central.

• Errores comunes

  • Presupuestos no configurados para proyectos nuevos; establezca una política para crear presupuestos automáticamente al crear un proyecto.
  • No tener una exportación a BigQuery significa una visión histórica limitada; actívela pronto para construir un historial.
  • El uso de tarjetas de crédito personales en los proyectos fragmenta la responsabilidad; consolide bajo la cuenta de facturación corporativa con los perfiles de IAM y de pago adecuados.
  • Las anomalías de costos en proyectos de servicios compartidos requieren una política de etiquetado y de cargos cruzados.

Patrones de Autenticación y Acceso para Cargas de Trabajo Seguras

• Suplantación de identidad de cuentas de servicio

  • Prefiere la suplantación de identidad en lugar de las claves. Otorga el rol roles/iam.serviceAccountTokenCreator a una identidad que realiza la llamada; esta obtiene tokens de corta duración para actuar como la cuenta de servicio.
  • Ejemplo: gcloud auth print-access-token
    –impersonate-service-account sa-deployer@PROJECT_ID.iam.gserviceaccount.com

• Claves y rotación

  • Evita las claves gestionadas por el usuario. Si son necesarias, almacénalas en Secret Manager, rótalas al menos cada 90 días, monitorea su uso y restríngelas con VPC Service Controls y CMEK.
  • Aplica restricciones para bloquear la creación de claves: constraints/iam.disableServiceAccountKeyCreation = true

• OS Login y SSH

  • Usa OS Login con roles de IAM basados en grupos (compute.osLogin, compute.osAdminLogin). Cada usuario sube su clave pública SSH a su cuenta de Google para un acceso atribuible. Audita a través de los registros de Actividad del Administrador y de Acceso a los Datos.
  • Evita incrustar claves SSH compartidas en las imágenes.

• Workload Identity Federation

  • Para entornos on-premise u otras nubes, configura la federación de identidades para otorgar acceso a Google Cloud sin crear claves, reduciendo el riesgo de exfiltración.

• Modos de fallo y mitigaciones

  • Almacenar claves en repositorios o variables de CI/CD conduce a una brecha de seguridad; cambia a la suplantación de identidad o a la federación.
  • Las cuentas de servicio predeterminadas con roles amplios son riesgosas; restríngelas con constraints/iam.allowedPolicyMemberDomains y elimina los roles primitivos.
  • La falta de un scope en instancias de GCE heredadas puede bloquear el acceso a las API; prefiere usar IAM por API junto con las credenciales predeterminadas de la aplicación.

Gobernanza, políticas de la organización, auditoría y solución de problemas

• Políticas y restricciones de la organización

  • Aplicar barreras de protección (guardrails) usando restricciones: no permitir IP externas en VM, restringir regiones, impedir la creación de claves, restringir los servicios permitidos, requerir acceso uniforme a nivel de bucket, restringir el uso compartido de dominios.
  • Apuntar por jerarquía de recursos y refinar con etiquetas (tags) para excepciones específicas del entorno.

• Cloud Identity y ciclo de vida

  • Cloud Identity proporciona el directorio de usuarios, SSO y roles administrativos. Delegar de forma restringida (p. ej., Group Admin, User Management Admin) y automatizar los flujos de trabajo de altas, cambios y bajas (joiner-mover-leaver) para actualizar la membresía de grupos y el acceso.
  • Usar Access Approvals y Access Transparency para entornos sensibles.

• Registro de auditoría

  • Los registros de Actividad del administrador (Admin Activity) y de Eventos del sistema (System Event) siempre están activados; los registros de Acceso a los datos (Data Access) deben habilitarse explícitamente y pueden generar costos.
  • Centralizar enrutando receptores agregados (aggregated sinks) desde carpetas/organización a un proyecto de seguridad. Proteger con CMEK y acceso restringido.
  • Monitorear los registros de Policy Denied para detectar conflictos con las políticas de la organización.

• Kit de herramientas para la solución de problemas en múltiples proyectos

  • Policy Troubleshooter: Diagnosticar por qué se permite o deniega un acceso, dadas las políticas de IAM y de denegación efectivas.
  • Cloud Asset Inventory: Consultar las vinculaciones (bindings) de IAM y el historial de políticas en toda la organización, carpetas o proyectos. Ejemplo:

undefined

• Logs Explorer: Filtrar por principal, método y recurso para rastrear acciones entre proyectos.
• Configuraciones de gcloud para el cambio de contexto del operador:

undefined

• Modos de fallo comunes: políticas de la organización en conflicto que bloquean los despliegues, falta de registros de Acceso a los datos que dificultan las investigaciones, e IAM otorgado en el ámbito (scope) incorrecto. Establecer runbooks y vistas previas previas al cambio para reducir el MTTR de los incidentes.

Escenario de problema práctico

Aurelia Retail consolida múltiples equipos y proyectos después de una adquisición. Deben centralizar la facturación, aplicar una administración coherente de IAM y SSH en cientos de VM de Compute Engine, y establecer una gobernanza con una interrupción mínima.

1. Crear una cuenta de facturación corporativa y vincular proyectos

• Justificación: Una única cuenta de facturación centraliza los métodos de pago, los créditos y los presupuestos. Otorgar el rol Billing Account User a un grupo de migración de proyectos y Project Billing Manager a los líderes de equipo para revincular proyectos sin otorgar privilegios excesivos.
• Acción: En la consola, crear la cuenta de facturación. Para cada proyecto, actualizar su asociación de facturación. Habilitar inmediatamente la exportación de Facturación a BigQuery en un proyecto central de análisis.

2. Estandarizar la jerarquía de recursos con carpetas y etiquetas (tags)

• Justificación: Colocar los proyectos bajo carpetas de entorno (prod, nonprod) soporta la herencia de barreras de protección (guardrails) y excepciones específicas. Las etiquetas (tags) permiten una aplicación detallada de políticas de la organización sin duplicar las estructuras de carpetas.
• Acción: Crear carpetas para prod y nonprod; mover los proyectos correspondientemente. Definir etiquetas env=prod|nonprod e identificadores de aplicación.

3. Implementar IAM basado en grupos con privilegio mínimo y separación de funciones

• Justificación: Los grupos simplifican el ciclo de vida y la auditoría. Dividir los roles entre los encargados del despliegue, la seguridad y los administradores de red reduce el radio de impacto (blast radius).
• Acción: Crear grupos de Google para app-operators, net-admins, sec-admins y billing-managers. Vincular roles predefinidos a nivel de carpeta/proyecto según sea necesario; evitar los roles básicos.

4. Aplicar la administración de SSH basada en OS Login

• Justificación: Las claves SSH individuales asociadas a las cuentas de usuario proporcionan un acceso atribuible y revocable. Los roles de OS Login gestionan las cuentas de Linux a través de IAM, eliminando las claves compartidas.
• Acción: En cada proyecto, habilitar los metadatos de OS Login. Otorgar el rol compute.osAdminLogin al grupo ops-admins. Ejemplo:

undefined

5. Reemplazar las claves de cuentas de servicio por suplantación (impersonation)

• Justificación: Las credenciales de corta duración mitigan el riesgo de exfiltración de claves y simplifican la rotación. Los registros de auditoría capturan quién suplantó a quién, mejorando la trazabilidad.
• Acción: Otorgar el rol roles/iam.serviceAccountTokenCreator a las identidades de los ejecutores de CI/CD en las cuentas de servicio de las cargas de trabajo. Eliminar las claves gestionadas por el usuario y aplicar una política de la organización para bloquear la creación de nuevas claves.

6. Aplicar políticas de la organización como barreras de protección (guardrails)

• Justificación: Las restricciones previenen configuraciones riesgosas en todos los proyectos, al tiempo que permiten excepciones etiquetadas donde esté justificado.
• Acción: Aplicar restricciones para no permitir IP externas en prod, restringir las regiones a ubicaciones aprobadas y deshabilitar la creación de claves de cuentas de servicio. Usar etiquetas para permitir excepciones para proyectos específicos con aprobaciones documentadas.

7. Establecer gobernanza de costos

• Justificación: Los presupuestos alertan a los propietarios antes de que se exceda el gasto; la exportación a BigQuery permite la atribución y la previsión. Las etiquetas (labels y tags) mapean el gasto de los recursos a los centros de costos.
• Acción: Crear presupuestos por carpeta y aplicación principal con notificaciones de Pub/Sub. Aplicar políticas de etiquetas a través de plantillas de despliegue y validación de políticas en CI.

8. Centralizar la auditoría y acelerar la solución de problemas

• Justificación: El registro agregado y el inventario de activos en toda la organización acelera las investigaciones y los informes de cumplimiento.
• Acción: Crear receptores agregados (aggregated sinks) hacia un proyecto de seguridad con buckets protegidos por CMEK. Habilitar los registros de Acceso a los datos para servicios críticos (Cloud Storage, BigQuery). Usar Cloud Asset Inventory para escanear rutinariamente las vinculaciones de IAM. Capacitar a los operadores para que usen Policy Troubleshooter cuando falle el acceso y Logs Explorer para rastrear la Actividad del administrador/Acceso a los datos.

9. Operacionalizar el cambio con vistas previas y despliegues por fases (staged rollout)

• Justificación: Validar los efectos de IAM y de las políticas antes de su aplicación reduce las interrupciones.
• Acción: Probar las políticas de IAM y de la organización primero en nonprod. Usar ejecuciones de prueba (dry-runs) y simulación de políticas donde estén disponibles. Para la automatización de despliegues, implementar despliegues canary y planes de reversión (backout).

Este enfoque produce una facturación y una visión de costos centralizadas, una administración de SSH atribuible a través de OS Login, un IAM de privilegio mínimo con suplantación, controles preventivos sólidos a través de políticas de la organización, y una auditoría y solución de problemas robustas en todo el nuevo entorno multiproyecto.

Todos los dominios · Compute Engine y operaciones de máquinas virtuales →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Google →