Google Cloud Security practice questions

Cloud Audit Logs

Why wrong: 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 wrong: 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.

Create a separate perimeter for each VM and use IAM conditions

Why wrong: 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 wrong: 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 wrong: 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.

Cloud DLP

Why wrong: Cloud DLP identifies and redacts sensitive data but does not prevent exfiltration.

Cloud KMS

Why wrong: Cloud KMS manages encryption keys; it does not control access based on user identity or location.

Cloud Armor

Why wrong: Cloud Armor protects HTTP(S) load balancers, not Cloud Storage.

Use a cron job to call the Google Cloud API

Why wrong: 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 wrong: 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 wrong: Cloud Armor protects against DDoS and web attacks, not data exfiltration.

Sensitive Data Protection (DLP)

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

Cloud IDS

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

Data Loss Prevention API

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Security Command Center

Why wrong: Security Command Center is Google Cloud's security and compliance management platform that aggregates findings and monitors for threats, vulnerabilities, and misconfigurations. However, it does not include a content inspection engine capable of scanning object data within Cloud Storage for sensitive patterns such as PII or payment card numbers. While SCC can ingest findings from Sensitive Data Protection jobs, it does not perform the underlying data discovery itself, so it is not the correct service for this task.

reCAPTCHA Enterprise

Why wrong: reCAPTCHA Enterprise is designed to protect websites and APIs from automated bot traffic, fraud, and abuse by analyzing user interactions like mouse moves and keystroke timing. It does not inspect the content of files or objects at rest, nor does it have any pattern-matching capabilities for sensitive data. Therefore, it cannot scan Cloud Storage buckets for sensitive information and is not a valid answer to this requirement.

Web Risk API

Why wrong: Web Risk API is a threat intelligence service that checks URLs and domains against Google's lists of phishing, malware, and unwanted software sites. It works at the URL level, not at the data content level, so it cannot examine the bytes inside objects stored in Cloud Storage buckets. Since it lacks the ability to parse or match sensitive-data patterns, it is unsuitable for scanning for sensitive information.

Defence in depth

Why wrong: Defense in depth is a layered security strategy that employs multiple independent controls—such as network firewalls, intrusion detection systems, and endpoint protection—to protect resources without relying on any single measure. It is a resilience framework designed to slow down attackers and provide redundancy, but it does not prescribe how user entitlements are assigned. In contrast to least privilege, defense in depth focuses on the breadth of security mechanisms rather than the granularity of permissions, making it the wrong answer to the question about permission granting.

Separation of duties

Why wrong: Separation of duties is an internal control principle that breaks sensitive tasks into steps performed by different individuals so that no single person possesses end-to-end control over a critical process. Its purpose is to prevent fraud and conflicts of interest by requiring collusion to abuse systems, not to limit permissions to the minimum needed for a role. While it can indirectly reduce excessive authority, it addresses task allocation rather than the direct principle of granting only the necessary access, so it does not answer the permission-scoping question.

Zero trust

Why wrong: Zero trust is a comprehensive security model built on the mantra 'never trust, always verify,' requiring continuous authentication and authorization for every access attempt, regardless of the user's location or previous trust level. It is an architectural philosophy that incorporates elements like microsegmentation and continuous monitoring, rather than a focused principle for assigning minimal user permissions. Although least privilege is a component of zero trust, the model itself is broader and does not specifically define the extent of permission grants, making it incorrect for this question.

Cloud IDS

Why wrong: Cloud IDS is a network-level intrusion detection system that examines traffic for signatures of exploits, malware, or C2 activity. However, it inspects packet flows and does not evaluate the static configuration state of GCP resources such as IAM bindings, firewalls, or bucket ACLs. Thus, it would miss a publicly exposed Cloud Storage bucket or an over-privileged service account, making it unsuitable for finding misconfigurations.

Assured Workloads

Why wrong: Assured Workloads is designed to help organizations meet regulatory and compliance requirements by enforcing controls on data residency, encryption, and access, based on frameworks like FedRAMP or HIPAA. It configures the environment to support compliance but does not perform active vulnerability scanning or configuration assessment. Relying on it to find misconfigurations would confuse compliance enforcement with security posture auditing, so it is not the right tool for this task.

Cloud Audit Logs

Why wrong: Cloud Audit Logs records who did what, when, where, and on which resource, providing a forensic trail of actions and access. While audit logs can help identify changes that might lead to misconfigurations, they do not proactively scan the resource hierarchy or compare configurations against best-practice policies. They are passive records, not an active detection engine, so they cannot continuously flag insecure settings like an open firewall rule or unencrypted data.

Cloud Armor security policy

Why wrong: Cloud Armor security policies protect applications behind a Cloud External HTTPS Load Balancer by providing WAF rules, DDoS protection, and IP-based allow/deny filters at the edge. They do not attach to Cloud Storage's API endpoint or apply context-aware access control to direct API calls to storage.googleapis.com. Because the policy only evaluates traffic hitting the load balancer, it cannot enforce an IP allowlist for the Cloud Storage API itself.

Identity-Aware Proxy (IAP)

Why wrong: Identity-Aware Proxy (IAP) provides context-aware access control to applications through OAuth, session management, and signed headers, typically fronted by an HTTPS load balancer or configured for App Engine, Compute Engine, and GKE. It does not integrate with the Cloud Storage JSON or XML API, nor does it intercept requests made directly to the storage.googleapis.com endpoint. IAP is designed for user-based access to web applications, not for programmatic API calls to storage services.

VPC firewall rules

Why wrong: VPC firewall rules control network traffic between VM instances and subnets based on IP address, port, and protocol at the VPC network layer. They do not apply to Cloud Storage's external API endpoint, which is served from a global Google-managed infrastructure outside your VPC. Even if you set up egress deny rules on a VM, those rules do not affect API calls made from other clients, nor do they filter based on context like the requesting user's IP when the call arrives at the API. Therefore, firewall rules cannot enforce an IP-based condition on the Cloud Storage API itself.

Operational security

Why wrong: Operational security is incorrect here; it focuses on detecting and responding to threats through logging, monitoring, and incident response, not on encrypting data. While it may observe encryption-related events, it does not implement the encryption of data in transit or at rest itself.

Deployment security

Why wrong: Deployment security is incorrect because it covers how infrastructure and applications are securely released, such as using CI/CD pipelines, infrastructure as code, and vulnerability scanning of images. These practices prevent misconfigurations but do not perform data encryption; encryption is a separate data-layer control.

Physical security

Why wrong: Physical security is incorrect because it protects the hardware (servers, network gear) in data centers using biometrics, guards, and security cages. It ensures only authorized personnel physically access servers but does not encrypt the data stored on those servers; that is the role of the data security layer.

Cloud Identity

Why wrong: Cloud Identity is a directory and identity management service that provides user login, SSO, and device management, but it does not enforce access decisions on individual resources. Zero trust requires context-aware, per-request authorization at the resource layer, which Cloud Identity alone cannot provide. It is a foundational component, not the access-control mechanism.

Cloud Armor

Why wrong: Cloud Armor is a network security service that provides DDoS protection and a web application firewall (WAF) at the edge. It filters traffic based on IP, geo, and Layer 7 signatures, but it does not inspect the user's identity, device posture, or session context. Therefore, it cannot enforce the identity-centric, dynamic zero-trust policies required for granular access control.

Cloud VPN

Why wrong: Cloud VPN creates encrypted IPsec tunnels to connect on-premises networks to Google Cloud, providing secure connectivity at the network layer. However, once a connection is established, it typically grants broad network access without verifying the identity or context of each individual user or request. This aligns with the traditional perimeter-based model, not zero trust, which demands per-request verification and context-aware authorization.