Practice Test #2

An organization-level sink is directionally correct for covering all projects, but Cloud Storage is not appropriate for near real-time SIEM ingestion. Storage sinks are optimized for durable archival and batch processing; SIEMs typically ingest via streaming endpoints. You could build additional components (e.g., notifications + processing), but that adds complexity and may not reliably meet the <60 seconds requirement compared to Pub/Sub.

Enabling Data Access audit logs org-wide is not required for the stated needs and can significantly increase log volume and cost. The requirement is for configuration-changing API calls (covered by Admin Activity logs, enabled by default) and Console sign-in events (identity audit logs). Data Access logs are for read/write access to user data (e.g., object reads), not primarily for admin configuration changes.

Parsing AuthenticationInfo can help identify the principal for many Cloud Audit Logs entries, but it does not solve the core requirements: it does not create org-wide coverage, does not provide a streaming export mechanism, and does not add Console sign-in events if they are not present in Cloud Logging. It is an implementation detail for SIEM enrichment, not one of the two required architectural actions.

Cloud IDS provides managed intrusion detection (based on Palo Alto Networks technology) for monitoring network threats in Google Cloud. It’s appropriate when you want Google-managed detection and alerting, not when you must forward raw mirrored traffic to a third-party NIDS VM. Cloud IDS consumes traffic via Packet Mirroring under the hood, but it does not satisfy the explicit requirement to send a copy of traffic to your own NIDS without altering packets.

VPC Service Controls logs relate to service perimeter events and access to Google-managed services (e.g., BigQuery, Cloud Storage) to reduce data exfiltration risk. They do not capture VPC east-west packet payloads or L4/L7 headers and cannot forward traffic to a network IDS. This option might seem relevant due to “fintech” and compliance, but it’s the wrong telemetry type for packet-level inspection.

VPC Flow Logs provide sampled/aggregated network flow metadata (5-tuple, bytes, packets, TCP flags, etc.) and are useful for traffic analysis and anomaly detection at scale. However, they do not include full packet payloads and cannot reconstruct L7 content. The question explicitly requires examining payloads and forwarding a copy of up to 8 Gbps of traffic, which Flow Logs cannot do.

Google Cloud Armor is an edge security service (WAF and DDoS protection) for external HTTP(S) load balancers and some other front-door scenarios. It does not provide packet capture for internal east-west traffic between subnets, nor does it mirror traffic to a third-party NIDS. It’s commonly confused with general network security tooling, but it’s specifically for protecting internet-facing applications.

Granting roles/resourcemanager.folderAdmin on the team folder is broader than necessary for the stated requirement. That role is intended for administering the folder itself, including folder management capabilities that exceed simply creating projects beneath it. Because the question explicitly asks to avoid broad administrative control at the folder or organization level, this violates least privilege. It also creates unnecessary risk if the provisioner service account is compromised, since the blast radius extends to folder administration rather than only project creation.

Granting roles/editor at the organization level is excessively permissive and clearly conflicts with least-privilege design. It provides broad access across organizational resources and does not create a strong, centrally enforced boundary limiting project creation to one specific folder. Telling squads to apply finer-grained IAM later is reactive rather than preventive and leads to inconsistent governance. This option is therefore both overprivileged and operationally weak for centralized control.

roles/resourcemanager.folderIamAdmin allows the principal to manage IAM policy on the folder, which is a sensitive administrative capability. That permission can enable privilege escalation because the service account could potentially grant itself or others additional access. It also does not directly solve the core need of controlled project creation under only one assigned folder. Since the question asks for a centrally managed, least-privilege approach that avoids broad administrative control, this option is not appropriate.

Incorrect. There is no standard, Google-recommended “enable-auto-rotate” capability for user-managed service account keys as described. Google’s guidance is to avoid long-lived keys where possible, and if keys are required, rotate them via a controlled process (create new key, deploy, then delete old). Relying on a nonexistent/incorrect command would not meet the 90-day policy or the 2-minute reduced-capacity requirement.

Incorrect. Key rotation is not typically performed by supplying a “NEW_KEY” to a rotate command for service account keys. In Google Cloud, you create a new key for the service account, distribute it securely (here, via Secret Manager), update workloads, and then delete the old key. A single-step “rotate” command is misleading and doesn’t address safe rollout, verification, or Secret Manager versioning.

Incorrect. Keeping the old key on VMs for 30 days increases exposure and undermines the purpose of rotation. It also conflicts with least privilege and credential hygiene: old keys should be revoked once the new key is confirmed working. If rollback is needed, use Secret Manager versioning and controlled deployment, not lingering key files on disk (which are prone to theft and hard to audit).

Cloud KMS protects data by encrypting it at rest and controlling access to encryption keys, which is valuable for confidentiality and key management. However, encryption does not inspect the contents of transcripts or summaries and does not remove sensitive values before they are sent to a model or shown to users. Once the application decrypts the data for processing, any PII is still present unless a separate inspection and redaction step is applied. Therefore, KMS is useful as a complementary control but does not satisfy the core requirement in the question.

VPC Service Controls helps reduce the risk of data exfiltration by placing supported services inside a service perimeter and restricting access paths. That control governs where data can move, but it does not analyze request or response payloads to determine whether they contain PII. Sensitive data could still be passed to the model and returned in summaries entirely within the perimeter, which would still violate the stated policy. As a result, VPC-SC is defense in depth, not the primary solution for content redaction.

A third-party Marketplace product might offer scanning or redaction features, but the question asks for the most appropriate managed and scalable Google Cloud control. Introducing an external product adds procurement, integration, operational, and compliance review overhead, and it is not the standard native answer for Google Cloud certification scenarios. The option also emphasizes encryption, which still does not inherently guarantee that PII is removed from prompts and summaries before use. Cloud DLP is purpose-built for sensitive-data inspection and de-identification, making it the better fit.