GCP Professional Cloud Security Engineer Practice Test

Both Cloud IDS logs and VPC Flow Logs are ingested into Cloud Logging. By creating an organization-level aggregated sink that routes all relevant log entries to a centralized log bucket, you guarantee a single storage location across projects. Upgrading that bucket to Log Analytics activates the built-in BigQuery execution engine, letting analysts run standard SQL directly against the logs without exporting them. The bucket's retention can be configured to any value between 1 and 3650 days, so setting it to roughly 550 days satisfies the 18-month archive requirement. Granting read-only Logging roles on the bucket enforces least-privilege access. The other options either require managing external BigQuery datasets, additional ETL pipelines, or use products (Chronicle, Cloud Trace) that do not natively satisfy the stated constraints.

Turning on DNSSEC for the Cloud DNS public zone instructs Cloud DNS to sign each resource-record set with RRSIG records that validating resolvers can check against the zone's DNSKEY records, protecting against spoofing and cache poisoning. When DNSSEC is enabled, Cloud DNS automatically creates and can automatically rotate the Zone-Signing Keys (ZSKs). You must still create (and periodically rotate) the Key-Signing Key (KSK) manually and publish the associated Delegation Signer (DS) record at your domain registrar to complete the chain of trust. Solutions based solely on encrypted transport (DoT/DoH), logging, or caching do not provide the cryptographic data-integrity guarantees required. Therefore, enabling DNSSEC with Cloud-managed ZSKs and manually publishing the DS record provides strong authenticity with minimal ongoing effort.

BigQuery column-level security relies on Data Catalog policy tags. By creating a taxonomy, tagging the SSN and Salary columns, and granting the hr-analysts group the Data Catalog fine-grained reader role (roles/datacatalog.categoryFineGrainedReader) on those tags, only that group can read the tagged columns. Everyone else retains their existing table access but receives NULLs for the restricted columns. Authorized views, row-level security, or CMEK key permissions do not provide transparent, policy-based column masking for this scenario.

The Vertex AI User role lets a principal create and run training pipelines and register Model resources, but it does not grant permissions to deploy models, update Endpoints, or set IAM policies. This satisfies the data-science requirements. The Vertex AI Deployment Resource Admin role is limited to managing online serving resources (Endpoints and deployed models) and does not allow changes to Datasets or training resources, meeting the MLOps needs. Granting broader roles such as Editor or Vertex AI Admin would violate the least-privilege objective, while Viewer would prevent the data-science team from running experiments.

GCDS is designed for one-way synchronization: it reads objects from an LDAP directory such as Active Directory and creates, updates, or suspends matching objects in Google Cloud or Google Workspace. It never writes data back to the LDAP source, regardless of configuration. Therefore, any modification made directly in Google Workspace-such as changing a phone number-remains only in Google Workspace; the value in Active Directory is unchanged. Statements suggesting bidirectional sync, group-only write-back, or the need for additional APIs to enable LDAP updates are incorrect because GCDS has no capability to modify the source directory.

Cloud DNS automatically publishes DNSKEY and RRSIG records after you enable DNSSEC, but the chain of trust is not complete until the parent zone (.com) advertises that the child zone is signed. You do this by adding the DS (Delegation Signer) record that Cloud DNS generates to the domain's registrar. Without that DS record, validating resolvers have no way to verify signatures, so the zone remains insecure. Manually creating DNSKEY/RRSIG records is unnecessary because Cloud DNS manages them. Client-side resolvers do not need special configuration beyond normal DNSSEC validation, and Cloud DNS does not support importing an external Cloud KMS key as a KSK.

After you create a hybrid inspection job, you must push data from the external system to the job by calling the projects.dlpJobs.hybridInspect (or projects.jobTriggers.hybridInspect) method. Each call is made to a URL that contains the DLP job's resource name (for example, projects/my-proj/dlpJobs/123456) and includes a HybridContentItem with the data and required metadata. The DLP service does not automatically pull data, does not require Cloud Storage staging, and still allows custom infoTypes. Pub/Sub can be used for notifications but is not required to start the inspection.

Private Service Connect lets a service producer publish a service attachment behind an internal load balancer. Each consumer project creates its own PSC endpoint, allocates a regional internal IP, and privately reaches the service over Google's backbone-no public IPs or peering required. Because consumer traffic appears as ordinary egress, the producer avoids per-consumer route or firewall updates. Peering, Cloud VPN, or an external load balancer would violate the overlapping-CIDR or private-backbone constraints.

Creating two separate aggregated organization-level log sinks with identical filters meets all objectives. The first sink streams matching log entries in near real time to a Pub/Sub topic located in a dedicated "ir-partner" project; granting the Mandiant-supplied service account the Pub/Sub Subscriber IAM role lets them pull or stream only those entries, honoring least-privilege. The second sink exports the same filtered logs to a Cloud Storage bucket that has both object versioning enabled and a locked retention policy, ensuring that no log object can be altered or deleted during the retention period, thus providing an immutable archive. Alternatives either expose excessive log access (project-level Logging Viewer), introduce unacceptable latency (BigQuery export), or fail to preserve raw logs immutably (dashboard access only).

VPC firewall rules filter traffic that leaves or enters a VM's virtual NIC. They cannot block the link-local metadata address (169.254.169.254), which is reached over the NIC's loopback path and therefore never evaluated by VPC firewalls. The practical control point is egress to external networks: prevent any destination except the Private Google Access IP range that the workload legitimately needs. Creating a very high-priority egress rule that allows traffic to 199.36.153.8/30 for the affected VM, followed by another high-priority rule that denies all remaining egress (0.0.0.0/0), stops the stolen token from leaving the VM while keeping calls to Google APIs functional. The other options either target traffic paths the firewall cannot control (metadata server), address inbound rather than outbound flows, or require additional services instead of the requested firewall-only fix.

Admin Activity audit logs are written automatically for all Google Cloud services and record configuration-changing API calls such as the creation, update, or deletion of Cloud SQL instances. These logs are always on and their ingestion does not generate charges. By creating an organization-level log sink that filters for the Cloud SQL Admin Activity log entries, the events can be forwarded to the central log bucket without turning on any additional, billable log types. Enabling Data Access logs, Asset Inventory feeds, or maintenance events would either incur extra logging fees or fail to capture every configuration-changing API call.

A recurring Sensitive Data Protection (formerly Cloud DLP) inspection job can automatically detect built-in infoTypes such as PERSON_NAME and US_SOCIAL_SECURITY_NUMBER in the landing tables. By attaching a de-identification template that uses tokenization or format-preserving encryption, the job can write the transformed results into a separate de-identified BigQuery table that maintains referential integrity for analytics but removes direct identifiers from the researchers' view. Because the job is scheduled, new nightly ingests are handled automatically. Simply granting Data Viewer on the raw tables violates HIPAA, exporting to Cloud Storage for custom scrubbing adds unnecessary complexity and operational overhead, and Data Catalog policy tags hide entire columns rather than transform their values-preventing researchers from performing joins that rely on the identifiers. Therefore, the automated SDP inspection and de-identification workflow is the best fit.

In a Software-as-a-Service offering such as Google Workspace, Google is responsible for operating, securing, and patching the service stack (data centers, network, and the Workspace application code). The customer, however, retains control over how the service is used - for example, setting sharing permissions, retention rules, and other policy configurations that govern its own data and users. The other options invert or misallocate duties: Google does not manage a customer's IAM groups, supply customer-managed keys by default, or define the customer's DLP rules, and customers do not patch Google servers or guarantee Workspace availability.

Creating the Cloud SQL instance with only a Private IP address (and removing/disabling any Public IP) forces all traffic to stay within the VPC. Private-IP instances are reachable from resources in the same VPC and from on-prem environments that are connected by Cloud VPN or Cloud Interconnect, but they expose no routable address on the public internet. Relying on authorized networks or the Cloud SQL Auth proxy while keeping a public IP still permits internet-routable connectivity and therefore fails the mandate. Placing an internal load balancer in front of Cloud SQL is not supported, and a bastion host introduces additional maintenance without eliminating the public endpoint.

Creating an Assured Workloads environment with the EU (PCI DSS) compliance regime imposes EU-based personnel controls. Adding the gcp.resourceLocations organization policy restricts resource creation strictly to europe-west3, ensuring data residency in Frankfurt. Enabling Access Approval forces just-in-time, time-bounded permission before any Google staff action and pairs with Access Transparency for auditing. Wrapping the PCI projects in a VPC Service Controls perimeter blocks API-level data exfiltration to other projects without maintaining individual firewall rules. The remaining options each miss at least one mandatory control: multi-region storage does not confine data to Frankfurt, Identity-Aware Proxy addresses customer but not provider access, and storing keys in us-central1 violates the data-residency mandate.

The key ring and symmetric CryptoKey must reside in the same region (europe-west1) as the BigQuery dataset. Create an import job whose protection level matches the target CryptoKey version (SOFTWARE or HSM). Download the import job's public wrapping key and wrap the 256-bit AES key offline with a supported algorithm such as AES-KWP (RFC 5649) or RSA_OAEP_3072_SHA1_AES_256. Finally, use gcloud kms keys versions import (or the equivalent API method) to upload the wrapped key material. This process keeps the key encrypted during transit and complies with Cloud KMS BYOK requirements. Directly pasting raw Base64 bytes, copying key material without wrapping, or using Cloud EKM (which links to but does not import the key) do not meet the import workflow requirements.

The primary danger comes from server-side request forgery (SSRF) or remote-code-execution flaws in software running inside the VM. If attacker-supplied input can make the application issue HTTP requests, the attacker can direct the code to query the metadata server. The legacy endpoints reply without requiring the protective header (Metadata-Flavor: Google), so an attacker can retrieve the VM's OAuth access token for its attached service account and use that token to access other Google Cloud resources. Inbound firewall rules do not mitigate this because the metadata server is reached over the VM's loopback interface. The other options describe issues that are either incorrect (user-level SSH keys are not stored on disk in plaintext), already mitigated by the firewall, or unrelated to the metadata server (disk-encryption key rotation).

Google recommends having at least one "break-glass" or emergency Super Administrator account that does not depend on the external IdP. Creating one or two native (non-federated) Super Administrator accounts whose strong, randomly generated passwords and hardware-based 2-Step Verification factors are stored securely offline ensures administrative access even if the IdP is unavailable. Regular Super Administrators continue to authenticate with SSO, protected by hardware security keys. Granting a service account Super Administrator privileges and sharing a JSON key is risky because keys are long-lived, hard to revoke, and violate least-privilege principles. Disabling SSO for everyone weakens security and does not meet the "minimize risk" requirement. IAM Deny policies cannot guarantee access during IdP outages and cannot override authentication failures, so they do not address the stated problem.

A single VPC Service Controls service perimeter around the production and analytics projects blocks all BigQuery and Cloud Storage calls that attempt to reach projects or services outside the perimeter, mitigating data-exfiltration risk even if credentials are stolen. Because service perimeters deny egress by default, PHI cannot be exported. An ingress policy can be added that references an access level matching the partner's static IP range, permitting just-in-time BigQuery ingestion traffic from that network into the analytics project. Private Service Connect, firewall rules, and Shared VPC egress rules do not enforce data movement controls on Google-managed APIs; IAM and org policy hardening alone cannot stop programmatic exports once a principal has data-access permissions.

A lower priority number means the rule is evaluated first. By creating an egress allow rule with a priority of 50 that targets only instances tagged updater, those VMs are matched and traffic is permitted. The subsequent rule with priority 100 denies egress to 0.0.0.0/0 for every instance, so all traffic from non-tagged VMs is blocked. NAT does not bypass firewall rules, and an ingress rule would not control outbound connections, so the other options fail to meet the requirement.