Google ACE: Almacenamiento, bases de datos y servicios de datos — Guía de estudio

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Forma parte de la Google Associate Cloud Engineer — 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

Esta sección proporciona una referencia práctica y centrada en las operaciones para los servicios de almacenamiento, bases de datos y análisis de datos de Google Cloud. Pone énfasis en los patrones de configuración, el control de acceso, los mecanismos de durabilidad, las características de rendimiento y costo, y las prácticas de recuperación segura. El objetivo es ayudarle a decidir qué servicio utilizar para una carga de trabajo determinada, comprender las compensaciones operativas y anticipar los modos de fallo comunes.

Diseño, acceso, ciclo de vida y protección de Cloud Storage

Cloud Storage es un almacenamiento de objetos duradero y de alta disponibilidad para datos no estructurados y copias de seguridad.

Buckets y objetos: Los buckets son espacios de nombres globales en una ubicación (región o birregional/multirregional) que contienen versiones de objetos inmutables. Elija la ubicación del bucket para minimizar el egreso y cumplir con la residencia de datos.
Clases de almacenamiento: Use Standard (acceso frecuente), Nearline (mín. ~30 días), Coldline (mín. ~90 días) y Archive (mín. ~365 días) según la frecuencia de acceso. Para las copias de seguridad de recuperación ante desastres (DR), Coldline es un valor predeterminado común. Puede mezclar clases por objeto dentro de un bucket.
Reglas de ciclo de vida: Automatice las transiciones y eliminaciones mediante las condiciones Age, CreatedBefore, MatchesStorageClass y NoncurrentVersion. Ejemplo para hacer la transición a los 90 días y eliminar a los 365 días:
1. lifecycle.json:

undefined

Aplicar:

undefined

Retención y retenciones legales: Las políticas de retención impiden la eliminación o modificación de objetos antes de que transcurra el período; bloquear la política es irreversible. Las retenciones legales son por objeto y deben eliminarse antes de la supresión.

Control de acceso e intercambio:

Uniforme vs. detallado: Prefiera el acceso uniforme a nivel de bucket (UBLA) para gestionar permisos solo con IAM. El acceso detallado (ACL de objeto) es heredado y complica la auditabilidad y la propagación. Habilitar UBLA deshabilita las ACL y puede afectar inmediatamente a las integraciones existentes que dependían de ellas.
URL firmadas: Para un acceso de corta duración sin una identidad de Google, use URL firmadas. Evite los archivos de claves de cuentas de servicio firmando con IAM:

undefined

Asegúrese de que la cuenta de servicio tenga el rol de Creador de Tokens de Cuenta de Servicio (service account token creator) sobre sí misma o a través de un rol de firmante.

Cifrado: Cifrado del lado del servidor por defecto; habilite CMEK en el ámbito del bucket o por objeto cuando necesite control sobre las claves y los registros de auditoría. Supervise la disponibilidad y rotación de claves de KMS; la falta de disponibilidad de CMEK bloqueará las subidas y los descifrados.
Control de versiones: Habilite el control de versiones de objetos para mantener versiones no actuales después de sobrescrituras/eliminaciones. Combínelo con reglas de ciclo de vida para que venzan las versiones no actuales y controlar el crecimiento del almacenamiento. Tenga en cuenta la lógica de listado del lado del cliente cuando existen muchas versiones.

Modos de fallo y mitigación:

Eliminación o sobrescritura accidental: Use el control de versiones y las políticas de retención. Para un cumplimiento estricto, bloquee la retención.
Acceso público mal configurado: Aplique la prevención de acceso público y UBLA. Audite periódicamente con Cloud Asset Inventory y el analizador de políticas.
Costos excesivos: Las reglas de ciclo de vida, las clases a nivel de objeto y el pago por parte del solicitante (requester pays) reducen las sorpresas. Supervise con las métricas y presupuestos de Cloud Monitoring.

Comandos útiles:

Crear un bucket con UBLA y retención:

undefined

Almacenamiento en bloque y de archivos para cargas de trabajo de computación

Elija el almacenamiento según el patrón de acceso, las necesidades de rendimiento y los requisitos de durabilidad para Compute Engine y GKE.

Persistent Disk (PD): Almacenamiento en bloque duradero, zonal o regional. Tipos: Standard (HDD) para rendimiento secuencial; Balanced (pd-balanced) y SSD (pd-ssd) para baja latencia e IOPS. El PD regional se replica sincrónicamente entre zonas, permitiendo una recuperación más rápida. Al PD se le pueden tomar instantáneas (snapshots), cambiar su tamaño en línea y adjuntarse en modo de solo lectura a varias VM (escritor único para lectura-escritura).
- Compensaciones: Costos de IOPS más altos en SSD; el HDD es rentable pero tiene alta latencia para E/S aleatoria. El PD regional cuesta más pero reduce el RTO.
Local SSD: Almacenamiento efímero conectado por NVMe o SCSI con IOPS muy altos y baja latencia. Los datos se pierden al detener la VM o durante el mantenimiento del host; úselo solo para cachés efímeros o datos replicados. Haga una copia de seguridad o replique en otro lugar para evitar la pérdida de datos.
Filestore: NFS gestionado para semántica de archivos compartidos POSIX. Los niveles básicos son zonales; los niveles Enterprise y superiores ofrecen alta disponibilidad (HA) regional con replicación síncrona y mayores IOPS. Ideal para GCVE, almacenamiento temporal (scratch) de HPC, renderizado de medios y aplicaciones que necesitan bloqueo de archivos compartido.
- Compensaciones: NFS introduce semántica de caché y bloqueo del lado del cliente; el rendimiento y la latencia difieren según el nivel; no es adecuado para E/S aleatoria pequeña con latencias de microsegundos de un solo dígito como el Local SSD.

Consideraciones sobre fallos:

Mantenimiento del host: Pérdida de datos del Local SSD; protéjase con la replicación de la aplicación.
Interrupciones zonales: Interrupciones del PD zonal y de Filestore Básico; use PD regional o Filestore Enterprise para alta disponibilidad (HA).
Consistencia de las instantáneas: Para instantáneas (snapshots) de PD consistentes con la aplicación, coordine con la congelación del sistema de archivos (filesystem freeze) o la quiescencia nativa de la base de datos para evitar ventanas de recuperación de fallos (crash recovery).

Bases de datos y servicios de datos gestionados

Cloud SQL (MySQL, PostgreSQL, SQL Server gestionados):

Configuración: Elige la forma de la máquina, el tipo de almacenamiento, las conexiones (se prefiere IP privada), las redes autorizadas si se usa IP pública, las ventanas de mantenimiento y los insights para diagnósticos de rendimiento. Usa la agrupación de conexiones (p. ej., Cloud SQL Auth Proxy, PGbouncer) para mantenerte dentro de los límites de conexión y CPU.
Alta disponibilidad: Las instancias de alta disponibilidad (HA) regionales despliegan una instancia de reserva (standby) en otra zona con replicación de almacenamiento síncrona; la conmutación por error (failover) es automática. Se debe esperar una breve ventana de indisponibilidad de escritura durante el failover.
Réplicas: Réplicas de lectura para escalar lecturas y descargar tareas de BI; replicación externa para migraciones. Supervisa el retraso de la réplica (replica lag) y diseña lectores idempotentes.
Copias de seguridad y PITR: Habilita las copias de seguridad automatizadas y el registro binario/WAL para la recuperación a un momento dado (point-in-time recovery). Prueba las restauraciones regularmente.

undefined

Modos de fallo: Las transacciones de larga duración bloquean el vacuum/checkpointing; los picos de conexiones causan thrashing; el crecimiento automático del almacenamiento (autogrow) puede detenerse si la cuota es insuficiente. Configura alertas para CPU, memoria, conexiones, retraso de la réplica y uso de disco.

Cloud Spanner:

Escala y regionalidad: Instancias regionales o multirregionales con replicación síncrona y consistencia sólida global. Escala los nodos para el rendimiento (throughput) y el almacenamiento; la ubicación de la región líder influye en la latencia de escritura.
Esquema y claves: Diseña claves primarias para evitar puntos calientes (hotspots); usa claves compuestas con un prefijo con hash o aleatorio para series temporales para distribuir las escrituras. Usa índices secundarios para patrones de consulta y considera almacenar juntas las columnas que se filtran con frecuencia. Mantén las transacciones pequeñas y acotadas para minimizar la contención de bloqueos.
Transacciones: Transacciones distribuidas y fuertemente consistentes con consistencia externa a través de TrueTime. La latencia de escritura está limitada por el quórum; los conflictos producen transacciones abortadas—reintenta con espera exponencial (backoff).

Firestore y Bigtable:

Firestore (modo nativo): Almacén de documentos con colecciones, escuchas en tiempo real (real-time listeners), transacciones que abarcan hasta 500 documentos por transacción y consistencia sólida para lecturas de documentos y la mayoría de las consultas. Ideal para datos de aplicaciones móviles/web, JSON jerárquico y aplicaciones basadas en eventos.
Bigtable: Base de datos de columna ancha para escala de petabytes y latencia inferior a 10 ms. Solo transacciones de una sola fila; diseña las claves de fila (row keys) para evitar el hotspotting. Ideal para series temporales, IoT, personalización y contadores a gran escala. No es para uniones ad-hoc o agregaciones complejas.

Memorystore:

Redis y Memcached: Cachés en memoria para latencia de microsegundos a milisegundos. El nivel Básico no tiene alta disponibilidad (HA); el nivel Estándar proporciona alta disponibilidad regional con conmutación por error automática para Redis. Trátalos como efímeros; no los uses como el sistema de registro (system of record).

BigQuery:

Conjuntos de datos y tablas: Organiza por conjunto de datos (dataset); controla el acceso a nivel de proyecto, conjunto de datos, tabla, columna y fila. Usa tablas particionadas y en clúster para controlar los bytes escaneados y el costo.
Trabajos de carga y consulta: Carga desde Cloud Storage, exportaciones de Cloud SQL o inserciones por streaming. Usa ejecuciones de prueba (dry runs) para estimar el costo:

undefined

Control de acceso: Otorga el rol de Visualizador de datos de BigQuery (BigQuery Data Viewer) a nivel de conjunto de datos para consumidores de solo lectura; usa vistas autorizadas o seguridad a nivel de fila/columna para aplicar el principio de privilegio mínimo.

Compensaciones en movimiento, migración, validación y operaciones de datos

Migración y transferencia:

Database Migration Service (DMS): Para migraciones homogéneas a Cloud SQL con tiempo de inactividad mínimo mediante replicación. Valida el cambio (cutover) con métricas de retraso (lag) y comparaciones de checksums.
Transferencias de Cloud Storage: Storage Transfer Service para transferencias repetitivas o controladas por eventos; gsutil -m rsync para copias sincronizadas únicas con checksums; Transfer Appliance para traslados offline de gran volumen.
Importación/exportación: Cloud SQL exporta a Cloud Storage; la reimportación admite el arranque de PITR y la verificación de datos. BigQuery admite cargas por lotes desde Cloud Storage y exportaciones a Avro/Parquet para su uso en sistemas posteriores (downstream).
Validación: Usa checksums de objetos (CRC32C), recuentos de filas, consultas de muestreo e invariantes a nivel de aplicación. Para BigQuery, compara recuentos o hashes de GROUP BY entre el origen y el destino.

Compensaciones de rendimiento, disponibilidad, capacidad y costo:

Cloud Storage: Optimiza el egreso coubicando la computación; elige las clases según la frecuencia de acceso; usa dual/multi-region para resiliencia entre zonas y mayor disponibilidad a un costo de almacenamiento más alto.
PD/Filestore: SSD para E/S de baja latencia; HDD para rendimiento (throughput); replicación regional para alta disponibilidad (HA); dimensiona correctamente los IOPS para evitar la limitación (throttling).
Cloud SQL: El escalado vertical es simple pero limitado; las réplicas de lectura descargan el tráfico de lectura; la alta disponibilidad (HA) añade disponibilidad pero no capacidad de lectura; la clase de almacenamiento afecta la latencia y el costo.
Spanner: Escala horizontalmente con consistencia fuerte; el costo premium se compensa con RPO/RTO global y un sharding simplificado. Las escrituras son sensibles al diseño de claves y a la latencia de la región líder.
Firestore/Bigtable/Memorystore: Elige según la latencia, el modelo de datos y la consistencia. Las cachés en memoria reducen la carga de la base de datos pero añaden complejidad en la invalidación de la caché.
BigQuery: El costo bajo demanda es proporcional a los bytes escaneados; el particionamiento/clustering y el empuje de predicados (predicate pushdown) reducen el gasto. Las reservas de tarifa plana (flat-rate) intercambian previsibilidad por compromiso.

Resolución de problemas y recuperación segura:

Cloud Storage: Usa el versionado y la retención de objetos para recuperar; examina los registros de acceso a datos de Cloud Logging para auditar eventos de lectura/escritura; asegúrate de que las claves CMEK estén habilitadas durante la recuperación.
PD/Filestore: Restaura desde instantáneas (snapshots) o copias de seguridad (backups); ejecuta fsck y modos de recuperación de base de datos; asegura la consistencia con una inmovilización (quiesce) a nivel de aplicación antes de tomar la instantánea.
Cloud SQL: Restaura a una nueva instancia para PITR para evitar la pérdida de datos en la principal; verifica con pruebas de solo lectura; mantén el firewall y el DNS privado para patrones de cambio (cutover) seguros.
Spanner/Bigtable: Investiga el hotspotting a través del sesgo de acceso a claves (key access skew); usa Monitoring para rastrear la latencia y la limitación (throttling); implementa backoff y reintentos para transacciones abortadas u operaciones con limitación de velocidad.
BigQuery: Diagnostica consultas lentas a través de los detalles de ejecución; añade particiones y clustering; limita el uso de SELECT *; materializa resultados intermedios cuando sea apropiado. Recupera tablas eliminadas dentro de la ventana de time travel restaurando una instantánea o copiando desde un momento de la instantánea.

Escenario de Problema Práctico

Contoso Retail está consolidando sus copias de seguridad y datos de analítica mientras refuerza los controles de acceso y habilita la recuperación a un punto en el tiempo (PITR) para sus sistemas transaccionales. Necesitan: almacenar copias de seguridad de aplicaciones con clasificación automática por niveles (tiering), proporcionar uso compartido de archivos de corta duración a terceros, habilitar PITR para una pequeña carga de trabajo relacional y estimar los costos de las consultas de analítica antes de su ejecución.

Enfoque:

Crear un bucket regional de Cloud Storage con UBLA, retención y ciclo de vida.
- Comando: gcloud storage buckets create gs://contoso-backups –location=us-central1 –uniform-bucket-level-access –default-storage-class=STANDARD gcloud storage buckets update gs://contoso-backups –retention-period=365d gsutil lifecycle set lifecycle.json gs://contoso-backups
- Justificación: UBLA centraliza la autorización en IAM y mejora la auditabilidad. Una retención de un año previene la eliminación accidental. El ciclo de vida transfiere las copias de seguridad a Coldline después de 90 días y las elimina al expirar para controlar los costos.
Otorgar acceso de solo escritura para los trabajos de copia de seguridad a través de una cuenta de servicio dedicada.
- Comando: gcloud storage buckets add-iam-policy-binding gs://contoso-backups –member=serviceAccount:backup-writer@contoso.iam.gserviceaccount.com –role=roles/storage.objectCreator
- Justificación: roles/storage.objectCreator previene la manipulación de metadatos y la relectura de copias de seguridad sensibles, adhiriéndose al principio de privilegio mínimo.
Compartir una copia de seguridad sensible con un proveedor durante cuatro horas usando una URL firmada sin distribuir claves.
- Comando: gcloud storage sign-url gs://contoso-backups/db-dump-2024-09-30.sql.gz –duration=4h –impersonate-service-account share-signer@contoso.iam.gserviceaccount.com
- Justificación: El acceso sin identidad y con límite de tiempo evita la creación de identidades externas o secretos de larga duración. La suplantación (impersonation) utiliza una firma centralizada respaldada por KMS y elimina los riesgos de filtración de claves.
Habilitar las copias de seguridad de Cloud SQL y PITR para la base de datos de pedidos.
- Comando: gcloud sql instances patch orders-sql –backup-start-time=02:00 –enable-bin-log
- Justificación: Las copias de seguridad automatizadas junto con el registro binario/WAL proporcionan puntos de restauración a cualquier segundo dentro de la ventana de retención, protegiendo contra la corrupción lógica y el error del operador.
Probar la recuperación restaurando a una nueva instancia y validando los datos antes del cambio (cutover).
- Comando: gcloud sql backups list –instance=orders-sql gcloud sql instances restore-backup orders-restore –backup-id=LATEST –destination-instance=orders-restore
- Justificación: Restaurar a una instancia separada evita impactar la producción y permite la validación mediante checksums y consultas de muestra antes de cualquier cambio a nivel de DNS o de aplicación.
Estimar el costo de una consulta de BigQuery con una ejecución de prueba (dry run) y optimizar con particionamiento.
- Comando: bq query –use_legacy_sql=false –dry_run=true ‘SELECT COUNT(*) FROM contoso.analytics.sales WHERE sale_date >= “2026-01-01”’
- Justificación: Las ejecuciones de prueba (dry runs) revelan los bytes que se escanearán; asegurar que sale_date sea una columna de partición con un predicado acotado reduce los bytes escaneados y controla los costos bajo demanda.
Monitorear y auditar el acceso.
- Pasos:
  - Habilitar los registros de acceso a datos para Cloud Storage y BigQuery.
  - Configurar alertas de Cloud Monitoring sobre conexiones de Cloud SQL, uso de disco y fallos en las copias de seguridad.
- Justificación: Los registros de acceso a datos proporcionan visibilidad de lectura/escritura a nivel de objeto para el cumplimiento normativo. Las alertas proactivas acortan el MTTR y aseguran que las copias de seguridad y el PITR sigan siendo efectivos.
Documentar modos de fallo y runbooks.
- Pasos:
  - Registrar procedimientos para restauraciones de versiones de objetos, revocación de URL firmadas, PITR de Cloud SQL y recuperación de tablas de BigQuery usando time travel.
- Justificación: Los runbooks claros y probados reducen el riesgo operativo durante incidentes y estandarizan las prácticas de recuperación segura entre los equipos.