Google PCA: Cómputo, Plataformas de Aplicaciones y Arquitectura de Cargas de Trabajo — 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

Este dominio cubre cómo seleccionar y diseñar plataformas de computación en Google Cloud, cómo empaquetar y desplegar aplicaciones, y cómo operar cargas de trabajo para lograr confiabilidad, rendimiento, seguridad y eficiencia de costos. Abarca máquinas virtuales, Kubernetes, entornos de ejecución sin servidor (serverless), balanceo de carga, estrategias de despliegue, computación con estado (stateful) y especializada, y patrones de modernización que reducen la deuda técnica mientras satisfacen la demanda cambiante.

Compute Engine y arquitecturas basadas en VM

Compute Engine proporciona un control granular sobre los sistemas operativos, las redes y los tipos de máquinas. Elige las familias de máquinas según las características de la carga de trabajo:

E2: de propósito general y optimizadas en costos; buenas para desarrollo/pruebas y aplicaciones con ráfagas de actividad (bursty).
N2/N2D: equilibrio entre precio y rendimiento para la mayoría de las cargas de trabajo de producción; N2D utiliza CPUs de AMD con un gran ancho de banda de memoria.
C2/C2D/C3: optimizadas para computación, para tareas que hacen un uso intensivo de la CPU (p. ej., API con altas QPS, computación por lotes).
M3: optimizadas para memoria, para grandes conjuntos de datos en memoria (cachés, análisis en memoria).
A3: optimizadas para GPU (NVIDIA) para entrenamiento/inferencia; también se pueden adjuntar GPUs a otras familias.
Confidential VMs (en CPUs compatibles) cifran los datos en uso con cambios mínimos en el código.

Los grupos de instancias administrados (MIGs) aportan elasticidad y resiliencia:

Usa plantillas de instancia (Instance Templates) para una configuración inmutable y MIGs para escalar horizontalmente entre zonas.
Políticas de autoescalado: CPU, utilización del balanceador de carga, métricas de Cloud Monitoring o profundidad de la cola a través de métricas personalizadas. Establece un mínimo/máximo de réplicas y un período de enfriamiento (cooldown) para evitar la inestabilidad (thrash) bajo cargas con ráfagas.
Las actualizaciones progresivas (rolling updates) y los despliegues canary reducen el riesgo; mantén conservadores los ajustes de excedente (surge) e indisponibilidad (unavailable) para servicios con estado (stateful) o con arranques en frío pesados.

Balanceo de carga y verificaciones de estado:

El balanceador de carga HTTP(S) externo global termina la conexión TLS, admite el mapeo de URL y es el front-end estándar para las API web; el balanceador de carga HTTP(S) interno se usa para el tráfico este-oeste.
Las verificaciones de estado (health checks) deben poder llegar a los backends. Un fallo común es el bloqueo de los sondeos, lo que provoca reinicios perpetuos de las instancias y la caída del tráfico. Permite los rangos de origen de las verificaciones de estado a los puertos del backend con reglas de firewall de VPC y etiquetas de destino (target tags).

Ejemplo para permitir verificaciones de estado HTTP a un MIG:

undefined

Consideraciones sobre el ciclo de vida de las VM:

Usa scripts de inicio (startup scripts) o metadatos de la imagen para el arranque (bootstrap); almacena la configuración de tiempo de ejecución en Secret Manager, no la incluyas en las imágenes.
Para VMs interrumpibles (preemptible/Spot), añade un script de apagado (shutdown-script) para drenar el trabajo al recibir el aviso de terminación.
Aplica parches mediante imágenes preconfiguradas (baked images) y reemplazo progresivo para evitar la deriva de la configuración (configuration drift).
El redimensionamiento de discos persistentes se hace en línea (online): aumenta el tamaño del disco y luego expande el sistema de archivos (p. ej., resize2fs en ext4) con un tiempo de inactividad mínimo.

Ejemplo de redimensionamiento de PD:

undefined

Identidad segura y observabilidad:

Asocia cuentas de servicio (service accounts) con privilegios mínimos a las instancias; no incrustes credenciales estáticas.
Instala el Ops Agent para Cloud Logging y Cloud Monitoring. Usa Cloud Trace y Cloud Profiler para reducir la latencia de cola (tail latency) y los puntos calientes (hot spots).
Exporta los datos de auditoría y métricas a BigQuery o Cloud Storage para su retención y análisis a largo plazo.

Computación por lotes y especializada:

Usa Cloud Batch o MIGs con VMs interrumpibles para procesos por lotes (batch) tolerantes a fallos y reducir costos; implementa puntos de control (checkpointing).
Adjunta GPUs/TPUs donde se necesite aceleración de ML. Usa grupos de nodos dedicados (dedicated node pools) o nodos de único propietario (sole-tenant nodes) para cumplir con los requisitos de cumplimiento/aislamiento.
Las Confidential VMs protegen los datos sensibles en memoria; mide la sobrecarga (overhead) en comparación con los requisitos.

Consideraciones sobre el estado:

Mantén las instancias de la aplicación sin estado (stateless); externaliza las sesiones a un almacén compartido (p. ej., Memorystore, Cloud SQL) para evitar anomalías visibles para el usuario durante el escalado.
Para el estado vinculado a la VM, usa discos persistentes regionales o bases de datos replicadas; prueba las rutas de conmutación por error (failover).

Kubernetes y plataformas de contenedores (GKE)

GKE proporciona un plano de control administrado con grupos de nodos de trabajo flexibles:

Los clústeres regionales replican el plano de control y los nodos en varias zonas para una alta disponibilidad; los clústeres zonales concentran los recursos para un menor costo y sensibilidad a la latencia.
Usa múltiples grupos de nodos para segmentar las cargas de trabajo (p. ej., propósito general, GPU, alta memoria, spot). Aplica taints/tolerations y affinity/anti-affinity para controlar la ubicación y reducir los efectos de “vecino ruidoso”.
Capas de escalado automático: el cluster autoscaler agrega/elimina nodos; el Horizontal Pod Autoscaler (HPA) escala las réplicas según métricas de CPU/personalizadas; el Vertical Pod Autoscaler (VPA) ajusta el tamaño de las solicitudes. Combina el HPA con el cluster autoscaler para obtener elasticidad.

Programación de cargas de trabajo y servicios:

Ajusta correctamente las solicitudes/límites de CPU/memoria para minimizar el riesgo de expulsión (eviction) y maximizar la eficiencia del empaquetado (binpacking).
Usa PodDisruptionBudgets para preservar la disponibilidad durante las actualizaciones.
Tipos de Service: ClusterIP (dentro del clúster), NodePort/LoadBalancer (norte-sur) e Ingress para el enrutamiento HTTP(S) con el LB global. Para los canaries, dirige el tráfico a través de backends de Services/Ingress separados o una malla de servicios (service mesh).

Actualizaciones y resiliencia:

Usa actualizaciones surge (surge upgrades) y maxUnavailable para controlar la rotación (churn); fija las cargas de trabajo críticas a múltiples zonas y grupos.
Establece ventanas/exclusiones de mantenimiento para los períodos críticos del negocio.
Valida con un entorno de preproducción y grupos de nodos canary antes de un despliegue general.

Imágenes y seguridad:

Almacena las imágenes de contenedor en Artifact Registry; habilita el escaneo de vulnerabilidades y configura la autorización binaria (binary authorization) o atestaciones para la procedencia.
Usa Workload Identity para mapear una GSA a una KSA para un acceso sin credenciales y con privilegios mínimos a las API de Google.
Obtén la configuración en tiempo de ejecución desde Secret Manager a través del controlador CSI; evita los Secrets de Kubernetes para valores altamente sensibles a menos que estén cifrados con CMEK y el RBAC sea estricto.

Despliegues y reversiones (rollback):

Prefiere las actualizaciones continuas (rolling updates) de Deployments con pasos pequeños y sondas de salud (health probes); para sistemas de baja tolerancia, usa blue-green a través de dos Deployments detrás de un único Service y cambia las etiquetas/selector.
Define siempre sondas de preparación (readiness) y actividad (liveness); las sondas mal configuradas causan reinicios en cascada o agujeros negros (blackholes) durante los despliegues.

Plataformas sin servidor (Serverless) y basadas en eventos

Las plataformas sin servidor de Google Cloud abstraen la infraestructura a la vez que proporcionan controles sólidos sobre la escala, la seguridad y el costo:

Cloud Run: nativo para contenedores, activado por solicitudes HTTP o Eventarc. Escala hasta cero; concurrencia configurable; división del tráfico por revisión para canary y rollback. Establece un mínimo de instancias (min instances) para reducir los arranques en frío (cold starts) en los endpoints sensibles a la latencia. Intégralo con la VPC a través del Acceso a VPC sin servidor (Serverless VPC Access) para el tráfico de salida (egress) privado.
App Engine: PaaS dogmática (opinionated). El entorno Standard ofrece un escalado rápido y restricciones de concurrencia por solicitud según el lenguaje; el entorno Flexible ejecuta contenedores en VM con más control. Evita el estado de sesión local de la instancia; externalízalo a un almacenamiento compartido para prevenir experiencias de usuario obsoletas o duplicadas bajo carga.
Cloud Functions: granularidad a nivel de función para lógica basada en eventos. Usa activadores (triggers) de Pub/Sub, Cloud Storage o Eventarc para micro-operaciones ligeras; mantén las funciones idempotentes y sin estado. Para pipelines combinados de batch/stream sin código existente, Dataflow proporciona un procesamiento unificado con escalado automático.

Compensaciones en la selección de plataforma:

Control operativo: Compute Engine > GKE > Cloud Run/App Engine > Cloud Functions.
Portabilidad: basado en contenedores (GKE/Cloud Run/App Engine Flex) > imágenes de VM > funciones y App Engine Standard.
Latencia: Cloud Run con un mínimo de instancias (min instances) o GKE para una baja latencia de cola (tail latency); evita los arranques en frío para cargas de trabajo interactivas.
Escalado: Cloud Functions/Run escalan más rápido; HPA de GKE más el cluster autoscaler; los MIG requieren calentamiento (warm-up) y sondeos de salud.
Costo: pago por uso en serverless para cargas de trabajo con picos o de bajo estado estable; GKE/VM con descuentos por uso continuo (committed use discounts) para servicios estables y de alto rendimiento; preemptible/Spot para procesos por lotes (batch).

Identidad y configuración:

Cada servicio debe usar una cuenta de servicio dedicada con privilegios mínimos. Para Cloud Run y Functions, establece explícitamente la cuenta de servicio en tiempo de ejecución.
Almacena los secretos en Secret Manager y vincula el acceso a través de IAM; inyéctalos mediante variables de entorno o montajes de volúmenes.

Patrones de Arquitectura, Entrega y Operaciones

Descomposición y límites de servicios:

Monolito: el despliegue y las transacciones más simples, pero limita el escalado independiente y el control del radio de impacto (blast radius); puede enmascarar problemas de rendimiento en lo profundo de las cadenas de llamadas.
Monolito modular: módulos internos claros, proceso compartido; un buen paso intermedio: impone interfaces sin las penalizaciones de la distribución.
Microservicios: desplegabilidad y escalado independientes; introduce latencia de red, transacciones distribuidas y desafíos de consistencia. Define contextos delimitados (bounded contexts) claros y la propiedad de los datos; evita las bases de datos compartidas para prevenir el acoplamiento.

Patrones de modernización:

Strangler-fig: enruta incrementalmente una porción del tráfico a componentes nuevos, retirando gradualmente los endpoints heredados (legacy).
Lift and shift: primero conteneriza o migra a VM para estabilizar, y luego refactoriza.
Capa anticorrupción/fachada (Anti-corruption layer/facade): aísla los contratos heredados mientras se construyen nuevos servicios.
Prioriza primero los dominios de alto cambio y alta fricción para maximizar el valor de negocio y reducir el riesgo.

Entrega y despliegues (rollouts):

El CI/CD con pruebas automatizadas y entornos por etapas (staged environments) reduce los retrocesos (rollbacks). Añade análisis canary, presupuestos de error (error budgets) y entrega progresiva.
Blue-green: minimiza el tiempo de inactividad y simplifica el rollback a costa de duplicar la capacidad.
División de tráfico: Cloud Run/App Engine admiten el enrutamiento basado en porcentajes entre revisiones/versiones; prueba bajo tráfico real con presupuestos de error de SLO ajustados.

Balanceo de carga y salud:

Usa un L7 global para HTTP y un proxy TCP para protocolos no HTTP; balanceadores de carga (LBs) internos para servicios privados. Configura la afinidad de sesión (session affinity) solo cuando sea necesario y externaliza el estado de la sesión.
Las comprobaciones de estado (health checks) deben reflejar la disponibilidad de la aplicación (p. ej., la salud de las dependencias); un simple 200 OK que enmascara una falla del almacén de datos puede causar una mala dirección del tráfico.

Observabilidad y gobernanza:

Instrumenta trazas (traces) para la atribución de latencia de extremo a extremo entre servicios; habilita el registro de IDs de solicitud para correlacionar logs y trazas.
Exporta logs/métricas/registros de auditoría a BigQuery o Cloud Storage para necesidades de retención y auditoría; asegura el acceso mediante vistas (views) e IAM.
Para los logs de VM, instala el Ops Agent; define la retención y los receptores (sinks) para controlar el costo y el cumplimiento.

Cadena de suministro de software segura:

Usa Artifact Registry con escaneo; mantén las imágenes al mínimo. Optimiza los Dockerfiles: prefiere bases ‘slim’, instala primero las dependencias y luego copia el código fuente para aprovechar la caché de compilación (build cache).

Redes y segmentación:

Aplica el acceso por niveles mediante etiquetas y reglas de firewall de VPC para permitir solo los flujos esperados (p. ej., web → API → BD). Deniega el acceso directo de web → BD.

Capacidad, rendimiento y computación especializada

Diseñar para una demanda variable:

GCE: escalar automáticamente los MIG basándose en indicadores adelantados (longitud de la cola) para anticiparse a la saturación de la CPU; añadir limitación de la tasa de solicitudes y contrapresión para proteger los sistemas descendentes.
GKE: combinar el HPA basado en solicitudes por segundo o métricas personalizadas y el escalador automático de clústeres; aprovisionar un pequeño búfer para evitar el retraso en el escalado.
Serverless: ajustar la concurrencia y las instancias mínimas para equilibrar el costo frente a la latencia; usar un despliegue regional para una latencia próxima al usuario.

Resiliencia y pruebas:

Ejecutar cargas sintéticas para validar el escalado automático y los SLO; incluir pruebas de caos (p. ej., terminar instancias/pods aleatorios) para asegurar que el sistema mantenga la disponibilidad durante fallos y actualizaciones.
Configurar PodDisruptionBudgets y ganchos de terminación controlada para drenar las conexiones antes del apagado de los pods/VM.

Rendimiento y selección de almacenamiento:

La ingesta de series temporales y de secuencias de clics de alto rendimiento y baja latencia se adapta bien a Bigtable; diseñar filas anchas y claves agrupadas por tiempo para evitar puntos calientes (hotspots).
Para Spark/Hadoop con cambios operativos mínimos, usar Dataproc; dimensionar correctamente los clústeres con escalado automático.
Para combinar lotes por hora y streaming sin código existente, usar Dataflow con escalado automático y ventanas (windowing) para unificar las canalizaciones.

Movimiento de datos y conectividad:

Para una replicación privada, sostenida y de gran ancho de banda (p. ej., bases de datos de varios terabytes), considerar Dedicated Interconnect; usar adjuntos de VLAN y Cloud Router para el enrutamiento dinámico. Para necesidades ad hoc o de menor rendimiento, Cloud VPN es suficiente.

Cargas de trabajo con estado (stateful):

En GKE, usar StatefulSets con volúmenes persistentes (PD regionales para alta disponibilidad) e identidades ordenadas y estables; considerar Filestore para semántica NFS.
Usar bases de datos gestionadas (Cloud SQL, AlloyDB, Spanner) para durabilidad y escalado siempre que sea posible; planificar réplicas de lectura y conmutación por error (failover).

Seguridad y cumplimiento:

Considerar Confidential VMs para proteger los datos en uso con una sobrecarga de rendimiento limitada; evaluar en función de los requisitos de la carga de trabajo.
Usar CMEK donde las claves deban ser controladas por el cliente; aplicar el aislamiento por entorno y separar los proyectos para desarrollo/pruebas/producción.

Controles de costos:

Usar descuentos por uso confirmado y por uso continuo para la computación en estado estable; instancias interrumpibles/Spot para lotes tolerantes a fallos; escalado automático a cero en serverless.
Dimensionar correctamente los recursos con las recomendaciones de Monitoring; eliminar servicios inactivos y establecer cuotas de métricas basadas en registros para evitar sorpresas en los costos.

Resolución de problemas de latencia:

Usar Cloud Trace para identificar el microservicio que añade más latencia; optimizar la ruta de código, el almacenamiento en caché o los índices de la base de datos de ese servicio. Validar las mejoras con canaries A/B.

Escenario de problema práctico

FerroLine Logistics planea modernizar un monolito J2EE que gestiona el seguimiento de envíos y las notificaciones a clientes. La carga de trabajo es intermitente durante los cierres regionales, debe cumplir un objetivo de disponibilidad del 99.9%, y el equipo desea portabilidad con un mínimo esfuerzo operativo mientras introduce características basadas en eventos.

Estabilizar y observar el sistema actual

Razón: Antes de realizar cambios, establecer una línea base del comportamiento y los errores para reducir el riesgo de reversión. Desplegar el Ops Agent en las VM existentes para Cloud Logging y Monitoring, e instrumentar el seguimiento distribuido en las rutas de solicitud de alta latencia. Exportar los registros y métricas a BigQuery para el análisis histórico y la generación de informes de SLO.

Elegir una zona de aterrizaje (landing zone) y una combinación de plataformas por etapas

Razón: Equilibrar el control y la velocidad. Migrar el monolito como un contenedor a trabajos de Cloud Run para los componentes por lotes y a servicios de Cloud Run para las API HTTP sin estado, estableciendo instancias mínimas para los puntos finales críticos en latencia. Mantener inicialmente la base de datos Oracle con estado en Compute Engine, precedida por un balanceador de carga HTTP(S) interno regional para las API internas, y planificar una futura migración a AlloyDB.

Externalizar el estado de sesión y configuración

Razón: Evitar problemas de sesión local en las instancias y permitir un escalado automático seguro. Almacenar los secretos en Secret Manager con cuentas por servicio para un acceso con privilegios mínimos. Mover el estado de la sesión a Memorystore y los archivos compartidos a Cloud Storage. Esto evita que los usuarios vean datos obsoletos bajo carga máxima.

Establecer controles de identidad y de registro

Razón: Aplicar el principio de privilegio mínimo y procedencia. Almacenar las imágenes en Artifact Registry con el escaneo de vulnerabilidades activado. Asignar una cuenta de servicio de tiempo de ejecución única a cada servicio de Cloud Run y carga de trabajo de GKE (para los componentes que se descompongan más adelante), y conceder solo los roles necesarios (p. ej., Publicador de Pub/Sub).

Implementar CI/CD con estrategias de despliegue seguras

Razón: Reducir las reversiones no planificadas. Construir una canalización que ejecute pruebas unitarias y de integración y despliegue en un entorno de staging. Usar la división de tráfico de Cloud Run para enviar en modo canary del 5 al 10% del tráfico a las nuevas revisiones y permitir una reversión rápida. Para los cambios en la base de datos basada en VM, usar patrones de migración de esquema azul-verde para desacoplar los despliegues de la aplicación y de la base de datos.

Descomponer primero los dominios de alto cambio

Razón: Valor incremental con menor riesgo. Aplicar un patrón estrangulador (strangler pattern): separar la entrega de notificaciones como un microservicio en GKE para aprovechar el HPA para los picos de carga y Pub/Sub para el desacoplamiento. Mantener el resto del monolito como un monolito modular en Cloud Run mientras las interfaces se estabilizan.

Diseñar el escalado automático y la descarga de carga (load shedding)

Razón: Gestionar las ráfagas de tráfico sin fallos en cascada. Configurar la concurrencia y las instancias mínimas de Cloud Run por punto final; establecer límites de tasa en Cloud Armor en el balanceador de carga HTTP(S) global para protegerse contra picos de tráfico no autenticado. Para los servicios de GKE, habilitar el HPA sobre métricas personalizadas (solicitudes por segundo) y aprovisionar un pequeño búfer de nodos a través del escalador automático de clústeres.

Preparar los servicios con estado y las rutas de datos

Razón: Asegurar la durabilidad y el rendimiento. Para los reintentos de notificación en GKE, usar una tabla de Bigtable con clave por cliente-región y cubos de tiempo para almacenar el estado de entrega transitorio con altas tasas de escritura. Para una conectividad privada y consistente con el ERP local durante la transición, usar Dedicated Interconnect con Cloud Router.

Ejecutar pruebas de resiliencia y rendimiento

Razón: Validar los SLO antes del cambio completo. Ejecutar flujos de usuario sintéticos y aleatorios para activar las capas de escalado automático. Inyectar caos terminando instancias de Cloud Run aleatorias (permitiendo que el plano de control las recree) y desalojando pods de GKE para verificar los PodDisruptionBudgets y las puertas de preparación (readiness gates). Usar Trace para identificar el mayor contribuyente a la latencia de cola y remediarlo.

Operar con barreras de protección de costos y cumplimiento

Razón: Operar de forma sostenible en producción. Establecer presupuestos y alertas por servicio, habilitar CMEK en el almacenamiento sensible donde sea necesario, y usar descuentos por uso confirmado para los grupos de nodos de GKE y AlloyDB una vez que se entienda el estado estable. Configurar políticas de retención de registros y vistas de BigQuery para compartir datos de auditoría de forma segura con los auditores internos.

Este enfoque por fases ofrece estabilidad y observabilidad inmediatas, introduce prácticas de despliegue seguras, descompone progresivamente el monolito a lo largo de los límites naturales del servicio y alinea las elecciones de plataforma con los objetivos de control, latencia, portabilidad, escalado y costo.

← Diseño Organizacional · Todos los dominios · Almacenamiento de Datos →

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