Google PCD: Costo, gobernanza y operaciones de aplicaciones sostenibles — Guía de estudio

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Forma parte de la Google Professional Cloud Developer — 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 costo, la gobernanza y las operaciones sostenibles son inseparables en el desarrollo moderno de aplicaciones en Google Cloud. El objetivo es exponer y controlar el gasto, diseñar servicios que escalen económicamente y aplicar barreras de protección que mantengan los entornos seguros, en cumplimiento y limpios, todo mientras se equilibra el rendimiento y la fiabilidad. Esta sección detalla mecanismos prácticos (facturación y etiquetas, controles de autoescalado, cuotas y políticas), la economía específica de las cargas de trabajo (Cloud Run, GKE, plataformas de datos) y las decisiones conscientes de la sostenibilidad que reducen el desperdicio por inactividad y el impacto de carbono sin socavar la experiencia del usuario.

Controles de costos y visibilidad

Cuentas de facturación, etiquetas, asignación de costos, presupuestos, alertas y visibilidad
- Utilice una cuenta de facturación dedicada por unidad de negocio o fuente de financiación para aislar la propiedad y habilitar permisos granulares. Exporte los datos de facturación a BigQuery para un análisis detallado, pronósticos y chargeback.
- Las etiquetas son pares clave-valor en los recursos para la atribución de costos. Estandarice las claves de las etiquetas (team, app, env, cost-center) y exija su uso mediante políticas de organización y verificaciones de CI. Nota: las etiquetas no son retroactivas; los recursos sin etiquetar sesgan los informes.
- Use presupuestos y alertas a nivel de cuenta de facturación y de proyecto. Combine umbrales (p. ej., 50, 90, 100 por ciento) y activadores basados en pronósticos. Dirija las notificaciones de presupuesto a Pub/Sub y reenvíelas a herramientas de Chat/Ops. Los presupuestos alertan; no aplican un control estricto.
- Para plataformas compartidas (p. ej., GKE, BigQuery), use etiquetas por namespace o por trabajo y adjúntelas a los registros y al uso para permitir el showback/chargeback.

Ejemplo: añadir etiquetas

undefined

Cuotas, límites, pronóstico de consumo y gobernanza de la capacidad
- Las cuotas protegen los servicios y limitan los costos descontrolados. Revise las cuotas de servicio regularmente, ajústelas al tamaño adecuado por proyecto y solicite aumentos antes de los lanzamientos. Implemente verificaciones previas al despliegue que comparen el uso máximo esperado con las cuotas.
- Pronostique el gasto utilizando la exportación de Facturación junto con la telemetría de uso del producto (métricas de Cloud Monitoring, métricas basadas en registros). Modele escenarios (QPS esperado, datos escaneados) y valídelos en preproducción.
- Modos de fallo: alcanzar una cuota en medio de un incidente o lanzamiento de producto conduce a throttling (429/403), interrupciones parciales o degradación silenciosa. Las cuotas sobreaprovisionadas aumentan el radio de impacto (blast radius) de los trabajos defectuosos.

Ejemplo: listar las cuotas de Compute Engine

undefined

Elasticidad y economía del cómputo

Ajuste de tamaño (right-sizing), autoescalado, facturación basada en solicitudes, uso confirmado y capacidad spot
- Ajusta el tamaño de vCPU y memoria usando la información de Cloud Monitoring y Recommender; valida con pruebas de carga. Las asignaciones insuficientes causan picos de latencia y estrangulamiento de CPU (CPU throttling) o falta de memoria (OOM); las asignaciones excesivas desperdician el gasto.
- El autoescalado convierte el sobreaprovisionamiento similar a capex en opex elástico. Usa HPA/VPA para GKE y el autoescalado por solicitud para serverless (Cloud Run) para ajustar la capacidad a la demanda.
- La facturación basada en solicitudes (Cloud Run, Cloud Functions, GKE Autopilot) alinea el costo con el uso y reduce la inactividad. Ten cuidado con las sobrecargas por solicitud (overheads) y los arranques en frío (cold starts); ajusta las instancias mínimas cuando sea apropiado.
- El uso confirmado es para la base de referencia de estado estable. Usa CUDs basados en recursos para Compute Engine y CUDs flexibles para productos administrados/serverless elegibles. No te sobrecomprometas con cargas de trabajo volátiles.
- La capacidad spot reduce el costo de cómputo para trabajos interrumpibles y tolerantes a fallos. Implementa siempre manejadores de terminación controlada (graceful termination); mantén la redundancia y puntos de control (checkpointing) rápidos. Prepárate para una terminación en cualquier momento con poca antelación.
Compensaciones entre concurrencia e instancias mínimas en Cloud Run
- La concurrencia controla cuántas solicitudes puede atender una única instancia simultáneamente.
  - Una mayor concurrencia mejora la utilización y la eficiencia de costos, pero puede aumentar la latencia de cola (tail latency) debido al bloqueo de cabecera de línea (head-of-line blocking) dentro del contenedor.
  - Una concurrencia de 1 aísla las solicitudes (útil para código limitado por CPU o que no es seguro para hilos [non-thread-safe]), pero a menudo aumenta el número de instancias y el costo.
- Las instancias mínimas reducen los arranques en frío y suavizan la latencia a costa de un gasto base. Úsalas solo donde los SLO lo requieran y valida el mínimo con los patrones de demanda.

Ejemplo: Configuración de Cloud Run (service.yaml)

undefined

Solicitudes y límites de recursos en GKE, comportamiento del Cluster Autoscaler y limpieza de recursos inactivos
- Las solicitudes (requests) determinan la programación (scheduling); los límites (limits) acotan el uso máximo. Establece las solicitudes cerca de la necesidad estable observada y los límites ligeramente por encima para permitir picos cortos. Límites demasiado bajos causan estrangulamiento de CPU (CPU throttling); límites de memoria demasiado bajos causan OOMKilled. Solicitudes muy por encima de la realidad desperdician capacidad y bloquean la programación.
- El Cluster Autoscaler escala los grupos de nodos basándose en pods que no se pueden programar (solicitudes agregadas insuficientes). Respeta los PodDisruptionBudgets y no puede expulsar (evict) ciertos pods (p. ej., con almacenamiento local o PDBs restrictivos), lo que puede impedir la reducción de escala (scale-down). Los DaemonSets y los taints/afinidades de nodo también pueden bloquear la eficiencia del escalado.
- El Horizontal Pod Autoscaler vincula el escalado a la CPU/memoria o a métricas personalizadas; el Vertical Pod Autoscaler ajusta el tamaño de las solicitudes a lo largo del tiempo. Coordina HPA y VPA para evitar la oscilación; usa VPA en los modos recommend o auto según corresponda.
- Limpieza de recursos inactivos: elimina balanceadores de carga, discos persistentes, instantáneas (snapshots) e IP estáticas sin usar. Utiliza las recomendaciones de Active Assist y limpiadores automatizados (janitors) para detectar y eliminar activos inactivos.

Ejemplo: Deployment de GKE con solicitudes/límites

undefined

Gobernanza de costos de datos, analíticas y red

Clases de almacenamiento, controles de ciclo de vida, escalado de bases de datos y diseño de egreso de red
- Elige las clases de Cloud Storage según el patrón de acceso: Standard para datos calientes; Nearline, Coldline o Archive para datos más fríos. Ten en cuenta los mínimos de recuperación y eliminación temprana para los niveles más fríos.
- Las reglas de ciclo de vida automatizan las transiciones y eliminaciones. Usa dual-region para resiliencia donde la latencia multirregional es aceptable; coubica el cómputo y los datos para reducir el egreso y la latencia.
- Escalado de bases de datos:
  - Cloud SQL: escala verticalmente con precaución; réplicas de lectura para lecturas; autoescalado de almacenamiento; usa planes de consulta y connection pooling. Un alto rendimiento de escritura puede requerir sharding o migrar a Spanner/Bigtable.
  - Spanner: escalado horizontal añadiendo nodos; configuraciones multirregión para disponibilidad y lecturas globales; diseña esquemas y claves para un balanceo de carga equilibrado.
  - Bigtable: diseña claves de fila para evitar hotspots; escala los nodos del clúster y el almacenamiento por separado.
- Egreso de red: evita el tráfico entre regiones; ubica los clientes y los datos en la misma región siempre que sea posible. Usa Cloud CDN para contenido a escala de internet, Cloud Interconnect/Peering para entornos híbridos, y Private Google Access o Private Service Connect para acceder a las APIs de Google de forma privada. El tráfico innecesario entre zonas o regiones aumenta el costo y la latencia.

Ejemplo: ciclo de vida de Cloud Storage

undefined

Controles de consulta de BigQuery, retención de datos y costo de uso de analíticas
- Controla los bytes escaneados: filtra siempre por claves de partición/clúster; evita SELECT *; usa vistas materializadas y caché de resultados para consultas repetidas; usa agregaciones aproximadas cuando sea posible.
- Limita el costo del escaneo con maximum bytes billed y establece la prioridad del trabajo en batch para tareas no urgentes para reducir la interferencia y el costo.
- Elige el modelo de precios: bajo demanda (on-demand) para cargas de trabajo esporádicas; reservas (slots) con compromisos para cargas de trabajo estables y de alto volumen. Usa reservas y asignaciones separadas para aislar equipos.
- Retención de datos: establece la expiración de conjuntos de datos/tablas y particiones para la gobernanza; implementa almacenamiento por niveles o exportación para archivado.
- Modos de fallo: las tablas grandes no particionadas disparan los costos; las consultas sin filtros de partición escanean tablas completas; las expiraciones demasiado agresivas eliminan datos necesarios; una contención excesiva de slots degrada los SLA.

Ejemplo: limitar el costo de una consulta

undefined

← Pruebas · Todos los dominios

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