Hard Difficulty Questions

Create a Cloud External Key Manager (EKM) key and configure BigQuery to use it. The EKM provider handles key rotation.

Why wrong: EKM is for keys managed externally; the company wants CMEK, not EKM.

Create a Cloud KMS key ring with a key, disable automatic rotation, and use Cloud Functions to rotate the key manually every 90 days. Enable Admin Activity audit logs for Cloud KMS.

Why wrong: Disabling automatic rotation and using Cloud Functions to manually rotate the key every 90 days fails the requirement because manual rotation does not guarantee enforcement of the 90-day rotation schedule—a missed function execution would leave the key unrotated, whereas BigQuery CMEK requires a reliable, auditable rotation mechanism. This option is tempting because Cloud KMS supports manual key rotation via API calls, and Admin Activity audit logs do capture key management events, making it appear sufficient for compliance; it would be correct in a scenario where the organisation accepted operational risk and did not need an enforced, automated rotation policy.

Create a Cloud KMS key ring with a key using a protection level of HSM and set a rotation period of 90 days. Then configure the BigQuery dataset to use this key.

Why wrong: HSM protection level is optional; software keys are sufficient unless compliance requires HSM. Also, key usage audit logs are not automatically enabled for CMEK.

Use automatic rotation and disable previous key versions after 30 days.

Why wrong: Disabling previous versions would make old data undecryptable.

Use manual rotation and delete old key versions after confirmation that all data has been re-encrypted.

Why wrong: Manual re-encryption is required, which contradicts the requirement of no manual re-encryption.

Use symmetric key with purpose SYMMETRIC_ENCRYPT_DECRYPT and set rotation period to 0 (never).

Why wrong: No rotation does not meet the key rotation requirement.

Do not use VPC Service Controls; instead, rely on IAM permissions and firewall rules to control access

Why wrong: IAM and firewalls do not prevent data exfiltration to external IPs outside the perimeter.

Create a separate perimeter that denies all traffic and apply it to the project

Why wrong: This would deny all access, including from VPN.

Add the project to a VPC Service Controls perimeter with no additional ingress rules

Why wrong: This would block access from on-premises via VPN because VPN traffic originates outside the perimeter.

Configure Cloud Armor to allow only traffic from the IP ranges used by IAP

Why wrong: IAP does not use specific IP ranges; it works at the application layer.

Create a Cloud Armor security policy that requires a valid JWT token signed by IAP

Why wrong: IAP itself validates the token; Cloud Armor does not need to do this.

Set a firewall rule on the backend instances to allow traffic only from the load balancer's health check IPs

Why wrong: This is for network-level access, not user authentication.

Use IAM roles only and enable Cloud Audit Logs, but keep ACLs enabled.

Why wrong: ACLs can override IAM permissions.

Use VPC Service Controls and enable Cloud Audit Logs.

Why wrong: VPC Service Controls control network access, not bucket-level access.

Enable fine-grained access using ACLs and enable Cloud Audit Logs.

Why wrong: ACLs can allow public access unintentionally and are harder to audit.

Configure an organization policy to deny key creation if keys are older than 90 days.

Why wrong: Organization policies cannot enforce rotation or detect key age.

Use Cloud Logging to analyze logs for key creation and compute age.

Why wrong: Logs show creation events but not current key age; would require complex logic.

Create a custom IAM role that prevents using keys older than 90 days.

Why wrong: IAM roles cannot enforce key age restrictions.

The container image is stored in a different registry that is not supported by Binary Authorization.

Why wrong: Artifact Registry is supported by Binary Authorization.

The GKE cluster's node service account does not have permission to verify attestations.

Why wrong: The node service account does not need to verify attestations; the Binary Authorization admission controller handles verification.

The Binary Authorization policy requires an attestation from a different attestor that is not configured.

Why wrong: The error indicates no signature at all, not a missing specific attestor.

The organization policy restricts cross-project access.

Why wrong: Organization policies would affect all projects, not just cross-project.

The service account does not have permission to create Dataflow jobs in Project B because it is not a member of Project B.

Why wrong: Organization-level roles grant access across all projects, so membership isn't the issue.

The Dataflow API is not enabled in Project B.

Why wrong: If the API were disabled, the error would be different.

A log sink to export logs to BigQuery

Why wrong: Optional, not required for enabling flow logs.

A metadata server to store logs

Why wrong: Logs are stored in Cloud Logging, not metadata server.

Migrate the function to Cloud Run with a longer timeout

Why wrong: Cloud Run also has a timeout (default 300s, max 3600s) but migration is more effort; the function can be fixed in Cloud Functions.

Change the Cloud Functions runtime from Node.js to Python

Why wrong: Runtime change does not guarantee faster execution; the issue is the 60-second timeout.

Increase the allocated memory for the function

Why wrong: More memory may speed up execution but does not extend the 60-second timeout limit.

Import key material from on-premises HSMs to avoid vendor lock-in.

Why wrong: Importing keys lowers security; generating in Cloud HSM is safer.

Automatically delete old key versions once they expire.

Why wrong: Old keys may be needed for decryption; soft deletion or scheduled deletion is recommended.

Create an IAM deny policy at the organization level that denies the compute.instances.create permission unless the Shielded VM flag is set.

Why wrong: IAM deny policies cannot conditionally deny creation based on instance configuration; they deny specific permissions unconditionally or based on attributes like resource name, not VM settings.

Create a custom role that includes the permission to create instances only with Shielded VM, and assign it to all users.

Why wrong: Custom roles cannot enforce that Shielded VM must be enabled; they only grant permissions. Users with other roles could still create non-compliant instances.

Implement a service account that only has permission to create instances and use service account impersonation for all instance creation.

Why wrong: Service account impersonation does not enforce Shielded VM requirements. It only controls who can act as a service account.

Yes, because she has the client role with no condition.

Why wrong: While the client role is unconditional, the statement is incomplete as it doesn't explain why the admin condition doesn't override.

No, because the admin role condition overrides the client role.

Why wrong: Roles are additive; conditions on one role do not restrict other unconditional roles.

No, because the cloudsql.admin role condition restricts to dev instances only.

Why wrong: The client role is separate and not affected by the condition on the admin role.

Clone the instance to a new VM.

Why wrong: Cloning may alter the source instance or require downtime.

Export the disk image to Cloud Storage.

Why wrong: Exporting a disk image to Cloud Storage creates a static copy, but this action still requires the instance to be stopped or the disk to be detached, which alters the live environment and risks losing volatile evidence such as running processes or memory contents. This step is tempting because it is a standard forensic preservation technique for persistent data, and would be correct if the goal were solely to archive the disk contents for offline analysis after the live environment had already been secured.

Enable VPC Flow Logs for the instance's network.

Why wrong: Flow logs are for network analysis, not disk evidence preservation.

Use Private Google Access to restrict egress.

Why wrong: Private Google Access is for access to Google APIs, not general egress.

Use VPC Service Controls to restrict egress.

Why wrong: VPC Service Controls prevent data exfiltration to Google services, not external IPs.

Create a firewall rule in the service project's VPC that denies egress.

Why wrong: Service projects do not have their own VPC in Shared VPC; they use the host's VPC.

Create a view that applies masking functions and grant access to the view.

Why wrong: Views can mask data but do not natively enforce role-based masking; every user sees the same view.

Use Cloud DLP to scan and de-identify the data in place.

Why wrong: DLP de-identification is a one-time transformation, not dynamic masking per user.

Create separate tables for each role and populate them with appropriate data.

Why wrong: This leads to data duplication and maintenance overhead.

Set up Cloud VPN and use Private Google Access on the VPC.

Why wrong: Cloud VPN is not a dedicated private connection; it uses the public internet.

Apply VPC Service Controls and enable Private Google Access on the subnet.

Why wrong: VPC Service Controls do not route traffic; Private Google Access on subnet only covers VMs in that subnet.

Configure Cloud NAT on the VPC and on-premises route via the interconnect.

Why wrong: Cloud NAT is for internet access, not for private Google access; it would route through public IPs.

Use dd to copy the disk over SSH to a forensic workstation.

Why wrong: This can alter the disk state and is not the recommended practice for GCP forensic snapshots.

Stop the instance, create a snapshot of the disk, then detach the disk.

Why wrong: Stopping the instance may alter the disk state (e.g., cache flush). Snapshot before stopping is better.

Detach the disk first, then create a snapshot of the detached disk.

Why wrong: Detaching may cause the VM to crash or lose data; also the disk state at detachment might not reflect the compromise.

Manually rotate the key every 30 days using a Cloud Function

Why wrong: Manual rotation via a Cloud Function introduces human latency and potential for missed rotations, failing the requirement for automatic 30-day rotation. This approach is tempting because Cloud Functions can automate arbitrary tasks, and in scenarios where key rotation must be triggered by external events or custom business logic rather than a scheduled policy, a function-based solution would be correct. However, Cloud KMS’s built-in rotation policy directly enforces the schedule without operational overhead.

Configure the key's `next_rotation_time` to start rotation immediately

Why wrong: Setting rotation period already schedules rotation; next_rotation_time is not needed.

Push the image to Artifact Registry and allow the Binary Authorization policy to automatically sign it.

Why wrong: Binary Authorization does not automatically sign images; signing must be done separately.

Configure the cluster to allow all images by setting the policy to 'Allow All' for the developer's namespace.

Why wrong: This bypasses the attestation requirement, which is not the intended solution.

Use the Binary Authorization API to create an attestation by specifying the image URL and the attestor, then deploy.

Why wrong: An attestation must be cryptographically signed using the attestor's key; simply creating an API object without signing will not satisfy the policy.