El temario oficial de Google Cloud Certified Associate Cloud Engineer, organizado por dominio. Marca cada punto según lo vayas repasando.
Inicia sesión para guardar tu progreso entre sesiones.
Setting up cloud projects and accounts
La jerarquía de recursos de Google Cloud va de la organización (raíz, que exige Cloud Identity o Google Workspace) a carpetas opcionales y proyectos; cada recurso tiene un único padre. Los roles de IAM y las políticas de organización concedidos en un nivel se heredan hacia abajo, por lo que las carpetas sirven para agrupar departamentos o entornos y delegar su administración. Las carpetas se crean con gcloud resource-manager folders create.
Las políticas de organización limitan qué configuraciones se permiten (ubicaciones, claves de cuentas de servicio, acceso público a Cloud Storage), mientras que IAM decide quién actúa. Se establecen en la organización, carpetas o proyectos y se heredan; en reglas de lista prevalecen los valores denegados y las reglas booleanas del hijo sustituyen a las del padre. La mayoría no son retroactivas.
Para dar acceso en un proyecto se concede un rol a un principal (usuario, grupo o cuenta de servicio) con gcloud projects add-iam-policy-binding, que añade una vinculación sin sobrescribir la política. Se recomiendan roles predefinidos o personalizados en vez de básicos y conceder a grupos. Las condiciones de IAM permiten accesos que caducan, pero no con roles básicos heredados.
Manage access to projects, folders, and organizations ↗Roles overview ↗
Cloud Identity gestiona de forma centralizada usuarios y grupos gestionados por la empresa. Se pueden crear a mano en la consola o automatizar con Google Cloud Directory Sync desde Active Directory (sincronización unidireccional, sin contraseñas) y SSO SAML, o con gcloud identity groups. Las unidades organizativas aplican ajustes como la verificación en dos pasos; el acceso se gestiona con grupos.
Federate Google Cloud with Active Directory ↗Overview of Google identity management ↗
Cada servicio de Google Cloud debe activarse en el proyecto antes de usarlo, desde la biblioteca de API de la consola o con gcloud services enable, que admite varios servicios a la vez; gcloud services list muestra los activados o disponibles. Hace falta el rol Service Usage Admin. Desactivar una API no borra los datos de Cloud Storage o BigQuery, y --force desactiva también los servicios dependientes.
En Cloud Monitoring, el ámbito de métricas de un proyecto de ámbito (mejor uno nuevo sin recursos) permite supervisar varios proyectos desde un único sitio. El Ops Agent recoge registros y métricas de las VM y se despliega a escala con políticas de agentes. Cloud Logging enruta con sumideros a buckets, Cloud Storage, BigQuery o Pub/Sub; los sumideros agregados de carpeta u organización usan --include-children.
Las cuotas limitan cuánto de un recurso puede usar un proyecto (también carpetas u organizaciones) y pueden ser de asignación, de tasa o de concurrencia, globales, regionales o zonales. Se revisan en la consola y se piden aumentos con antelación; una anulación por debajo del valor predeterminado limita el uso. Las alertas de uso avisan y el ajustador de cuotas solicita aumentos automáticamente. Los límites del sistema no se amplían.
Managing billing configuration
Una cuenta de facturación de Cloud define quién paga los proyectos vinculados, funciona en una sola moneda y se asocia a un perfil de pagos de Google. En una organización hace falta el rol Billing Account Creator para crearla. El país y la moneda no se pueden cambiar, así que otro país exige otra cuenta. Un perfil de pagos de tipo Organización admite varios usuarios; el Individual, no.
Create a new self-serve Cloud Billing account ↗Cloud Billing overview ↗
Un proyecto solo puede usar servicios de Google Cloud si está vinculado a una cuenta de facturación de Cloud activa; cada proyecto se vincula a una sola cuenta, que puede pagar muchos proyectos. Se vincula o se cambia con gcloud billing projects link, con Billing Account User en la cuenta y Project Billing Manager o Project Owner en el proyecto. Deshabilitar la facturación detiene los servicios y puede eliminar recursos.
Enable, disable, or change billing for a project ↗gcloud billing projects link ↗
Los presupuestos de Cloud Billing comparan el gasto real o previsto con un importe y envían alertas al cruzar umbrales; pueden abarcar la cuenta, proyectos, carpetas, servicios o una etiqueta. Por defecto avisan a Billing Account Administrator y User; con canales de Cloud Monitoring se añaden otros destinatarios. Un presupuesto solo de alertas no limita el gasto: para automatizar respuestas se usan notificaciones a Pub/Sub.
Create, edit, or delete budgets and budget alerts ↗Set up programmatic notifications ↗
Facturación de Cloud exporta a BigQuery costes de uso estándar, costes detallados por recurso, precios y metadatos de CUD; cada tipo se habilita por separado. Se recomienda un proyecto de FinOps vinculado a la misma cuenta, un conjunto de datos multirregional (añade el mes anterior) sin caducidad de tablas, y el rol Billing Account Costs Manager o Administrator; los precios exigen la API BigQuery Data Transfer Service.
Export Cloud Billing data to BigQuery ↗Set up Cloud Billing data export to BigQuery ↗
Practica por dominio oficial y revisa la explicación de cada respuesta.
Empezar a practicar