CertifyDeck
Empieza gratis
Todos los resúmenes
Professional Security Operations Engineer · CHEAT SHEET

Google Cloud Certified Professional Security Operations Engineer

Conceptos clave agrupados según el peso oficial del examen.

Descargar en PDF (gratis, sin registro)

1. Platform operations

13–13%

Enhancing detection and response

  • Google SecOps recibe datos de Google Cloud por ingesta directa (Cloud Logging, Cloud Asset Metadata y hallazgos de Security Command Center Premium) o por Cloud Storage cuando hay que filtrar antes. Los registros Data Access conviene filtrarlos para evitar volumen sin valor, y los hallazgos de SCC no admiten filtro. Para amenazas del navegador se reenvían los registros de Chrome Management con el conector de Chrome Enterprise.
  • El Content Hub de Google SecOps reúne Content Packs (ingesta, detecciones seleccionadas y paneles), integraciones de respuesta, playbooks, bloques y búsquedas guardadas. Tras instalar una integración hay que configurar sus conectores, acciones y una instancia por entorno antes de usarla en un playbook. Las actualizaciones se prueban antes en el modo staging del IDE, y Dynamic Mode elige la instancia del entorno del caso.
  • Cada herramienta cubre un hueco distinto: Security Command Center detecta en registros (Event Threat Detection, con módulos personalizados), sin agentes (VM Threat Detection) y en tiempo de ejecución (Container y Cloud Run Threat Detection); Cloud Logging avisa con alertas basadas en registros sin pasar por el SIEM; y Google SecOps correlaciona hallazgos de SCC con otros registros mediante reglas y detecciones seleccionadas.
  • La matriz MITRE ATT&CK de Google SecOps muestra la cobertura por técnica: una tarjeta con cero reglas y tipos de registro disponibles es una oportunidad de detección. Las reglas propias cuentan solo con la clave technique en sus metadatos, y el cálculo se afina por estado en vivo y de alertas. Los conjuntos Managed Detection Testing comprueban que los datos tienen el formato que esperan las detecciones seleccionadas.
  • Gemini en Google SecOps genera consultas de búsqueda y reglas YARA-L a partir de lenguaje natural, resume casos y ayuda a crear playbooks. El Triage and Investigation Agent decide si una alerta del SIEM es verdadero o falso positivo con GTI, búsquedas y árbol de procesos; no procesa alertas de conectores de SOAR. Integrado en un playbook, su veredicto y confianza permiten ramificar la respuesta.

Configuring access for human and non-human identities

  • Los usuarios entran en Google SecOps con Cloud Identity o Google Workspace, o con un IdP SAML u OIDC mediante Workforce Identity Federation (solo SSO iniciado por el proveedor de servicios). El servidor MCP remoto de SecOps usa OAuth 2.0 con IAM, el rol MCP Tool User y, para federados, un proveedor dedicado; los agentes de producción usan su propia identidad. La API de GTI usa claves en la cabecera x-apikey.
  • El acceso a funcionalidades de Google SecOps (feature RBAC) se controla con IAM en el proyecto vinculado: roles predefinidos como Chronicle API Admin, Editor, Viewer y Limited Viewer, o roles personalizados con permisos chronicle.*. Con Workforce Identity Federation se asigna google.groups y se conceden roles a principalSet de grupos. En proyectos compartidos, una condición sobre modifiedGrantsByRole limita qué roles concede un administrador.
  • Data RBAC limita qué datos ve cada usuario de Google SecOps mediante ámbitos formados por etiquetas (tipo de registro, namespace o etiquetas propias). El usuario con ámbito recibe Chronicle API Restricted Data Access con una condición de IAM sobre el nombre del ámbito; el acceso global prevalece. Reglas, tablas de datos y listas de referencia también se vinculan a ámbitos, y las detecciones seleccionadas solo las ven usuarios globales.
  • Google SecOps escribe registros de auditoría con el servicio chronicle.googleapis.com: la actividad de administración (crear reglas, actualizar feeds) siempre se registra, y para guardar las búsquedas UDM hay que activar Data Read en los registros de acceso a datos de Chronicle API. Se consultan en Logs Explorer por principalSubject y methodName; leerlos exige Private Logs Viewer y los principales exentos reducen volumen.
  • Las automatizaciones deben usar identidades no humanas con mínimo privilegio: una cuenta de servicio asociada al recurso o suplantada con Workload Identity (lo que recomienda la integración de Security Command Center) en vez de claves JSON; una clave de API estándar no identifica a ningún principal. En GTI se usan claves de cuentas de servicio del grupo, y el servidor MCP de SecOps exige MCP Tool User más un rol de Chronicle API.

2. Data management

20–20%

Ingesting logs for security tooling

  • El recopilador de Bindplane (basado en OpenTelemetry) lee canales de Windows Event y los envía con un exportador por tipo de registro (WINEVTLOG, WINDOWS_SYSMON); a gran escala se usan pasarelas tras un balanceador. Para Google Cloud, la ingesta directa reenvía Cloud Logging, Cloud Asset Metadata y hallazgos de SCC Premium sin filtrar por hallazgo; los registros de aplicaciones de GKE van por Cloud Storage y un feed.
  • Cada regla de Event Threat Detection indica qué registros necesita: Cloud DNS para dominios maliciosos, flujo de VPC, firewall o Cloud NAT para IP maliciosas, registros de acceso a datos (con pgAudit en Cloud SQL para PostgreSQL) para bases de datos, y Workspace solo con activación a nivel de organización. En Google SecOps, cada conjunto de detecciones seleccionadas documenta sus fuentes, como GCP_RUN o el contexto de Cloud Asset Metadata.
  • Cada parser corresponde a un único tipo de registro y convierte el registro sin procesar en UDM; lo que no asigna se queda en el registro sin procesar. La página Parsers solo muestra parsers prediseñados de tipos ya ingeridos, y Compare parsers enseña la diferencia de código y la salida UDM de una muestra editable. Desactivar las actualizaciones automáticas fija la versión; Skip update crea un parser personalizado.
  • Una extensión del parser añade asignaciones a un parser predeterminado o personalizado sin sustituirlo; un parser personalizado sí lo sustituye y deja fuera las actualizaciones. Hay una extensión por tipo de registro, con enfoque sin código (JSON sencillo) o de fragmento de código (XML, CSV, Grok), y sus asignaciones prevalecen. Los campos repetidos admiten Append o Replace, y solo se aplica a datos nuevos salvo que se pida un Log Replay.
  • La normalización convierte cada registro en un evento UDM con metadata.event_type, marca de tiempo y al menos un nombre (principal, target, src, intermediary, observer, about), de modo que fuentes distintas comparten semántica y reglas. Los espacios de nombres separan activos con IP solapadas, y el enriquecimiento y el alias añaden contexto en la ingesta; para cobertura total se usan tablas de datos y uniones con el grafo de entidades.

Implementing a baseline of user, asset, and entity context

  • La inteligencia relevante es la que toca tu entorno: la pestaña IOC Matches muestra los indicadores de los feeds vistos en tus eventos (con coincidencia retroactiva sobre datos históricos), ATI prioriza esas coincidencias (Active Breach, High, Medium), el Emerging Threats Center cruza campañas de GTI con tus IoC y reglas activadas, y los threat profiles de GTI recomiendan actores y campañas según sector y región.
  • Los datos de eventos (Cloud Audit Logs, el System Log del IdP, Sysmon, DNS) registran acciones y se normalizan como eventos UDM; los datos de entidad (OKTA_USER_CONTEXT, AZURE_AD_CONTEXT, CMDB, Cloud Asset Metadata como GCP_IAM_CONTEXT) describen usuarios y activos y alimentan el Entity Context Graph. El contexto tiene un intervalo de validez y se consulta con campos graph.*, no con una búsqueda UDM de eventos.
  • El alias vincula indicadores de un mismo activo o usuario (DHCP enlaza IP, MAC y hostname; CS_EDR enlaza ID de activo y hostname) y permite enriquecer los eventos. Cada tipo sigue su lógica: hashes por primera coincidencia, activos combinando hostname, MAC y asset_id con la IP solo como alternativa, y siempre dentro del mismo espacio de nombres. Para cobertura completa en reglas, se recomienda unir con el grafo de entidades.

Configuring and Ingesting Threat Intelligence

  • Los IoC de terceros se ingieren con el tipo de registro de IoC adecuado (MISP_IOC, STIX, CSV_CUSTOM_IOC...) para que el parser los convierta en entidades del ECG con source_type ENTITY_CONTEXT, metadatos de amenaza e intervalo de validez; los datos de GTI llegan con la integración BYOL (GCP_THREATINTEL) o con ATI. Las reglas YARA-L unen eventos con esas entidades, y un retrohunt sin alertas revisa el histórico.
  • Google Threat Intelligence ofrece Livehunt (reglas YARA sobre cada archivo que analiza, con avisos en IoC Stream) y Retrohunt (archivos pasados y corpus de goodware para falsos positivos), Digital Threat Monitoring (monitores sobre la web y la dark web: credenciales, marcas, dominios), Private Scanning de archivos y URL sin compartirlos, y Google Insights, donde pesa más el número de organizaciones que los avistamientos.

3. Threat hunting

18–18%

Performing threat hunting across environments

  • Las búsquedas UDM de Google SecOps rinden más filtrando por campos optimizados (metadata.event_type, principal.hostname, target.ip) y acotando el intervalo; los campos enumerados no admiten expresiones regulares, las listas largas de valores van en tablas de datos con in, Gemini convierte frases en lenguaje natural en consultas editables, y el intervalo de búsqueda sigue la hora del evento, no la de ingesta.
  • Las búsquedas estadísticas UDM combinan filtro, match (agrupación, también por día u hora con by u over every), outcome con funciones como count, count_distinct, sum o earliest, y order y limit; no admiten condition ni la ventana over de las reglas. Los campos vacíos cuentan como valores, así que hay que filtrarlos. Para análisis de comportamiento continuo, Risk Analytics for UEBA ofrece reglas gestionadas.
  • Logs Explorer filtra entradas con el lenguaje de consulta de Logging (log_id, protoPayload, SEARCH) pero no agrega; para contar y agrupar se usa Observability Analytics con SQL. En Google SecOps, la búsqueda UDM cubre eventos normalizados y la búsqueda de registros sin procesar (raw=) encuentra cadenas no analizadas. La exportación a BigQuery (datalake: events, rule_detections, ioc_matches, entity_graph) permite análisis histórico y uniones SQL.
  • La búsqueda de amenazas en colaboración con respuesta a incidentes se apoya en SIEM Search: los eventos UDM y las detecciones encontrados pueden adjuntarse a un caso nuevo o existente como evidencia, y las búsquedas guardadas con variables ${...} se comparten con la organización. El Threat Hunt Agent crea casos etiquetados Threat Hunt, y las listas de seguimiento elevan el riesgo solo de las entidades indicadas.
  • Las hipótesis de búsqueda pueden nacer de la exposición (rutas de ataque, combinaciones tóxicas y puntuaciones de Risk Engine en SCC, que son simulaciones y no evidencias), de la inteligencia (Threat Profiles de GTI y el feed del Emerging Threats Center filtrado por sector y coincidencias de IoC) y del comportamiento, como dominios con first_seen_time reciente en el Entity Context Graph.

Leveraging threat intelligence for threat hunting

  • Para buscar IOC en el histórico de Google SecOps se usan búsquedas UDM con tablas de datos (in %tabla.columna), la búsqueda de registros sin procesar para cadenas no mapeadas a UDM y BigQuery para IOC multidimensionales como IP y puerto. La coincidencia de IOC es también retroactiva, y las entidades IOC propias necesitan metadata.threat para coincidir más allá de unos cinco días.
  • Para detectar patrones de ataque nuevos, el Emerging Threats Center cruza campañas de GTI con tu telemetría, muestra reglas asociadas y desactivadas, y Gemini redacta reglas para los huecos que un analista aprueba. ATI prioriza IoC por Active Breach, High y Medium. En SCC, Risk Engine detecta combinaciones tóxicas y puntos de estrangulamiento, visibles en Issues y Findings.
  • La puntuación de riesgo de entidad de Google SecOps suma la detección de mayor riesgo más una ponderación del resto, se normaliza entre 1 y 1000 y se calcula en ventanas de 24 horas o 7 días. Las reglas pueden asignar riesgo con risk_entity_to_score, consultar graph.risk_score indicando la ventana o alertar con eventos ENTITY_RISK_CHANGE; la página de la entidad muestra sus hallazgos y anomalías.
  • Un retrohunt aplica una regla YARA-L a datos históricos y conviene lanzarlo con las alertas desactivadas. Las reglas de varios eventos reevalúan bloques en pasadas de ajuste, ampliables con Ensure enrichment completeness. Los resultados de búsqueda UDM y de reglas difieren, por ejemplo con campos repetidos (usar any). Para comparar con SQL, BigQuery recibe la exportación de SecOps y Cloud Logging ofrece conjuntos vinculados.
  • La búsqueda proactiva con inteligencia combina Google Threat Intelligence (Livehunt aplica reglas YARA a cada archivo analizado y avisa en el IoC Stream; Retrohunt revisa el histórico y un corpus de goodware para probar falsos positivos) con reglas de Google SecOps: reglas YARA-L sobre el ATI Fusion Feed y conjuntos Mandiant Hunting con las alertas desactivadas.

4. Detection engineering

20–20%

Developing and implementing mechanisms to detect risks and identify threats

  • Google SecOps compara de forma automática los eventos UDM con los IOC de Google y de feeds propios, en tiempo real y de forma retroactiva, y muestra en IoC Matches los activos y usuarios implicados. Applied Threat Intelligence prioriza esas coincidencias con GTI y, para reglas a medida, YARA-L une eventos, indicadores del Entity Context Graph y contexto de usuarios o activos.
  • Para encontrar actividad anómala, la búsqueda UDM admite estadísticas con match, outcome, order y limit; la búsqueda de registros sin procesar (raw= y parsed = false) cubre datos sin normalizar, y las funciones de métricas comparan la actividad con una referencia de 30 días dentro de una regla. Los campos repetidos se evalúan distinto en búsqueda y en reglas, que necesitan any.
  • Las reglas en vivo evalúan los datos nuevos y el retrohunt aplica la misma lógica al historial, mejor con las alertas desactivadas. En la sección match se elige entre ventanas de salto (over), fijas (by) y deslizantes ancladas a un pivote (after o before), y las reglas multievento admiten un retardo de asentamiento y ejecuciones de ajuste para los datos que llegan tarde.
  • Las tablas de datos de Google SecOps son tablas de búsqueda con varias columnas tipadas que las reglas usan por columna (in) o por fila (=, >=), y en este caso todas las condiciones deben cumplirse en la misma fila y la regla necesita sección match. Las reglas pueden escribir variables de outcome con write_row, y las filas pueden caducar con un TTL de tabla o de fila.
  • Risk Analytics suma el riesgo de alertas y detecciones en una puntuación por entidad (usuario o activo), con ponderación, coeficiente de alertas cerradas y puntuaciones por defecto configurables. Las detecciones seleccionadas de Risk Analytics for UEBA comparan la actividad con el historial; en reglas propias, $risk_score fija el valor y $risk_entity_to_score la entidad, y las watchlists aplican un factor a entidades concretas.

Leveraging threat intelligence for detection

  • Applied Threat Intelligence asigna prioridades Active breach, High y Medium a las coincidencias de IoC según el veredicto y la severidad de GTI, la presencia en investigaciones de Mandiant y otros factores; las prioridades media se dejan sin alertas para no generar ruido. En reglas propias, $risk_score en outcome gradúa el riesgo por IoC y ENTITY_RISK_CHANGE permite alertar por umbral de riesgo de la entidad.
  • Para buscar IoC recientes en la telemetría de Google SecOps, la búsqueda UDM con campos agrupados (hash, ip, domain) cubre varios campos a la vez y la búsqueda de registros sin procesar queda para datos sin normalizar. La coincidencia automática de IoC es en tiempo real y retroactiva, las reglas solo usan indicadores cuyo metadata.interval cubre el evento y la tabla datalake.ioc_matches permite análisis históricos en BigQuery.
  • Para medir alertas repetitivas en Google SecOps se prueba la regla sobre varios días, se revisa el panel Procedural Filtering y se usan los paneles seleccionados de reglas y detecciones. Para reducir falsos positivos: suppression_window para limitar repeticiones, exclusiones (solo en reglas seleccionadas, probadas con Test Exclusion) y tablas de datos con listas de exclusión reutilizables en reglas personalizadas.
  • Las reglas YARA-L de Google SecOps pueden unir eventos UDM con indicadores de Google Threat Intelligence en el grafo de entidades. Las reglas que usan los feeds antiguos de Mandiant deben pasar al feed GTI_IOC, filtrando por stable = true para usar solo indicadores verificados; los campos de asociación (malware, actor) acotan la amenaza. Sin ATI, la integración BYOL normaliza los datos de GTI como GCP_THREATINTEL.
  • Applied Threat Intelligence compara la telemetría con IoC seleccionados por Google Threat Intelligence y prioriza las coincidencias; sus reglas compuestas agrupan detecciones de la misma campaña o actor. El Emerging Threats Center muestra campañas y operaciones de GTI con coincidencias de IoC, reglas asociadas y desactivadas, cobertura MITRE ATT&CK y las entidades potencialmente afectadas de tu entorno.

5. Incident response

18–18%

Containing and investigating security incidents

  • Para recoger pruebas de un incidente en Google Cloud se hace primero una instantánea de los discos de la VM, posible con el disco conectado, sabiendo que no captura la memoria; los datos volátiles se recogen con herramientas forenses en vivo tras reducir el acceso, y la VM se abandona de su grupo gestionado antes de aislarla. En Google SecOps, Download as CSV exporta los eventos UDM de una detección multievento.
  • En Security Command Center, el panel Threats muestra la evolución y el reparto de los hallazgos de amenazas, y cada hallazgo incluye su JSON, enlaces a MITRE ATT&CK y, si existe, el campo VirusTotal Indicator. En Google SecOps, la vista de una alerta ofrece las pestañas Overview, Graph y Alert history; el grafo depende de los sustantivos UDM incluidos en la sección outcome de la regla.
  • Para valorar alcance y severidad: Cloud Audit Logs en Logs Explorer (los de acceso a datos están desactivados por defecto salvo en BigQuery y exigen Private Logs Viewer), hallazgos relacionados de vulnerabilidades y configuración en Security Command Center, Vulnerability Assessment for Google Cloud para CVE sin agentes y Compliance Manager para infracciones de controles. Una puntuación de exposición alta no prueba un ataque.
  • La colaboración se apoya en integraciones de ticketing como Jira (Create Alert Issue y jobs que sincronizan comentarios y cierre) y en datos de cierre estructurados: un campo Disposition en el diálogo Close Case da la tasa de falsos positivos por regla y la etapa Improvement marca casos para refinar detecciones. En Security Command Center, un hallazgo de amenaza real pasa a INACTIVE solo tras investigar la causa raíz.
  • La contención se ejecuta desde playbooks con integraciones de respuesta: Stop Instance en Google Cloud Compute (tras copiar los discos para el análisis forense, porque lo eliminado no se recupera), Contain Endpoint en CrowdStrike Falcon, Disable Service Account en Google Cloud IAM (reversible) y Revoke User Sessions en Google Workspace. Elige siempre la acción que corta el ataque sin destruir evidencias ni romper dependencias desconocidas.

Building, implementing, and using response playbooks

  • Automatiza el enriquecimiento y la clasificación, y reserva la contención para cuando hay certeza o aprobación: el playbook de respaldo (prioridad 3, trigger All) no es destructivo, las acciones sensibles pasan a Manual con Approval link para aprobadores externos y las ramas del Triage and Investigation Agent usan veredicto y confianza. Los fallos se gestionan con Skip step o con ramas If previous action fails.
  • Un threat profile de Google Threat Intelligence recomienda actores, campañas y malware según sector, región y motivación; el Threat Map destaca lo relevante y frecuente a la vez, y sus IoCs se exportan o se siguen en el IoC Stream. En los playbooks, Get Related Associations vincula las entidades a actores y campañas, y el bloque de enriquecimiento debe ejecutar los servicios según el tipo de entidad y sin llamadas innecesarias.
  • Las integraciones de respuesta se instalan desde el Content Hub y aportan conectores, acciones y jobs. Elige la que cumpla el requisito: Workload Identity y un rol personalizado en Google Cloud Compute, un Remote Agent con Run Remotely para redes sin acceso entrante, Microsoft Graph Mail o Gmail para preguntar por correo y esperar la respuesta, y acciones de espera de ServiceNow para pausar el playbook hasta que TI resuelva.
  • Los patrones nuevos se detectan revisando las alertas que caen en el playbook de respaldo y se convierten en playbooks específicos. Gemini puede generarlos a partir de un prompt con objetivo, trigger, acciones y condiciones, usando solo integraciones instaladas; las secuencias comunes se crean como bloques reutilizables y todo se prueba en el Playbook Simulator con casos de prueba y datos simulados antes de activarlo.
  • Playbook monitoring revela carencias: Redundant indica playbooks que no se adjuntaron por el límite de uno automático por alerta, y Waiting for User Action señala esperas manuales que pueden escalarse con Time to respond y una rama propia. Las tareas repetidas sobre muchas entidades se automatizan con bucles de playbook, y las peticiones informales de otros equipos con plantillas de petición atendidas por un playbook.

Implementing the case management lifecycle

  • Los SLA de SOAR pueden ser de alerta o de caso; un SLA de caso por etapa solo corre en esa etapa y no se reinicia al volver, uno por prioridad se reinicia al cambiarla, y una acción de playbook prevalece sobre etapa y prioridad. Al cerrar, Reason y Root Cause se completan con campos personalizados de ámbito Case o All, como Disposition, que los paneles pueden consultar.
  • Para escalar, la etapa Assessment indica evaluación por el siguiente nivel, y marcar un caso como Incident lo pone en Critical, en la etapa Incident (irreversible), lo asigna al SOC Manager y avisa a todos los analistas. En playbooks, Raise Incident escala con un rol de SOC, y una acción Manual asignada a un rol con Time to respond permite escalar si falla por plazo.

6. Observability

11–11%

Developing and maintaining dashboards to provide insights

  • Los KPI de respuesta se leen en paneles predefinidos: el Response Health Hub compara el MTTR de cierres automáticos y manuales, separa el tiempo total del playbook del tiempo activo de las acciones y muestra colas, adjuntos, fallos y ejecuciones terminadas. El panel Triage and Investigation Agent Metrics sigue volumen, veredictos y la valoración de los usuarios sobre esos veredictos.
  • Los paneles de Google SecOps usan consultas YARA-L 2.0 con un prefijo por origen de datos (eventos, detection, ioc, ingestion, case, playbook...), con match u outcome y sin condition. Los predefinidos no se editan: se duplican. Todos respetan data RBAC; los datos de SOAR solo los ven usuarios globales, y las métricas de ingesta exigen ámbitos con etiquetas estándar como el namespace.
  • Cada plataforma genera sus informes: en SOAR, el informe del caso (DOC, XLSX o CSV) con muro y acciones; en SecOps, descargas de paneles (CSV completo, PDF y PNG solo lo visible) e informes programados por correo o enlace a Cloud Storage; en SCC, el informe de riesgos en PDF con rutas de ataque y combinaciones tóxicas; en GTI, PDF de informes y resúmenes Report Digest.

Configuring health monitoring and alerting

  • La salud de la ingesta se vigila con métricas de Google SecOps en Cloud Monitoring: Total ingested log count con Metric absence y agrupado por collector_id o ingestion_source detecta orígenes silenciosos, y Total ingested log size controla el volumen diario contratado, no quota_limit. El Health Hub muestra orígenes y parsers fallidos o irregulares, Last Ingested frente a Last Normalized y fallos silenciosos de credenciales de feeds.
  • Los paneles de Google SecOps combinan gráficos de varios orígenes de datos (métricas de ingesta, detecciones, casos, playbooks) con consultas YARA-L que llevan sección match u outcome. Los paneles seleccionados, como Health Hub o Response Health Hub, son de solo lectura: se duplican para personalizarlos. Para unir métricas, políticas de alertas y registros de Google Cloud en una vista se usa un panel personalizado de Cloud Monitoring.
  • Google SecOps publica métricas de ingesta en Cloud Monitoring (Chronicle Collector Ingestion y Normalizer, Outofband para feeds) que se filtran por log_type, feed_name, collector_id o state. Para el volumen diario se usa Total ingested log size con ventana de un día y umbral, no quota_limit, y conviene agregar con sum y agrupar por project_id para evitar falsas alertas.
  • Los canales de notificación de Cloud Monitoring incluyen correo, SMS, Slack, PagerDuty, webhooks, Mobile App y Pub/Sub. Se recomienda redundancia con correo o Pub/Sub, ya que Slack, PagerDuty, webhooks y Mobile App comparten un punto de fallo; para automatización o endpoints privados se usa Pub/Sub, autorizando a la cuenta de servicio de notificaciones como Pub/Sub Publisher.
  • En instancias con proyecto BYOP, Google SecOps envía los registros de actividad de los feeds a Cloud Logging (log_id chronicle.googleapis.com/ingestion_activity; los feeds de STS usan storage_transfer_job). Debug with logs abre Logs Explorer filtrado por el feed, Ask Gemini Cloud Assist responde sobre volúmenes y errores, y el Health Hub muestra el último problema de cada origen.
Practicar esta certificación