Practice Test #3

VPC Service Controls creates service perimeters to reduce data exfiltration risk and control access to Google-managed services from outside a perimeter. It does not provide a scalable delegation model for IAM administration, nor does it inherently prevent a studio admin from viewing/changing IAM on other studios’ projects if they have permissions. It addresses boundary protection, not organizational access administration.

Cloud Identity Organizational Units (OUs) are used for applying identity and device policies within Cloud Identity/Google Workspace. Google Cloud IAM does not support assigning IAM policies directly to Cloud Identity OUs as principals or as a scoping mechanism. Access control in Google Cloud is scoped by resource hierarchy (org/folder/project) and granted to principals like users, groups, or service accounts.

Using project naming conventions with IAM Conditions is fragile and hard to operate at scale. Conditions evaluate request attributes and can be complex to maintain, and naming conventions are not a security boundary (projects can be renamed or created incorrectly). This also doesn’t naturally support delegated administration or prevent cross-studio visibility; it’s an anti-pattern compared to folders and group-based IAM.

Cloud KMS is for managing cryptographic keys and performing encrypt/decrypt/sign operations. While it supports IAM, audit logs, and rotation of keys, it is not a full secret storage system for passwords and API tokens with secret-version retrieval semantics. You could build an envelope-encryption solution, but it adds operational complexity and doesn’t natively satisfy “centrally stored secrets with per-secret IAM controls” and straightforward audited reads like Secret Manager.

Compute Engine guest attributes can store small pieces of data retrievable by the VM, but they are not intended for sensitive secrets governance. They lack dedicated secret lifecycle features such as robust per-secret IAM, built-in versioning/rotation workflows, and standardized secret access audit patterns. The question explicitly prohibits storing secrets in guest attributes, making this option noncompliant regardless of technical feasibility.

Compute Engine custom metadata is commonly used for configuration and bootstrapping, but it is not a secrets manager. Metadata is accessible to processes on the VM and can be exfiltrated if the instance is compromised; it also lacks strong secret lifecycle controls like versioning and rotation management. The policy explicitly forbids storing secrets in instance metadata, so this option is disallowed.

Incorrect. TCP/25 is not universally blocked by implied VPC firewall rules. Any SMTP limitations are typically due to anti-abuse measures, organization policy constraints, or external provider controls, not the baseline implied firewall behavior. From a pure VPC firewall perspective, egress is allowed by default, so you cannot claim TCP/25 is implicitly blocked regardless of user rules.

Incorrect. This describes a default-deny egress posture, which is not how GCP VPC works out of the box. By default, egress is allowed via an implied rule. You can implement default-deny egress by creating higher-priority egress deny rules and then adding explicit egress allow rules for required destinations/ports, but that is not the implied baseline.

Incorrect. There is no implied allow for inbound HTTP (tcp/80). Inbound traffic is denied by default unless explicitly allowed. HTTP access would require an ingress firewall rule (e.g., allow tcp:80 from 0.0.0.0/0 or a restricted CIDR) and, in many architectures, would typically be fronted by an external HTTP(S) load balancer with appropriate firewall rules for health checks and proxy ranges.

Incorrect. Sole-tenant nodes address workload isolation and certain compliance requirements, not image drift or patch automation. Policy Controller (Anthos) is primarily for Kubernetes admission control and configuration policy; it is not the right mechanism to restrict Compute Engine VM image sources or enforce OS patching on VMs. This option doesn’t meet the 48-hour patch requirement or VM lifecycle enforcement.

Incorrect. A Cloud Build pipeline for baking hardened images is useful for standardization, but Artifact Registry is for container and language artifacts, not Compute Engine VM images (which live in Compute Engine image resources). More importantly, image baking alone doesn’t ensure existing VMs receive critical patches within 48 hours or that baseline controls remain enforced throughout the VM lifecycle without an additional enforcement tool like OS Config.

Incorrect. Security Command Center Enterprise improves visibility (asset discovery, posture findings, vulnerability insights) and can integrate with response tooling, but it is not the primary service to enforce OS patching or continuously apply configuration state on Compute Engine VMs. SCC is largely detect/monitor; you would still need OS Config (or equivalent) to meet the explicit 48-hour patch and ongoing enforcement requirements.

Routing all logs to BigQuery copies data into another analytics store and usually increases exposure surface (dataset access, query results, extracts). Even if the SIEM filters in BigQuery, you still granted access to a broader dataset unless you build additional controls (authorized views, row-level security). It also adds cost (streaming ingestion/storage/query) and is not the most direct way to provide least-privilege read access to recent logs.

A Pub/Sub sink plus Dataflow forwarding is an export pipeline that pushes logs toward the on-prem SIEM, which contradicts the requirement to avoid copying all logs to external systems and to minimize data exposure. It also introduces operational complexity (pipeline reliability, scaling, backpressure, DLQs) and additional cost. While it can filter logs, it is not the least-exposure approach compared to a Logging view.

Providing a JSON service account key violates the explicit requirement to avoid long-lived keys. It also increases risk of credential leakage and key management burden (rotation, revocation, audit). Storing logs in Cloud Storage is another form of copying/exporting away from Cloud Logging’s native controls, and fine-grained, time-bounded access is harder to enforce compared to Logging retention and views.

Incorrect. An external SSL proxy load balancer is not the required entry point for Cloud Armor WAF protections aimed at HTTP attacks such as XSS and SQL injection. Those protections depend on HTTP(S)-aware request inspection, which is provided by external HTTP(S) load balancing rather than generic SSL proxying. The question specifically describes a web front end and WAF behavior, which maps to external HTTP(S) load balancers, not SSL Proxy.

Incorrect. This option describes a rule-matching characteristic rather than an infrastructure prerequisite that must exist for policy enforcement. Cloud Armor does evaluate Layer 7 request attributes for HTTP(S) traffic, but knowing that does not establish the required deployment architecture. Also, Cloud Armor can match on more than just URI and headers, so the statement is not a precise prerequisite and is partly misleading.

Incorrect. Premium Network Service Tier is commonly used with global external HTTP(S) load balancing, but it is not the prerequisite the question is testing for Cloud Armor policy evaluation. The essential requirements are the supported external HTTP(S) load-balancer entry point and an eligible external backend service where the policy is attached. Treating Premium Tier itself as one of the two required prerequisites overstates its role and makes this option less accurate than D.

Cloud NAT enables outbound (egress) internet access for private resources without external IPs. It does not authenticate end users, perform OAuth sign-in, or enforce group-based authorization for inbound access to web applications. Cloud NAT is a network translation service, not an application access control layer, and it would not meet requirements for per-user access policies or detailed user access auditing for dashboards.

Google Cloud Armor is a WAF and DDoS protection service for HTTP(S) Load Balancers. It can enforce IP allow/deny lists, geo restrictions, rate limiting, and preconfigured WAF rules, but it does not provide per-user authentication via OAuth 2.0 or group-based access tied to Google Workspace identities. It may complement IAP for threat protection, but it cannot replace IAP for identity-aware access control.

Shielded VMs protect VM instances against boot-level and rootkit-style attacks using secure boot, vTPM, and integrity monitoring. This improves host security posture for Compute Engine workloads, but it does not provide centralized user authentication, OAuth sign-in, or authorization for web dashboards. It also does not address the requirement for identity-based access control and user-level audit logging for application access.

Cloud Run is a serverless compute platform and is unrelated to VPC Service Controls operating modes. While Cloud Run services can be placed behind VPC controls indirectly (for example, accessing protected services), it does not provide a “mode” for VPC SC evaluation or enforcement. Selecting Cloud Run confuses an application runtime product with a security boundary control feature.

“Native” is not a VPC Service Controls mode used to evaluate or enforce perimeters. VPC SC perimeters are configured and then applied either in enforced behavior or in dry-run evaluation. If you see terms like “native,” they typically relate to other product contexts (for example, native integrations) and not to the operational modes required for safe perimeter testing.

Enforced mode actively blocks requests that violate the service perimeter rules. This is appropriate when you are ready to prevent data exfiltration and can tolerate/expect access denials for non-compliant paths. In this scenario, the requirement explicitly says to avoid interrupting any existing access paths during a 14-day evaluation, so enforced mode would be too risky and would likely cause outages.

Writing logs directly to Cloud Storage can meet retention and regionality if the bucket is in asia-southeast1 and has a retention policy. However, it requires application changes, loses Cloud Logging’s native querying/alerting, and is higher operational overhead. It also risks missing platform/system logs that Cloud Run sends to Cloud Logging. This is not the most Google-managed, low-overhead approach for Cloud Run logging compliance.

Cloud Run does not support installing traditional logging agents like on VMs, and sidecars add complexity and operational burden (build, deploy, patch, resource sizing). Also, you don’t need an agent to get logs into Cloud Logging—Cloud Run already streams stdout/stderr to Cloud Logging. The correct pattern is configuring Cloud Logging buckets and Log Router, not adding custom log shipping components.

Exporting logs via Pub/Sub to Cloud Storage introduces an extra pipeline (sink to Pub/Sub, subscriber, delivery guarantees, backpressure handling) and increases operational overhead. It can be costlier and more failure-prone at 40 GB/day. While you can keep the Storage bucket regional and set lifecycle/retention, this is not the simplest Google-managed solution compared to routing directly into a regional Cloud Logging bucket.