GCP Associate Cloud Engineer #1: Configuración del entorno de la solución en la nube

Esta es la primera entrega de una serie para preparar el examen Associate Cloud Engineer (ACE) de Google Cloud. Cada artículo cubre una sección de la guía oficial. Aquí vemos la Sección 1: Configuración del entorno de la solución en la nube, que vale aproximadamente el 20 % del examen.

El examen dura 2 horas, tiene entre 50 y 60 preguntas de opción múltiple y de selección múltiple, y se rinde con Pearson VUE.

Qué evalúa esta sección

La Sección 1 trata de lo que haces antes de crear el primer recurso: ordenar la jerarquía, decidir quién puede hacer qué, activar lo necesario, controlar cuotas y gastos. Son preguntas de escenario donde casi siempre hay que elegir la herramienta o el nivel correcto de la jerarquía. En las siguientes partes de la serie pasaremos a planificar e implementar los recursos.

1.1 Configuración de proyectos y cuentas

Jerarquía de recursos y herencia

La jerarquía tiene cuatro niveles: organización → carpetas → proyectos → recursos. Las políticas de IAM y las Organization Policies se heredan hacia abajo: lo que defines en una carpeta aplica a todos los proyectos que contiene. Las políticas de IAM se suman (un permiso concedido arriba no se puede quitar abajo); en cambio, una Organization Policy puede sobrescribirse en niveles inferiores según cómo esté configurada.

Organization Policies

Las Organization Policies definen qué se puede hacer con los recursos (restricciones), mientras que IAM define quién puede hacerlo. Tres ejemplos que conviene reconocer:

IAM: roles en un proyecto

Prefiere roles predefinidos asignados a grupos, no a usuarios individuales. Así, cuando alguien cambia de equipo, solo cambias su pertenencia al grupo.

1
2
3
gcloud projects add-iam-policy-binding mi-proyecto \
--member='group:devops@ejemplo.com' \
--role='roles/compute.instanceAdmin.v1'

Cloud Identity: usuarios y grupos

Cloud Identity administra usuarios y grupos. Se pueden crear manualmente (consola o Admin SDK) o de forma automatizada sincronizando desde Active Directory o LDAP con Google Cloud Directory Sync (GCDS), que copia en un solo sentido (del directorio local hacia Cloud Identity).

Habilitar APIs

Un servicio no se puede usar hasta que su API esté habilitada en el proyecto.

1
gcloud services enable compute.googleapis.com --project=mi-proyecto

Google Cloud Observability

Para ver métricas de varios proyectos en un solo lugar, usas un metrics scope: un proyecto "de alcance" (scoping project) al que agregas los proyectos monitoreados.

Cuotas

Las cuotas limitan cuánto puedes consumir de un recurso. Se revisan y se solicita su aumento desde Cloud Quotas (IAM y administración → Cuotas y límites del sistema).

También puedes solicitar un ajuste desde la terminal con gcloud quotas preferences create.

1
2
3
4
gcloud quotas preferences create --project=mi-proyecto \
--service=compute.googleapis.com \
--quota-id=QUOTA_ID \
--preferred-value=VALOR_DESEADO

Organizaciones standalone

Si tu empresa no tiene Google Workspace, creas una organización con Cloud Identity Free y un dominio verificado (verificación con un registro DNS). Al verificar el dominio se crea el recurso de organización.

Configurar la red

Una cuenta nueva suele traer la red default en modo automático, con una subred por región y rangos predefinidos. Para producción se recomienda una VPC en modo personalizado, donde tú defines las subredes y los rangos IP.

1
gcloud compute networks create mi-vpc --subnet-mode=custom

Disponibilidad por región y zona

No todos los productos están en todas las regiones o zonas. Antes de elegir ubicación, revisa la página de ubicaciones de Google Cloud para confirmar que el producto existe donde lo necesitas.

Cloud Asset Inventory y Gemini Cloud Assist

Cloud Asset Inventory guarda un inventario y el historial de tus recursos y políticas de IAM, y permite buscarlos en una organización. Gemini Cloud Assist permite apoyarse en lenguaje natural para analizar y entender esos recursos.

1
gcloud asset search-all-resources --scope=organizations/123456789 --query='labels.env:prod'

Workforce Identity Federation

Workforce Identity Federation permite que personas (empleados) de un proveedor de identidad externo (OIDC o SAML) accedan a Google Cloud sin crear cuentas en Cloud Identity. No la confundas con Workload Identity Federation, que permite que aplicaciones o procesos (por ejemplo, desde AWS, Azure o GitHub Actions) accedan sin claves de cuenta de servicio.

Escenario → Solución (1.1)

1. Restringir regiones

• Escenario: una empresa europea debe garantizar que ningún proyecto de la carpeta "Producción" cree recursos fuera de la UE.
• Solución: Organization Policy gcp.resourceLocations aplicada a la carpeta.
• Por qué: la política se hereda a todos los proyectos de la carpeta y restringe las ubicaciones, sin depender de que cada equipo lo recuerde.
• Trampa común: dar roles de IAM más limitados. IAM controla quién, no dónde se crean los recursos.

2. Permisos para un equipo

• Escenario: diez ingenieros de infraestructura necesitan administrar VMs en un solo proyecto.
• Solución: crear un grupo, agregar a las personas y asignar al grupo un rol predefinido (por ejemplo, Compute Instance Admin) en el proyecto.
• Por qué: administrar grupos es más simple y auditable que asignar roles a cada usuario.
• Trampa común: usar Owner o Editor "para que funcione". Son roles básicos, demasiado amplios.

3. Sincronizar el directorio corporativo

• Escenario: la empresa tiene Active Directory local y quiere que sus usuarios y grupos existan en Google Cloud sin recrearlos a mano.
• Solución: Google Cloud Directory Sync (GCDS) hacia Cloud Identity.
• Por qué: automatiza la sincronización de usuarios y grupos desde el directorio.
• Trampa común: Workforce Identity Federation. Federa el acceso sin crear cuentas; no es la herramienta de sincronización que describe el escenario.

4. Habilitar una API

• Escenario: al crear una VM, el comando falla porque la API de Compute Engine no está activada.
• Solución: gcloud services enable compute.googleapis.com.
• Por qué: las APIs se habilitan por proyecto.
• Trampa común: pedir un aumento de cuota. Una API deshabilitada no es un problema de cuota.

5. Monitorear varios proyectos

• Escenario: quieres un solo panel con las métricas de los proyectos de desarrollo, pruebas y producción.
• Solución: configurar un metrics scope en un proyecto y agregar los otros como proyectos monitoreados.
• Por qué: el scope centraliza la visualización de métricas.
• Trampa común: crear un panel en cada proyecto y compararlos a mano.

6. Cuota agotada

• Escenario: un despliegue falla con un error de cuota de CPUs en una región.
• Solución: solicitar un aumento de la cuota en Cloud Quotas (o usar otra región con disponibilidad).
• Por qué: las cuotas son límites de consumo por proyecto y región.
• Trampa común: pensar que un budget lo solucionará. Los budgets no controlan el consumo.

7. Red de producción

• Escenario: el equipo de seguridad exige rangos IP propios y sin subredes en regiones que no se usan.
• Solución: crear una VPC en modo personalizado y definir solo las subredes necesarias.
• Por qué: el modo automático crea una subred en cada región con rangos predefinidos que pueden chocar con otras redes.
• Trampa común: quedarse con la red default porque ya existe.

8. Acceso de empleados con un IdP externo

• Escenario: los empleados ya usan un proveedor de identidad corporativo y deben entrar a la consola de Google Cloud sin cuentas nuevas.
• Solución: Workforce Identity Federation.
• Por qué: está pensada para identidades humanas externas.
• Trampa común: Workload Identity Federation, que es para aplicaciones y procesos, no para personas.

9. Auditar recursos

• Escenario: necesitas encontrar todos los recursos con la etiqueta env=prod en la organización.
• Solución: Cloud Asset Inventory (gcloud asset search-all-resources).
• Por qué: busca recursos a escala de organización.
• Trampa común: recorrer proyecto por proyecto con comandos list.

1.2 Gestión de la facturación

Cuentas de facturación y vinculación de proyectos

Los costos se pagan mediante una cuenta de facturación (Cloud Billing account), y cada proyecto debe estar vinculado a una para usar servicios de pago. Para vincular un proyecto necesitas dos permisos:

• Billing Account User en la cuenta de facturación.
• Project Billing Manager en el proyecto.

Para crear cuentas de facturación se necesita el rol Billing Account Creator (roles/billing.creator).

1
2
gcloud billing accounts list
gcloud billing projects link mi-proyecto --billing-account=0X0X0X-0X0X0X-0X0X0X

Budgets y alertas

Un budget envía alertas cuando el gasto alcanza umbrales que defines, sobre el gasto real o el pronosticado.

Exportación de facturación a BigQuery

Puedes exportar los datos de facturación a BigQuery para analizarlos con SQL. Hay tres tipos de datos: uso estándar, uso detallado y precios. Usa labels en los recursos para atribuir costos a equipos, entornos o aplicaciones y luego filtrar o agrupar por ellos.

Escenario → Solución (1.2)

10. Vincular un proyecto

• Escenario: un proyecto nuevo no puede crear recursos de pago porque no tiene facturación.
• Solución: vincularlo a una cuenta de facturación, con Billing Account User en la cuenta y Project Billing Manager en el proyecto.
• Por qué: sin cuenta vinculada, los servicios de pago no funcionan.
• Trampa común: pensar que ser Owner del proyecto basta. Se necesita además permiso sobre la cuenta de facturación.

11. Aviso de sobrecosto

• Escenario: finanzas quiere un correo cuando el gasto del mes supere el 80 % de 1.000 USD.
• Solución: crear un budget con umbral al 80 % y notificaciones por correo.
• Por qué: los budgets alertan al llegar a los umbrales, sobre gasto real o pronosticado.
• Trampa común: creer que el budget bloquea el consumo al llegar al límite.

12. Análisis de costos por equipo

• Escenario: quieres saber cuánto gasta cada equipo en BigQuery y Compute Engine.
• Solución: etiquetar los recursos con labels y exportar la facturación a BigQuery.
• Por qué: la exportación permite consultar el detalle con SQL y los labels permiten agrupar por equipo.
• Trampa común: usar solo los reportes de la consola, que no dan el mismo nivel de detalle ni permiten SQL.

Tabla resumen: "El escenario dice… → Respuesta"

Quiz final de la sección

Checklist: qué debes saber de la Sección 1

• Los niveles de la jerarquía y cómo se heredan IAM y las Organization Policies.
• Para qué sirven gcp.resourceLocations, compute.vmExternalIpAccess e iam.disableServiceAccountKeyCreation.
• Asignar roles predefinidos a grupos en un proyecto.
• Diferenciar Cloud Identity manual, GCDS, Workforce y Workload Identity Federation.
• Habilitar APIs con gcloud services enable.
• Qué es un metrics scope en Google Cloud Observability.
• Cuotas: dónde se ven y cómo se solicita un aumento.
• Cómo crear una organización standalone (Cloud Identity Free + dominio verificado).
• VPC en modo personalizado frente a la red default.
• Cloud Asset Inventory para buscar recursos.
• Vincular proyectos a facturación (Billing Account User + Project Billing Manager).
• Los budgets alertan; las cuotas limitan.
• Exportación a BigQuery (estándar, detallada y precios) y uso de labels.

Próximo artículo

En el #2 pasamos a la Sección 2: Planificación e implementación de una solución en la nube: elegir y configurar cómputo, almacenamiento, bases de datos y redes, y desplegar recursos con la herramienta adecuada.