Google Professional Cloud Security Engineer

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. An Access Context Manager access level can restrict access to Google Cloud resources, but blocking super administrators from signing in defeats the purpose of break-glass accounts. In an emergency (identity recovery, org-level misconfiguration), you must be able to authenticate as super admin. Best practice is to tightly control and monitor super admin use, not prevent it entirely.

Incorrect. Removing IAM role bindings at the organization root may reduce Google Cloud resource permissions, but it does not remove Cloud Identity/Google Workspace super administrator privileges, which exist outside Cloud IAM. Also, super admins may need certain permissions during initial setup and recovery. The better pattern is separate day-to-day accounts with least privilege plus hardened super admins for emergencies.

Incorrect. While private network paths can reduce some exposure, Google sign-in is designed to be secure over the public Internet using TLS, and the scenario explicitly states there is no VPN/Interconnect and setup must be completed within 24 hours. Requiring private connectivity is not a realistic or necessary prerequisite for securely creating/administering super admin accounts.

Incorrect. Using Cloud KMS to manage a DEK is not how Google Cloud storage encryption is typically implemented; KMS keys are used as KEKs to wrap DEKs (envelope encryption). More importantly, Cloud KMS stores key material in Google-managed HSM infrastructure, which violates the requirement that Google Cloud must not store the key and that the on-prem HSM-generated key be used directly.

Incorrect. Cloud KMS managing a KEK describes CMEK: Google stores the KEK in Cloud KMS and uses it to wrap per-resource DEKs. This can satisfy many compliance needs, but it does not meet the strict requirement that the key is generated in an on-prem HSM and that Google Cloud does not store the key. With CMEK, loss of access can block decryption, but the key still resides in Google Cloud.

Incorrect. CSEK is not used to manage a KEK in the Cloud KMS sense; rather, the customer-supplied key is used to wrap the resource’s DEK. Choosing “KEK” here reflects a misunderstanding of Google’s envelope encryption terminology. The correct framing is that CSEK is applied to the DEK for the disk, not that you are managing a KEK service-side.

An org-level hierarchical firewall deny from 0.0.0.0/0 is centralized and preventative, but it is overly broad. It would block all internet ingress to every workload, including legitimate public-facing services (for example, web apps on 443) and could cause widespread outages. The question targets stopping common exposure misconfigurations (like open Redis), not eliminating all public ingress everywhere.

Cloud Armor is a WAF/DDoS policy attached to external HTTP(S) Load Balancers (and some proxy-based LBs). It does not protect arbitrary TCP ports on VM external IPs, such as direct Redis on 6379. Since the finding is about VMs reachable from the internet, the correct control plane is VPC/hierarchical firewalling, not Cloud Armor.

Adding a priority-0 deny rule in every VPC network could block internet ingress, but it violates the requirement to avoid per-project/per-network maintenance. With ~90 VPCs and 2,300 projects (and future growth), this approach is operationally brittle and easy to drift. Centralized hierarchical firewall policies are designed specifically to enforce consistent baselines across the organization.

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).

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.

Granting users the Service Account User role allows those users to impersonate or actAs the service account for Google Cloud IAM purposes. It does not provide access to Google Drive user data via the Drive API, nor does it eliminate the need for Workspace OAuth authorization. It also scales poorly and increases risk by allowing many users to impersonate the service account.

Using a Google Group to grant Service Account User is an IAM convenience improvement over option A, but it still addresses the wrong control plane. IAM actAs permissions do not grant Workspace Drive access to employee files. The requirement is server-to-server access to Workspace user data without interactive consent, which requires domain-wide delegation and authorized OAuth scopes.

Authenticating with a super admin account is explicitly discouraged. It violates least privilege, creates a high-impact credential that can access far more than Drive read-only, and is difficult to manage securely (rotation, storage, auditing). It also does not follow Google’s recommended server-to-server approach for accessing Workspace user data at scale.

Domain contestation is designed for situations where domain ownership is disputed or an unauthorized party controls the domain in a tenant. Here, the domain is already used internally with 850 accounts and SAML SSO, so contestation would be highly disruptive and unnecessary. It risks account conflicts, service interruption, and complex migration. It does not align with the “least disruption” requirement and is not the right tool for internal segmentation.

Using a new domain (analytics-example.com) could technically enable a separate Cloud Identity tenant, but it violates the spirit of “all identities remain company-owned” under the primary corporate domain and creates identity fragmentation. Users would need alternate usernames or aliases, complicating lifecycle management, group membership, and access governance. It also increases operational overhead and can introduce inconsistent SSO and policy enforcement across tenants.

Granting Super Admin to a marketing program manager is excessive and violates least privilege. Super Admin has broad control over identity, security settings, and domain-wide configurations, creating significant risk. The requirement is to onboard a unit with minimal disruption and maintain policy, not to delegate top-level tenant control. Proper onboarding should be done by existing admins with scoped admin roles and group/OU-based controls.

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.

Secure Web Proxy is designed primarily as a managed forward proxy for controlling and inspecting outbound (egress) web traffic from clients to the internet/SaaS, with URL filtering and threat protection. It is not the right construct for inbound TLS traffic coming from on-prem over HA VPN to an internal load balancer. It also doesn’t meet the “centrally enforced for all projects in a folder” requirement in the same way as hierarchical firewall policies.

An internal proxy load balancer can terminate TLS, but load balancers are not positioned as malware/C2 inspection engines for decrypted payload inspection. Terminating TLS at the ILB changes where encryption ends, but it does not inherently provide the mandated security inspection capabilities. Additionally, it does not provide centralized, folder-level enforcement across multiple projects; it would be configured per service/load balancer.

VPC firewall rules are scoped to a specific VPC network/project and are not centrally enforced across all projects in a folder unless you replicate them everywhere, which violates the “centrally enforced” mandate and increases drift risk. Also, standard VPC firewall rules do not provide TLS decryption/inspection; they are L3/L4 allow/deny controls. Even with NGFW features, the governance requirement points to hierarchical firewall policies, not per-VPC rules.

Security Foundations/landing zone blueprints are useful starting points (org structure, IAM patterns, logging, networking), but implementing them “verbatim” is rarely correct for exams. They require customization for your specific VPC topology, regions, GDPR controls, and log-retention requirements. Also, a blueprint does not “continuously maintain” posture by itself; you still need governance, monitoring, and ongoing operations to keep controls effective.

Risk Manager/cyber insurance (and similar risk-transfer mechanisms) may be part of an overall risk strategy, but they do not answer the core requirement: deciding where to apply controls and clarifying which responsibilities belong to Google vs your team. A posture report can be informative, yet it is not the foundational step for control ownership mapping, GDPR accountability, or audit-log retention design.

Tracking release notes and evaluating new services before enabling APIs is good change-management practice, but it does not establish a security control framework or clarify shared responsibility. The question is about control placement and responsibility boundaries for regulated data and audit requirements. Release notes won’t tell you which layers you must secure (IAM, keys, logging, segmentation) versus what Google secures.

Incorrect. A Cloud Identity user with rotating passwords and stored OAuth refresh tokens still relies on long-lived user credentials and secrets that can be exfiltrated from the CI/CD environment or vault. Refresh tokens are particularly sensitive because they can be exchanged for new access tokens. This violates the requirement to avoid long-lived user credentials and is not the recommended workload identity model for automated systems.

Incorrect. Using a Cloud Identity user account for automation is already against best practice for CI/CD because it introduces user credentials and typically long-lived refresh tokens. Additionally, disabling service account creation does not directly reduce the risk of credential theft from build pods; it can also hinder adopting the recommended approach (dedicated service accounts and Workload Identity) for workloads.

Incorrect. constraints/iam.allowServiceAccountCredentialLifetimeExtension enables longer-lived credentials, which increases the window of misuse if credentials are stolen. The scenario explicitly wants to minimize exfiltration risk and avoid long-lived credentials. Security best practice is to keep credentials short-lived and non-exportable, not to extend their lifetime.

Granting Compute Network User at the host project level is too broad. It would allow the group to attach VMs from the service project to any subnetwork in the host project’s Shared VPC, not just 172.16.20.0/24 in us-central1. This violates the requirement to prevent attachment to any other subnet. Project-level grants are common but fail least-privilege constraints.

Compute Shared VPC Admin (roles/compute.xpnAdmin) at the host project level is intended for administering Shared VPC: enabling a host project, associating/dissociating service projects, and managing Shared VPC-level settings. It is far more privileged than needed and does not directly implement a “only this one subnet” usage constraint. It also increases risk by expanding administrative capabilities.

Compute Shared VPC Admin at the service project level is not the right control point for subnet attachment. The subnetworks are owned by the host project, so the effective permission to use a subnet must be granted on the host project’s subnetwork resource. Additionally, xpnAdmin is an administrative role and is overly permissive relative to the requirement.

External SSL Proxy Load Balancer is a proxy-based, global external load balancer that terminates SSL/TLS and forwards traffic to backends. It is not designed for UDP (it’s for TCP with SSL offload) and, as a proxy, it does not preserve the original client source IP at the backend by default. It also requires the Premium network tier, violating the Standard tier cost constraint.

External TCP Proxy Load Balancer is also proxy-based and intended for TCP traffic (not UDP). Because it proxies connections, the backend typically sees the load balancer’s IP as the source, not the original client IP, which breaks per-player rate limiting and audit requirements. Additionally, external TCP proxy load balancing is a global external proxy service and requires Premium tier, conflicting with the Standard tier mandate.

Internal TCP/UDP Load Balancer supports TCP/UDP but is only for internal (private) traffic within a VPC or connected networks (VPN/Interconnect). It is not an internet-facing load balancer for public gaming clients. Even though it can preserve source IP for internal clients, it cannot meet the requirement of serving external players connecting over the public internet.

Incorrect. Even with Secret Manager and a 30-day rotation schedule, this approach still uses service account keys (long-lived credentials) and requires operational processes to rotate, redeploy, and handle failures. It also increases blast radius if a key is exfiltrated. The question explicitly forbids distributing long-lived credentials to workloads, which service account keys violate.

Incorrect. Storing service account keys in a Kubernetes Secret is the highest operational and security risk among the options: keys are long-lived, can be copied, and may be accessible to other principals in the namespace depending on RBAC. Rotation is manual/complex, and it directly violates the policy against distributing long-lived credentials to workloads.

Incorrect. Secret Manager is better than Kubernetes Secrets for storing sensitive material, but it does not solve the core issue: service account keys are still long-lived credentials that must be distributed to workloads. This increases management overhead (key lifecycle, rotation, rollout coordination) and conflicts with least-privilege best practices compared to Workload Identity’s short-lived, automatically rotated tokens.