Google PCA: Diseño Organizacional, IAM y Gobernanza de la Nube — Guía de estudio

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Forma parte de la Google Professional Cloud Architect — 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

El diseño de la organización, IAM y la gobernanza establecen la base sobre la que se ejecutan todas las arquitecturas de Google Cloud. Un buen diseño crea límites administrativos claros, minimiza el radio de impacto, habilita el privilegio mínimo, controla los costos y escala operacionalmente entre múltiples equipos y entornos. La gobernanza debe enfatizar las barreras de protección (guardrails) en lugar de las barreras de acceso (gates): automatizar valores predeterminados que sean seguros, medibles y reversibles, mientras se delega el control diario a los equipos más cercanos a la carga de trabajo.

Jerarquía de recursos y fundamentos de identidad

Los recursos de Google Cloud forman un árbol estricto: Organización → Carpetas (Folders) → Proyectos → Recursos (por ejemplo, instancias de Compute Engine, buckets). Las políticas de IAM y las restricciones de la Política de la Organización (Organization Policy) se heredan hacia abajo en el árbol.

Principios clave de diseño:

Usa una única Organización para centralizar la gobernanza. Crea Carpetas (Folders) de nivel superior para los límites administrativos principales (por ejemplo, unidades de negocio, regiones o entornos regulados frente a no regulados).
Dentro de cada límite, crea Carpetas de entorno (prod, nonprod) para aplicar políticas diferenciadas. Mantén los proyectos con un alcance limitado a la carga de trabajo y efímeros siempre que sea posible para reducir el radio de impacto y facilitar la imputación de costos (chargeback).
Herencia: los permisos de concesión (allow grants) se acumulan (unión de las vinculaciones de permiso de los ancestros y el nodo). Las políticas de denegación de IAM (IAM Deny), si se utilizan, tienen precedencia y pueden bloquear el acceso incluso si existe un permiso de concesión. Evita asignar roles amplios en un nivel alto del árbol; el radio de impacto es grande y es difícil de deshacer.

Fuentes de identidad:

Cloud Identity es el plano de identidad para la fuerza laboral. Intégralo con tu IdP empresarial (SAML/OIDC) para centralizar la autenticación y el ciclo de vida del personal (altas, cambios y bajas). Usa Google Cloud Directory Sync para la sincronización de atributos y grupos si es necesario.
Los Grupos son los sujetos principales de IAM. El acceso basado en grupos permite cambios escalables y una propiedad auditable. Usa un patrón de grupo de grupos (por ejemplo, net-admins, sec-admins, app-team-A) y restringe quién puede gestionar la membresía de los grupos.
Las cuentas de servicio (Service accounts) representan las cargas de trabajo. Prefiere la suplantación de identidad de cuentas de servicio (impersonation) con credenciales de corta duración en lugar de claves almacenadas. Evita las claves de cuentas de servicio gestionadas por el usuario; trátalas como excepciones con aprobaciones estrictas y rotación.
Patrones de identidad para cargas de trabajo:
- GKE Workload Identity vincula las cuentas de servicio de Kubernetes con las cuentas de servicio de Google, eliminando las credenciales a nivel de nodo.
- Workload Identity Federation permite que identidades externas (on-prem, otras nubes, GitHub Actions) obtengan acceso de corta duración a Google sin necesidad de claves. Usa el alcance por pool/proveedor y condiciones de atributos para restringir el acceso.

Modos de fallo comunes y mitigaciones:

Conceder roles primitivos (Propietario/Editor/Visualizador) a nivel de Carpeta u Organización conduce a un sobreaprovisionamiento de privilegios generalizado. Úsalos solo en proyectos de acceso de emergencia (break-glass) con un alcance muy restringido.
La proliferación de grupos (group sprawl) con una propiedad poco clara socava el principio de privilegio mínimo. Aplica convenciones de nomenclatura, etiquetas de propósito y metadatos de propietario en los grupos.
Las cuentas de servicio huérfanas y las vinculaciones obsoletas acumulan riesgos. Programa revisiones de acceso recurrentes y usa IAM Recommender para reducir los permisos no utilizados.

Modelos de IAM, roles y operaciones de acceso

Roles y vinculaciones (bindings):

Los roles predefinidos están seleccionados para servicios específicos y deberían ser la opción por defecto.
Los roles personalizados cubren las carencias cuando los roles predefinidos son demasiado generales. Créalos a partir del conjunto mínimo de permisos que se observe como necesario; gestiónalos con versiones y pruébalos.
Los roles básicos (Visualizador/Editor/Propietario) son heredados y demasiado amplios. Evítalos en los ámbitos de Organización y Carpeta. No uses el rol de Propietario para las operaciones diarias; resérvalo para el acceso de emergencia a la plataforma con fuertes controles de compensación.
Las vinculaciones de roles condicionales (IAM Conditions) restringen cuándo y dónde se aplica una vinculación usando atributos como resource.name, resource.matchTag, request.time o request.auth.audiences. Usa condiciones para el acceso por tiempo limitado, el acceso a producción basado en etiquetas o las acciones restringidas por ubicación.

Privilegio mínimo y elevación de privilegios:

Separa las responsabilidades de “lectura”, “operación” y “administración”. Por ejemplo, los equipos de redes, seguridad y aplicaciones obtienen roles distintos en ámbitos distintos.
Usa la elevación de privilegios justo a tiempo (just-in-time) con flujos de trabajo de Access Approval o automatización basada en tickets para vincular roles por tiempo limitado mediante condiciones.

Políticas de denegación (Deny) y sus riesgos:

IAM Deny puede bloquear de forma centralizada permisos de riesgo (por ejemplo, resourcemanager.projects.delete). Una denegación anula un permiso de concesión y se aplica a todo el subárbol. Valida exhaustivamente; una política de denegación mal configurada puede bloquear la automatización o interrumpir los despliegues.

Auditabilidad y revisiones:

Habilita los registros de Actividad del Administrador (Admin Activity logs) a nivel de Organización; se conservan durante 400 días por defecto. Para servicios sensibles, habilita los registros de Acceso a Datos (Data Access logs) y envíalos a BigQuery para su retención y auditoría a largo plazo.
Implementa revisiones de acceso periódicas: enumera las vinculaciones con Cloud Asset Inventory, compáralas con los registros de propiedad, elimina los roles no utilizados sugeridos por IAM Recommender y verifica el vencimiento de las excepciones.

Ejemplo útil (vinculación por tiempo limitado y basada en etiquetas):

gcloud projects add-iam-policy-binding PROJECT_ID –member=“group:prod-ops@example.com” –role=“roles/compute.instanceAdmin.v1” –condition=‘title=ProdOnlyTemp,expression=resource.matchTag(“organizations/1234567890/env”,“prod”) && request.time < timestamp(“2026-01-01T00:00:00Z”)’

Gobernanza financiera y barreras de protección de las políticas de la organización

Arquitectura de facturación:

Centralizar una o más cuentas de facturación bajo la propiedad del departamento de Finanzas. Usar múltiples cuentas de facturación solo cuando sea legal u operativamente necesario (por ejemplo, entidades separadas o modelos de revendedor).
Vincular proyectos a cuentas de facturación mediante automatización; no permitir la vinculación manual fuera de los flujos de trabajo aprobados.

Imputación de costos y visibilidad:

Usar etiquetas (labels) y tags de asignación de costos de manera consistente. Las etiquetas (labels) son metadatos de formato libre para filtrado e informes; los tags son jerárquicos y se pueden usar en condiciones y políticas de IAM. Habilitar la asignación de costos para los tags seleccionados para que aparezcan en las exportaciones de facturación.
Exportar datos de facturación a BigQuery para su análisis; crear dashboards por propietario, centro de costos y entorno. Exigir que cada proyecto tenga un propietario responsable y un presupuesto.

Presupuestos y detección de anomalías:

Crear presupuestos con alertas a nivel de carpeta (Folder) y de proyecto. Añadir reacciones programáticas (por ejemplo, notificar al personal de guardia, abrir tickets o deshabilitar nuevos aumentos de cuota) para frenar el gasto descontrolado.
Usar cuotas y compromisos (CUDs) alineados con el uso esperado; monitorear la utilización.

Restricciones de políticas de la organización (seguro por defecto):

Aplicar barreras de protección a nivel de organización o de carpeta (Folder) y relajarlas solo cuando esté justificado. Restricciones comunes:
- constraints/iam.disableServiceAccountKeyCreation = true
- constraints/compute.requireOsLogin = true
- constraints/compute.trustedImageProjects restringiendo las imágenes de VM
- constraints/sql.restrictPublicIp = true
- constraints/storage.uniformBucketLevelAccess = true
- constraints/compute.disableSerialPortAccess = true
Usar VPC Service Controls para reducir el riesgo de exfiltración de datos para los servicios compatibles en perímetros sensibles.

Manejo de excepciones a las políticas:

Las excepciones deben poder solicitarse, ser aprobadas, tener un plazo limitado y ser auditables. Preferir las condiciones de IAM para acotar las excepciones por tag/tiempo. Reconciliar periódicamente las excepciones y hacer que expiren automáticamente a través de pipelines de política como código (policy-as-code).

Ejemplo de política de la organización (YAML) para deshabilitar las claves de cuentas de servicio:

name: organizations/1234567890/policies/iam.disableServiceAccountKeyCreation spec: rules:
- enforce: true Luego aplicar: gcloud org-policies set-policy policy.yaml

Todos los dominios · Cómputo →

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