Google Cloud Security practice questions

Cloud Audit Logs

Why it fails: Cloud Audit Logs are incorrect because they serve as an immutable record of administrative actions, data access, and system events, which is essential for compliance and forensic analysis. However, audit logs are passive telemetry—they do not actively analyze patterns, correlate events, or generate threat alerts, so they must be paired with tools like Security Command Center or Chronicle to enable actual threat detection.

Mandiant

Why it fails: Mandiant is incorrect because it primarily delivers expert-driven threat intelligence, incident response services, and manual or managed threat hunting. While it provides deep knowledge and specialized tools for investigating and remediating sophisticated attacks, it is not a continuously operating, automated security management console that detects and prioritizes threats across a Google Cloud environment without human intervention.

Secret Manager

Why it fails: Secret Manager is a service for securely storing and managing API keys, passwords, and certificates as secret strings. It does not manage cryptographic keys for data encryption, lacks the key rotation and versioning features needed for encryption key lifecycles, and cannot be directly integrated with Google Cloud services to encrypt data at rest. Using Secret Manager would not satisfy a requirement to manage encryption keys.

Google-managed encryption keys

Why it fails: Google-managed encryption keys are the default encryption keys that Google Cloud automatically applies to all data at rest. These keys are generated, stored, and rotated by Google without customer involvement, giving customers no ability to control the key material, set IAM policies, or perform cryptographic operations on demand. Since the company needs to manage or control the keys, this option fails to provide the required level of customer control.

Customer-supplied encryption keys (CSEK)

Why it fails: Customer-supplied encryption keys (CSEK) require customers to provide their own key material and manage key storage, rotation, and lifecycle entirely outside Google Cloud. Google uses the key to encrypt data but does not persist it, and if the key is lost, data becomes unrecoverable; moreover, CSEK keys are not integrated with Cloud KMS and do not provide centralized audit or access control. This places the operational burden solely on the customer, unlike a managed key service.

Create a separate perimeter for each VM and use IAM conditions

Why it fails: Creating a separate VPC Service Controls perimeter for each VM is fundamentally unscalable and quickly hits the hard limit on the number of perimeters per project. IAM conditions only gate authorization at the resource level; they do not constrain the network path or enforce an explicit context-aware boundary, so the same compromised credential could still reach BigQuery from outside the intended network context.

Add the project to a perimeter and create an egress rule to allow access from authorized VMs

Why it fails: An egress rule governs traffic leaving a service perimeter, not traffic entering it to reach a protected resource like BigQuery. Because the authorized VMs are outside the perimeter and need to send requests into the project that contains BigQuery, the correct control is an ingress rule that explicitly permits those VM service accounts to access the protected resources. Using egress would leave the project closed to inbound requests.

Use Cloud Armor to whitelist the VMs' IP addresses for BigQuery access

Why it fails: Cloud Armor is a web application firewall that protects HTTP(S) load-balanced traffic, not the BigQuery Data API or other Google Cloud service endpoints. Whitelisting VM IP addresses would also be insufficient because BigQuery requests originate from service accounts, not raw IPs, and Cloud Armor cannot enforce the identity-based, context-aware perimeter that VPC Service Controls provides. This option conflates layer-7 edge protection with service-level network access control.

Create a new service account, grant the Cloud Run Deployer role, and export a key file to the instance

Why it fails: Exporting a service account key file to the instance creates a long-lived credential that must be stored, rotated, and protected; if the instance is compromised, the key can be exfiltrated and used outside the instance. Attaching the service account directly to the instance via the metadata server avoids this risk, so while this option technically works, it violates the security best practice of avoiding service account keys in favor of instance-attached identities.

Use the Cloud Run service agent with the roles/run.serviceAgent role

Why it fails: The Cloud Run service agent (with roles/run.serviceAgent) is a Google-managed identity used by the Cloud Run control plane to perform operations like reading container images or writing logs; it is not an identity that a CI/CD pipeline should assume. The pipeline runs with its own service account, and using the service agent would grant internal service permissions that are neither intended nor appropriate for external deployments, and it would not provide the deployer role needed for the pipeline's actions.

Grant the Cloud Run Admin role to the user account running the pipeline

Why it fails: The pipeline runs as a service account, not as an individual user, so granting roles/run.admin to a user account does not affect the pipeline's permissions. Moreover, Cloud Run Admin is a broad role that allows creating, deleting, and updating all Cloud Run resources, which violates least privilege when compared to the more focused roles/run.deployer. The correct approach is to grant the deployer role to the service account identity that the pipeline actually uses, not to a human user's account.

Grant the Cloud KMS CryptoKey Encrypter/Decrypter role to the service accounts

Why it fails: The service accounts need the role, but this is an additional step not listed in the options as required for the question.

Enable CMEK in the project settings

Why it fails: CMEK is enabled per resource, not project-wide.

Upload a custom key to Cloud HSM

Why it fails: CMEK uses Cloud KMS, not Cloud HSM (though HSM can be used, not required).

Use IAM conditions to restrict access to the VPC

Why it fails: IAM conditions do not enforce network-level perimeters.

Enable Private Google Access on the VPC subnets

Why it fails: Private Google Access allows VMs to access Google APIs, but does not restrict access from outside.

Create a firewall rule that denies all traffic to Cloud Storage

Why it fails: Firewall rules apply to VM instances, not Cloud Storage API.

roles/bigquery.dataEditor

Why it fails: Allows modifying data, which violates least privilege.

roles/bigquery.admin

Why it fails: Full admin access, not least privilege.

Permissions

Why it fails: Permissions are atomic statements that enumerate specific actions on resources, such as 'read object' or 'delete instance'. However, the IAM concept that defines whether a user can actually perform those actions is authorization, which evaluates policies, conditions, and context to allow or deny a request. Merely possessing a permission is necessary but not sufficient; authorization governs how those permissions are applied in practice.

Authentication

Why it fails: Authentication is the process of verifying a principal's identity through credentials like passwords, tokens, or keys. It answers the identity verification question, not the authorization question. It is a prerequisite for access control, but it does not define what actions a user is allowed to perform; that decision is made by authorization after identity is established.

Roles

Why it fails: Roles are named collections of permissions that are assigned to users or groups to simplify access management. Although roles are commonly used to bundle permissions, they are not the concept that defines what actions users can perform; they are an organizational and packaging mechanism. Authorization uses roles as input to make decisions, but the actual process of deciding allowed actions is authorization itself, not the role construct.

Use a cron job to call the Google Cloud API

Why it fails: A cron job that calls the Google Cloud API is an external workaround, not a Cloud KMS-managed feature. It would require provisioning and maintaining a compute instance or scheduler, storing service account credentials, and manually invoking methods like `cryptoKeyVersions.create` and `cryptoKeys.updatePrimary`. This adds operational overhead, introduces a dependency on an external system, and is prone to missed rotations or permission errors, unlike Cloud KMS's natively managed rotation scheduler.

Manually create a new key version every 90 days

Why it fails: Manually creating a new key version every 90 days is not automatic rotation—it requires human intervention and is error-prone. Each manual rotation also requires you to remember to promote the new version to primary and update all downstream systems that reference the key, whereas Cloud KMS's automatic rotation handles version creation and primary promotion atomically based on the configured schedule. This approach negates the security benefits of consistent, predictable rotation and relies on undocumented, ad-hoc processes.

Cloud Armor

Why it fails: Cloud Armor protects against DDoS and web attacks, not data exfiltration.

Sensitive Data Protection (DLP)

Why it fails: DLP helps classify and redact sensitive data, but does not prevent exfiltration.

Cloud IDS

Why it fails: Cloud IDS detects network intrusions but does not prevent data exfiltration.

roles/compute.networkAdmin

Why it fails: roles/compute.networkAdmin manages firewall rules, subnets and routes, none of which deploying applications or reading logs requires. It is tempting because network configuration often accompanies deployment, and would be the right choice for a network engineer, not for these developers.

roles/compute.admin

Why it fails: roles/compute.admin grants full control of Compute Engine, including deleting instances and managing images, exceeding what deploying applications requires. It is tempting because it certainly permits deployment, and would be correct for a platform administrator, not for least-privilege developers.

Data Loss Prevention API

Why it fails: The Data Loss Prevention (DLP) API is designed to inspect, classify, and de-identify sensitive data such as credit card numbers, personally identifiable information, and custom regex patterns within your own datasets. It does not monitor or log who accesses that data, let alone track actions performed by Google personnel. DLP operates on the content plane, not control-plane or administrative access, so it cannot provide the required transparency into Google staff activity.

VPC Service Controls

Why it fails: VPC Service Controls is a security perimeter mechanism that protects Google Cloud resources by preventing data exfiltration through unauthorized network connections, using perimeters and egress/ingress policies. It is a preventive control that restricts traffic, but it does not generate logs or provide visibility into the identity or actions of Google personnel accessing data from inside Google's infrastructure. The engineer needs a detective control for transparency, not a network-level barrier.

Cloud Audit Logs

Why it fails: Cloud Audit Logs records administrative and data-access operations performed by principals such as users, service accounts, or groups within your own GCP project (e.g., who created a VM, modified an IAM policy, or read a GCS object). By default, these logs do not include actions taken by Google's internal staff, because those actions occur on Google's side of the boundary. While Access Transparency feeds into Cloud Audit Logs when enabled, the standard Cloud Audit Logs alone cannot answer the engineer's question about Google personnel access.

Cloud Armor

Why it fails: Cloud Armor is a web application firewall (WAF) and DDoS mitigation service that inspects HTTP/HTTPS traffic at the edge, applying rules based on IP, geo, and layer 7 characteristics. It protects load-balanced applications from attacks like SQL injection and cross-site scripting, not data access at the storage layer. Because Cloud Storage is accessed via its own API and not through an HTTP load balancer, Cloud Armor cannot enforce bucket-level access restrictions for VM-to-storage traffic.

Identity-Aware Proxy (IAP)

Why it fails: Identity-Aware Proxy controls user-level access to web applications via identity and context, not network-level access to Cloud Storage buckets from VMs. It fails because the requirement is to restrict bucket access to specific VPCs and VMs, not to authenticate individual users. IAP is tempting because it enforces access based on identity and device context, which would be correct for securing a web-based customer portal against unauthorised data downloads.

Cloud NAT

Why it fails: Cloud NAT lets private VMs initiate outbound connections to the internet by performing source network address translation. It is a connectivity feature that does not examine or restrict traffic based on destination, and it certainly cannot enforce per-bucket authorization. Deploying Cloud NAT might even increase the risk of data exfiltration because it gives VMs a path to send data outbound; it does not provide any access control for Cloud Storage resources.

Identity-Aware Proxy (IAP)

Why it fails: Identity-Aware Proxy (IAP) is a single component within the BeyondCorp Enterprise architecture, not a standalone VPN replacement. IAP provides per-request application-level authorization using identity and context, but it does not include the broader zero-trust capabilities such as endpoint health verification, data loss prevention, or threat detection. Choosing IAP alone leaves gaps in endpoint security and policy enforcement, so it is incomplete for replacing an enterprise VPN.

Cloud VPN

Why it fails: Cloud VPN creates an IPSec tunnel between on-premises networks and Google Cloud, giving users or sites network-level access to the entire private CIDR range. This follows the legacy perimeter-security model: once inside the tunnel, a user retains broad network trust, regardless of identity, device, or context. It lacks granular, per-request authorization and does not enforce zero-trust principles, making it the opposite of a zero-trust remote-access solution.

Cloud Identity

Why it fails: Cloud Identity is an identity and access management service that provides user lifecycle management, SSO, and group-based policies for Google Cloud and third-party apps. It does not mediate access to resources or evaluate device context and security posture for every request. While identity is a key input to zero trust, Cloud Identity alone cannot replace a VPN because it lacks the proxy and enforcement layer needed to control application-level access.

Default encryption at rest

Why it fails: Default encryption at rest automatically encrypts data using Google-managed keys before it is written to disk, with no action required from the customer. The keys are created and rotated behind the scenes, and the customer has no ability to view, manage, or control them. Because the organization specifically wants to manage keys itself rather than relying on Google's default transparency-free encryption, this option is incorrect.

Customer-supplied encryption keys (CSEK)

Why it fails: CSEK requires you to supply your own raw key material with every API call, and you must manage the key's lifecycle (generation, rotation, storage, and destruction) entirely outside Google. It does not integrate with Cloud KMS, so you forgo centralized key management, IAM-based access control for keys, and native rotation capabilities. This is why it does not meet the organization's need to manage keys through a managed service.

Google-managed encryption keys

Why it fails: Google-managed encryption keys are fully owned and operated by Google: Google generates, stores, rotates, and controls access to the keys, with no customer visibility or management capability. While this provides robust default security, it fails the requirement when an organization needs to exercise its own control, set key rotation policies, or define per-key IAM permissions. The org's requirement implies active customer governance over key material, which this option cannot deliver.

Security Command Center

Why it fails: Security Command Center is a security and posture management service that aggregates vulnerability findings and misconfiguration risks across GCP, but it does not ingest or correlate raw logs from multiple clouds as a SIEM would. Its purpose is to prioritize and remediate security issues, not to provide persistent log-based threat detection and incident response. Therefore, while useful for visibility into GCP assets, it lacks the log analytics engine needed for multi-cloud SIEM workflows.

Cloud IDS

Why it fails: Cloud IDS is a network intrusion detection service that inspects traffic between subnets and on-premises networks for malicious signatures, operating at the packet and flow level. It does not analyze application logs or security telemetry from disparate cloud providers, and it offers no capabilities for querying historical log data or correlating events across environments. This makes it a complementary security control, not a substitute for log-driven SIEM analysis.

Cloud Logging

Why it fails: Cloud Logging is a centralized log management and monitoring service that stores logs from GCP services and can receive logs from other sources, but it does not provide core SIEM capabilities such as entity correlation, threat detection rules, incident management, or security-specific analytics. Its primary focus is operational observability—like searching logs for troubleshooting—rather than performing the deep threat correlation and multi-source attack-chain reconstruction expected from a SIEM. Thus, while logs can be exported to a SIEM like Chronicle, Cloud Logging itself is not a SIEM solution.

reCAPTCHA Enterprise

Why it fails: reCAPTCHA Enterprise is a bot-management service that uses risk analysis and behavioral signals to distinguish human users from automated clients. It does not inspect HTTP request payloads for SQL injection or cross-site scripting patterns, nor does it provide signature-based WAF rules or absorb large-scale DDoS floods. For this reason, it can be part of a layered defense against credential-stuffing bots, but it cannot protect the web application from OWASP Top 10 exploits or volumetric distributed denial-of-service.

Cloud CDN

Why it fails: Cloud CDN is a content delivery network that caches static assets at distributed points of presence to reduce latency and backend resource load. It does not terminate TLS, inspect application-layer payloads, or make allow/deny decisions based on HTTP content; it simply forwards requests that miss the cache to the origin. While it can indirectly dampen some reflected amplification attacks by serving cached responses, it is not a security control and cannot filter SQL injection or other application-layer attacks.

VPC firewall rules

Why it fails: VPC firewall rules are stateful packet filters that operate at the network and transport layers (IP addresses, ports, and protocols). They are evaluated for every packet entering or leaving a VPC network, but they do not have visibility into application-layer data—such as HTTP body content—needed to detect SQL injection or cross-site scripting. Their primary purpose is to enforce network segmentation and access control, so they cannot serve as a web application firewall.

Cloud KMS

Why it fails: Cloud KMS is a cryptographic key management service that generates, rotates, and uses encryption keys to protect data, but it does not store secrets like database passwords; it stores key material. Access to Cloud KMS controls who can use a key for cryptographic operations, not who can retrieve a plaintext secret, and it does not provide secret versioning or application-level secret retrieval APIs. Treating keys as secrets misses the distinction between protecting data and storing credentials.

Cloud Key Management Service

Why it fails: Cloud Key Management Service is the full name for Cloud KMS, and while it is a centralized key vault for managing cryptographic keys, it is not a general-purpose secret store for passwords and API keys. A common misconception is that since keys are themselves secrets, the service can serve as a secret manager, but it lacks features like automatic secret rotation policies, secret versioning tied to application releases, and per-secret IAM roles for non-key material. Using it for database credentials would be an architectural anti-pattern.

Cloud Storage

Why it fails: Cloud Storage is object storage for unstructured blobs, with bucket-level IAM and lifecycle policies, but it lacks native secret-versioning, rotation, and per-secret audit capabilities. Storing database passwords there would require bolting on client-side encryption and manually managing access control, which is error-prone and not a secure pattern. It is not designed for secret management.

To control ingress and egress traffic at the network level

Why it fails: VPC firewall rules are the appropriate mechanism for controlling ingress/egress at the network level, evaluating packet attributes like IP addresses and ports. VPC Service Controls, in contrast, operate at the Google Cloud API layer, enforcing context-aware access to managed services without inspecting network packets. Consequently, this option misattributes a core network function to a service designed for data boundary control.

To detect network intrusions

Why it fails: Intrusion detection is the domain of Cloud IDS, which inspects traffic for signatures and anomalies that indicate malicious activity. VPC Service Controls never analyze packet contents; they enforce policies on service requests and responses to prevent unauthorized data movement. Thus, this choice mistakes a threat-detection tool for a data-exfiltration prevention mechanism.

To protect against DDoS attacks

Why it fails: DDoS protection is delivered by Cloud Armor, which mitigates volumetric and protocol attacks at the network edge through filtering and rate limiting. VPC Service Controls do not address network availability or absorb attack traffic; they restrict data access and transfer. Therefore, this option confuses availability protection with data access governance.

Cloud Audit Logs

Why it fails: Cloud Audit Logs are wrong because they record administrative and data-access operations performed by principals within your own Google Cloud project, such as users, service accounts, and groups. They do not capture actions by Google employees, because Google personnel are not identity principals in your project; their access is governed by Google's own internal infrastructure. Therefore, Cloud Audit Logs cannot satisfy a requirement to log Google personnel access.

Security Command Center

Why it fails: Security Command Center (SCC) is a security and risk management platform that collects and correlates findings about misconfigurations, vulnerabilities, and threats across your cloud environment. It does not generate raw audit logs of personnel access; instead, it ingests findings from services like Cloud Audit Logs and Access Transparency for threat detection and compliance dashboards. SCC might display access-related findings, but it is not the logging service itself.

Assured Workloads

Why it fails: Assured Workloads is a compliance-oriented service that helps you enforce regulatory controls such as data residency, boundary conditions, and access approval policies on a dedicated infrastructure; it does not directly produce logs of Google personnel actions. Even when an Assured Workloads folder enables Access Approval/Transparency integrations, the actual logging they seek is performed by Access Transparency, not by Assured Workloads itself. Thus, it may support the governance framework but is not the logging mechanism.