Practice Test #1

Cloud External Key Manager (EKM) integrates Google Cloud services with keys stored in an external key management system (often on-prem or third-party HSM). While it can provide strong customer control and separation from Google, it violates the requirement of “no dependency on external key stores” and “keys must reside in Google Cloud KMS/HSM.” Therefore it is not suitable for this scenario.

Customer-supplied encryption keys (CSEK) require you to provide raw key material to Google Cloud services at request time. This increases operational complexity, complicates rotation, and is not uniformly supported across all the listed services (notably many managed services like BigQuery and Pub/Sub rely on CMEK rather than CSEK). It also does not meet the requirement that keys must reside in Cloud KMS/HSM.

Google default encryption uses Google-managed keys and provides encryption at rest automatically, but you do not control key creation, rotation cadence, or IAM-scoped key usage. This fails the explicit requirement that the customer—not Google—must control key lifecycle and access. It also does not satisfy compliance-driven “customer control” expectations common in regulated environments.

Incorrect. While managed services reduce your operational burden, they do not eliminate your security responsibilities. Rate limits and budget alerts are cost/availability controls, not the core security posture for partner uploads and managed batch inference. You still must manage IAM, data access boundaries, and monitoring. This option misrepresents the shared responsibility model by implying most security shifts entirely to Google.

Incorrect. Securing CSV normalization code is important (input validation, safe parsing), but the question asks to describe security responsibilities for the managed workflow end-to-end. Limiting IAM discussion to “within the development team” ignores the biggest risks here: external partner access, service account permissions between Cloud Functions/Vertex AI/Cloud Storage, and auditability. It’s too narrow for a configuration review.

Incorrect. You generally cannot place custom network firewalls or deep IDS/IPS “around” Vertex AI’s managed service control plane in the way you would for self-managed VMs. The more appropriate controls are IAM, organization policies, VPC Service Controls, private access patterns, and logging/monitoring. Vulnerability scanning of a Google-managed runtime is also largely Google’s responsibility, not yours.

Cloud Functions on IAM policy changes is partial and brittle: it focuses on IAM changes only, not comprehensive user activity, Data Access, or service account key usage across services. It also depends on building/maintaining custom detection logic and storage, and it doesn’t inherently provide centralized, near-real-time export and 400-day retention for all relevant audit events. Policy Simulator is for analysis, not an audit log system.

Cloud Monitoring Metrics Explorer can alert on certain authentication/usage metrics, but metrics are not a complete, immutable audit trail of administrative actions and data reads/writes. It won’t reliably capture IAM policy deltas, detailed API caller identity, or service account key creation/usage events with the fidelity needed for compliance and forensics, nor is it designed for SIEM-grade cross-environment log correlation and long-term retention.

OS Config requires agents on VMs, which violates the “no agents” constraint. Even if allowed, patch and configuration monitoring does not provide authoritative visibility into IAM policy changes, API-level user activity, or service account key usage across managed services. It’s a systems management tool, not a centralized cloud audit and compliance logging solution, and it won’t address cross-environment SIEM correlation requirements.

Security Reviewer is a read-only role intended for visibility into security posture, configurations, and findings. It can help a team inspect resources and support audits, but it does not allow them to change IAM policies or control who can grant permissions. Because the requirement explicitly calls for assuming control of permission-granting authority, a reviewer role is insufficient. It addresses observation, not administration.

Organization Role Administrator manages custom IAM roles at the organization level, such as creating, updating, or deleting custom role definitions. However, defining roles is different from granting permissions to principals through IAM policy bindings on organizations, folders, and projects. This role does not by itself provide the broad authority needed to control who can assign access across the hierarchy. Therefore it is too narrow for the stated requirement.

Organization Policy Administrator manages organization policy constraints, such as restricting resource locations or allowed services. These policies are useful for governance and compliance, but they do not directly control IAM permission grants or who can bind roles to users and service accounts. The question is specifically about controlling access delegation, which is an IAM administration function rather than an organization policy function. As a result, this role does not meet the core requirement.

CSEK requires you to provide the raw encryption key material with each API request that creates or attaches the disk. In a bursty autoscaling MIG (8 to 200 VMs in minutes), securely distributing and injecting keys at scale is operationally complex and error-prone, and it reduces agility. Auditability is also less centralized than Cloud KMS. While you “control” the key, it is not the best fit for rapid automated instance creation.

Google-managed encryption keys (default encryption) provide minimal operational overhead and good baseline security, but they do not meet the requirement to retain full control of the key lifecycle. You cannot perform your own quarterly rotation policy, immediate disablement during incidents, or get the same level of customer-controlled governance over key usage decisions. This option fails the explicit security requirements.

Pre-encrypting files before upload can protect data at rest for application-level inputs/outputs, but it does not satisfy boot disk encryption key lifecycle control for Compute Engine instances. The requirement is specifically about boot disk encryption keys and the ability to rotate/disable/audit them. This approach also adds complexity to the pipeline and does not provide a centralized “kill switch” for VM boot disk access.