Trust and security with Google Cloud practice questions

Grant the Storage Admin role at the project level but add a condition that limits it to specific operations

Why it fails: IAM conditions can restrict by resource name or time, but starting with Storage Admin (which includes delete and create bucket permissions) and trying to narrow it is harder and more error-prone than starting with a minimal role at the resource level.

Create a custom IAM role that combines all permissions from all predefined roles but removes the most dangerous ones

Why it fails: Starting from all permissions and removing dangerous ones is the opposite of least privilege — it's more likely to leave excessive permissions than starting from a minimal set and adding only what's needed.

Use the same broad Storage Admin role but rotate the service account key every 90 days to reduce the window of exposure

Why it fails: Key rotation reduces credential exposure time but doesn't address the core problem: the service account has far more permissions than it needs. A compromised credential within the 90-day window still has full Storage Admin access. Least privilege reduces blast radius; rotation reduces exposure duration — both are needed, but least privilege must be addressed first.

Create a custom role with compute.instances.insert and compute.instances.delete permissions.

Why it fails: A custom role with both compute.instances.insert and compute.instances.delete permissions would allow developers to delete instances, violating the requirement.

Assign all developers the primitive role of Editor.

Why it fails: Assigning the Editor primitive role gives developers broad permissions, including the ability to delete instances, so it does not meet the requirement.

Create a service account for each developer and grant it the compute.instanceAdmin role.

Why it fails: The compute.instanceAdmin role includes compute.instances.delete permission, which would allow developers to delete instances.

Cloud Data Loss Prevention (DLP)

Why it fails: Cloud DLP is a data security service that inspects, classifies, and de-identifies sensitive data in streams and at rest, but it does not record who accessed what resource. It identifies content like credit card numbers or personal IDs and applies protection techniques such as redaction or tokenization. While valuable for preventing data exposure, it generates no access logs, so it cannot satisfy the requirement to log every access event.

Security Command Center

Why it fails: Security Command Center is a security and risk management platform that aggregates findings across Google Cloud, such as vulnerability findings, misconfigurations, and threat detection. It does not natively capture per-access logs of data reads or writes; it provides a prioritized list of security issues, not a chronological record of individual data access. Therefore, it may highlight that a bucket is public, but it cannot tell you who accessed a specific object or when.

Cloud Audit Logs

Why it fails: Cloud Audit Logs record administrative activities, configuration changes, and some data-level events in your own Google Cloud project. The Admin Activity logs are always on, but Data Access logs are disabled by default and only capture certain resource types, not all data reads and writes. Critically, Cloud Audit Logs do not capture actions performed by Google personnel on your data, which is the key requirement here for ensuring all access.

The project has reached its compute instance quota.

Why it fails: Quota exhaustion in Compute Engine is reported as a resource-limit error, such as "Quota 'INSTANCES' exceeded. Limit: 5.0" or HTTP 429, and it is independent of IAM. The error here names a specific service account as lacking compute.instances.create, which is a permission-check failure, not a capacity-check failure. Therefore, a quota-limit message would not be issued for an IAM denial, and the answer is incorrect.

The developer does not have the compute.instances.create permission.

Why it fails: Project Editor (roles/editor) includes compute.instances.create for the entire project, so the developer's own identity is authorized to create the instance. The error message explicitly references the service account 'my-service-account' as the principal without permission, not the developer's user account. Misreading the error subject (the service account vs. the user) is a common mistake; the user's permission is not the bottleneck.

The VPC network has insufficient IP addresses.

Why it fails: Insufficient IP addresses in a VPC subnet would trigger an error like 'ZONE_RESOURCE_POOL_EXHAUSTED' or 'no free IPs in subnet', which is a networking capacity issue, not an IAM authorization failure. The error text here indicates an IAM permission check against a service account, which is unrelated to IP availability. Subnet exhaustion is also a zonal/subnet-level condition, whereas the failing permission is project-scoped and principal-scoped.

IAM and Cloud IAP

Why it fails: IAM alone is correct for managing roles, but Cloud IAP (Identity-Aware Proxy) cannot be used to secure BigQuery. IAP is designed for HTTP/HTTPS web applications, sitting in front of App Engine, Cloud Run, or a load balancer to verify user identity at the L7 layer; it does not intercept or filter BigQuery's REST API calls made by client libraries, SDKs, or the bq command-line tool. Because BigQuery is not a web application with a browser-facing endpoint, IAP cannot enforce network or identity restrictions on its API, so pairing IAM with IAP fails to meet the requirement.

Cloud Armor and IAM

Why it fails: Cloud Armor is a Web Application Firewall and DDoS mitigation service that inspects incoming HTTPS traffic to external HTTP(S) load balancers, applying rules based on IP addresses, geo-location, or custom expressions. It is not an access-control proxy for BigQuery APIs, which use gRPC or REST endpoints that never traverse Cloud Armor. While IAM grants a data analyst read-only roles, Cloud Armor cannot apply network-level restrictions to those API requests, so the combination does not achieve the desired context-aware, network-secured access.

Organization Policies and Cloud Audit Logs

Why it fails: Organization Policies (constraints) enforce guardrails such as restricting resource locations or disabling public IPv4 addresses, but they are administrative rules that can never grant or deny access to a specific user; permissions are always assigned via IAM. Cloud Audit Logs are diagnostic records that capture 'who did what, when' and are invaluable for forensics and compliance, but they have no ability to block or authorize access—they only observe it. Since the data analyst needs read-only access, neither component provides the actual authorization (IAM), making this pair insufficient.

Alice can view objects only in non-sensitive buckets, and can view objects in sensitive-data only after 9 AM due to condition.

Why it fails: This statement incorrectly attributes a time-based condition to Alice's access. The condition (likely about 9 AM) applies to Carol's objectAdmin role, not to Alice's objectViewer role. Since Alice's role is unconditional, she has immediate and unrestricted read access to all buckets, including sensitive-data, regardless of the time of day. The condition does not gate her permissions.

Alice can view objects in all buckets except sensitive-data.

Why it fails: This option suggests that there is some exclusion for the sensitive-data bucket, but no such exclusion exists in the policy applied at the project level. Alice's objectViewer role is granted without any scope restriction to specific buckets or any condition that would exclude a particular bucket. IAM roles at the project level apply to all resources in the project, so she can view objects in sensitive-data as well.

Alice can view and modify objects in all buckets.

Why it fails: The objectViewer role is read-only by design; it includes permissions like storage.objects.get and storage.objects.list but does not include write permissions such as storage.objects.update or storage.objects.create. Therefore, Alice can view objects but cannot modify them. To modify objects, she would need a role like objectOwner or objectAdmin, which grants write access.

Remove public IPs from all Compute Engine instances and enforce firewall rules to block SSH from the internet.

Why it fails: Removing public IPs and enforcing firewall rules is a critical security measure but does not address the data residency violation. The bucket remains in the wrong region, so compliance is not achieved. This step should be taken after or in parallel with the data migration.

Configure VPC Service Controls to create a secure perimeter around the project and restrict data movement.

Why it fails: Configuring VPC Service Controls creates a security perimeter but does not change the location of existing data. The bucket is still in a multi-region, violating the residency policy. This is a secondary step.

Enable customer-managed encryption keys (CMEK) on the bucket to encrypt all objects at rest.

Why it fails: Enabling CMEK encrypts objects at rest but does not affect the bucket's location. It addresses encryption, not location compliance.

Yes, customers must enable encryption in the Cloud Storage bucket settings for each bucket.

Why it fails: Cloud Storage bucket configuration does not include an 'enable encryption' setting; encryption is applied transparently and always. When an object is uploaded, Google encrypts it at the storage layer using AES-256 before persisting it, regardless of bucket-level settings. Therefore, any claim that the customer must per-bucket enable encryption conflates optional features like CMEK with the default encryption that is universally present.

Only data in premium storage tiers is encrypted; Standard storage requires manual encryption.

Why it fails: Encryption at rest is a uniform platform capability applied to every Cloud Storage storage class—Standard, Nearline, Coldline, and Archive—without any customer action. There is no 'premium tier' that gets additional default encryption, and Standard storage does not require manual configuration. Google automatically encrypts all object data using AES-256 before it is written to disk.

Customers must purchase the Security Command Center Premium tier to enable data encryption.

Why it fails: Security Command Center is a vulnerability monitoring and security analytics service, not a mechanism for enabling at-rest encryption. Data encryption in Google Cloud is a foundational feature of the platform, included in the base service at no additional charge and active on all storage services. Purchasing SCC Premium does not turn on encryption because encryption is already on; it simply provides visibility into misconfigurations and threats.

Perimeter security model

Why it fails: The perimeter security model, often called the castle-and-moat approach, assumes that anything inside the network firewall is inherently trustworthy and only focuses protections on the network edge. This model fails against insider threats, compromised credentials, and advanced attackers who breach the perimeter and then move laterally with minimal friction, because it never re-evaluates trust for internal requests, directly contradicting Zero Trust's continuous verification.

Defense in depth model

Why it fails: Defense in depth is a risk-management strategy that layers independent security controls—such as firewalls, intrusion detection, antivirus, and endpoint protection—so that if one fails, others provide redundancy. While complementary to Zero Trust, it describes the stacking of countermeasures rather than a policy of verifying each request's legitimacy based on identity and context; a defense-in-depth architecture can still trust internal traffic implicitly, unlike Zero Trust.

Principle of least privilege

Why it fails: The principle of least privilege is an access-control practice that grants users and services only the minimum permissions required to perform their functions, reducing the blast radius of compromised accounts. However, it is a single component of a comprehensive security strategy, not an architectural model; it does not inherently require dynamic re-authentication of every request, ongoing device health assessment, or encryption of all traffic, which are hallmarks of Zero Trust.

Google controls who can access the database and what data can be stored.

Why it fails: In Google Cloud managed databases like Cloud SQL or AlloyDB, the customer creates database users, assigns IAM roles, manages SSL/TLS certificates, and defines schemas. Google never makes decisions about who can query a table or what columns or records exist. That access control and data governance responsibility rests with the database administrator at the customer's organization. Thus, this statement is incorrect because it inverts the shared responsibility model for data plane access.

Google is responsible for backing up customer data and ensuring data recovery.

Why it fails: In services like Cloud SQL, Google operates the backup infrastructure—automatically creating backups when enabled—but the decision to enable backups, set retention windows, and perform point-in-time recovery belongs to the customer. Customers must also test restore procedures and integrate backups into their overall disaster recovery plan. Google does not proactively ensure data recoverability unless the customer configures these features; if backups are disabled or deleted, Google typically cannot restore the data. Therefore, this responsibility is shared, not entirely Google's.

Google determines which compliance certifications the customer's application must meet.

Why it fails: Compliance obligations like PCI DSS, HIPAA, or GDPR apply based on the customer's business, data type, and jurisdiction, not on Google's choices. Google does not assess your application's requirements; instead, it offers a set of certifications and compliance reports (e.g., SOC 2, ISO 27001) that customers use as evidence of the infrastructure's controls. The customer is responsible for architecting the application and configuring GCP services to meet those regulatory standards. Google's role is to provide the secure foundation and compliance artifacts, not to decide what the customer must comply with.

Storing data in Google Cloud automatically makes an application HIPAA-compliant.

Why it fails: Simply storing protected health information (PHI) in Google Cloud does not create compliance, because HIPAA demands ongoing administrative and technical safeguards such as risk analysis, role-based access, and workforce training. Synchronizing a BAA and selecting HIPAA-eligible services only establishes the foundation; the customer must still architect controls, enforce least privilege, and monitor access. Compliance is an operational state, not an inherent property of a storage location.

HIPAA compliance is impossible on public cloud; healthcare data must stay on-premises.

Why it fails: While some assume public cloud cannot meet healthcare regulations, HIPAA does not mandate on-premises storage. The HHS explicitly permits cloud computing when covered entities sign a Business Associate Agreement (BAA) with a compliant cloud provider like Google Cloud. Moreover, physical security and infrastructure safeguards in a hyperscale cloud often exceed those of a typical hospital data center, so the premise is technically false.

Google Cloud's automatic data encryption fully satisfies all HIPAA technical safeguard requirements.

Why it fails: Automatic encryption at rest and in transit addresses one aspect of the HIPAA Technical Safeguards standard, but that standard also requires access controls including unique user identification, emergency access procedures, automatic logoff, and audit trail capabilities. Additionally, integrity controls and transmission security go beyond simple encryption, encompassing measures like hashing, integrity monitoring, and custom VPN configurations. The burden remains on the covered entity to configure and validate these controls, so encryption alone is insufficient.

`roles/bigquery.admin`

Why it fails: The `bigquery.admin` role provides full control over BigQuery, including dataset creation and deletion, table updates, IAM policy management, and execution of all jobs. It encompasses far more power than a data engineer who only needs to read and query specific datasets needs. Granting this role would violate least privilege and create an unnecessary security risk, as the engineer could inadvertently modify or delete data and change access controls.

`roles/viewer` (project-level Viewer)

Why it fails: Project-level Viewer is a basic role that grants read access to all resources in the project, such as Virtual Machines, Cloud Storage, and Networking, not just BigQuery. This is overly broad for a data engineer whose scope is limited to BigQuery datasets, violating least privilege. It also does not include the `bigquery.jobUser` permission, so even within BigQuery it would not allow running queries.

`roles/bigquery.dataEditor`

Why it fails: The `dataEditor` role includes read permissions but also grants write access to table data, such as inserting, updating, and deleting rows. This exceeds the engineer's requirement, which is strictly read-only analysis. Additionally, while dataEditor includes job creation permission, the write capability is the primary concern, as it allows accidental or unauthorized modification of the data.

Security Command Center — it scans BigQuery for sensitive data automatically.

Why it fails: Security Command Center (SCC) is a centralized security and risk management platform that aggregates findings from various GCP services, not a data inspection engine. It cannot scan BigQuery table content for sensitive data directly; instead, Cloud DLP performs the inspection and sends its findings to SCC for visibility and remediation. Therefore, claiming SCC scans BigQuery automatically conflates the finding aggregator with the classification service.

Cloud Monitoring custom dashboards with SQL queries that search for PII patterns.

Why it fails: Cloud Monitoring custom dashboards are designed to track operational metrics such as latency, errors, and resource utilization, not to inspect data stored in BigQuery. Writing SQL queries that search for PII patterns would require executing those queries over every table, which is inefficient, non-scalable, and lacks the comprehensive infoType coverage that Cloud DLP provides. Cloud Monitoring is not a data security solution, and this approach would miss sensitive data outside the exact patterns you manually define.

Cloud Audit Logs — they record all BigQuery queries and can identify when sensitive columns are accessed.

Why it fails: Cloud Audit Logs record who accessed which BigQuery resources and when, but they do not inspect the actual data content within the tables. While an audit log entry might show that a specific user ran a query against a column, it cannot tell you whether that column contains PII or other sensitive patterns. To identify where sensitive data resides, you need a data classification tool like Cloud DLP, not just access logs.

It prevents unauthorized users from accessing the Google Cloud Console.

Why it fails: Access to the Google Cloud Console is governed by IAM (Identity and Access Management) policies that authenticate the user and authorize specific roles and permissions. HTTPS on an application encrypts traffic to that application, but it does not grant or deny anyone access to the console—it neither identifies the user nor checks their IAM permissions. Unauthorized users are blocked by login and IAM checks, not by the presence or absence of TLS.

It encrypts data stored in the server's database.

Why it fails: HTTPS/TLS secures data only while it is being transmitted over the network. Data stored in a server's database is at rest and is protected by separate mechanisms, such as Google Cloud's default encryption at rest or customer-managed encryption keys. Even with HTTPS active, the application or database may store plaintext data unless that layer is explicitly encrypted, so this option mistakes in-transit protection for at-rest protection.

It authenticates the user and verifies their permissions to use the application.

Why it fails: TLS/HTTPS authenticates the server to the client using a digital certificate, proving the server's identity, but it does not authenticate the client user. User identity and permissions are validated separately through credential checks, such as passwords, multi-factor authentication, or SAML/OIDC single sign-on, and then authorized by the application or IAM. Therefore, HTTPS alone cannot confirm who the user is or which operations they may perform, so this option conflates server authentication with user authentication.

Access Transparency shows customers which Google Cloud services are available in their region.

Why it fails: Access Transparency does not expose the catalog of available services per region; Google Cloud's documentation and the regions page list service availability across locations. Instead, Access Transparency is purpose-built to monitor a specific risk: internal human access to customer data. The feature captures audit log entries when Google staff access content, including the reason and scope, thereby addressing regulatory and compliance requirements rather than providing a service catalog.

Access Transparency is a feature that makes all customer data visible to Google for quality improvement.

Why it fails: Access Transparency actually works in the opposite direction: it pulls back the curtain on Google's own behavior to give customers visibility into what Google personnel do with their data. Rather than exposing customer information to Google for improvement purposes, it logs and surfaces metadata about any access that does occur, so customers can detect and audit unauthorized activity. This supports a 'no perpetual access' model where customer content remains under the customer's control, and any access by Google requires a documented business justification. The misconception typically stems from confusing transparency with data sharing, but the feature is a governance control, not a data-processing pipeline.

Access Transparency provides customers with real-time dashboards of their application's security vulnerabilities.

Why it fails: Access Transparency does not perform vulnerability scanning or offer any dashboard of application weaknesses; real-time risk and vulnerability posture for customer workloads is delivered by Google Cloud Security Command Center (SEC), which aggregates findings from services like Security Health Analytics and Web Security Scanner. Access Transparency serves a different layer: it records the human side of cloud operations by logging when Google personnel access customer data, with reasons and timestamps. Confusing these two conflates threat detection with access governance, which are distinct controls in a defense-in-depth architecture.

Google employees have unrestricted access to all customer data as part of the infrastructure service agreement.

Why it fails: Google employees do not have unrestricted access to customer data. Access is granted on a least-privilege basis, requiring business justification, and is logged in Access Transparency, Google Cloud’s near-real-time log of personnel access. The Cloud Data Processing Addendum restricts Google from accessing customer data except to deliver the services or as instructed by the customer, and personnel with infrastructure roles are subject to background checks and security reviews. Thus, the claim of unrestricted access under an infrastructure service agreement is false.

Google uses customer data to train its global AI models to improve services.

Why it fails: Google contractually commits in its Cloud Data Processing Addendum that it will not use customer data to train AI models, build advertising profiles, or market to customers. Customer data is owned by the customer, and Google processes it only as a data processor under the customer's instructions. Unless a customer explicitly opts into a separate, clearly labeled data-sharing program, the vast majority of Google Cloud customer data is excluded from model training. The claim that Google automatically uses customer data to train its global AI models is therefore incorrect.

Customer data stored in Google Cloud is automatically accessible by government agencies on request.

Why it fails: Government agencies cannot automatically access customer data stored in Google Cloud. Law enforcement and national security requests must be supported by appropriate legal process, such as a subpoena, court order, or warrant, and Google evaluates and often challenges overbroad requests. Google publishes a government transparency report detailing the number and scope of such requests, and customers may implement customer-managed encryption keys to further restrict access. Therefore, the data is not automatically accessible; legal and contractual safeguards apply.

Enable Cloud Armor on all load balancers to block non-EU traffic.

Why it fails: Cloud Armor is a web application firewall and DDoS protection service that filters incoming requests based on IP address, geo-location, or other attributes. It can block traffic from non-EU IP ranges, but it has no ability to influence where Google stores the data that the application processes or writes. Even if all client requests originate from the EU, the underlying compute and storage resources could still be provisioned in non-EU regions, so this does not enforce data residency.

Use HTTPS for all connections to ensure data is encrypted when it leaves the EU.

Why it fails: HTTPS encryption via TLS protects data in transit between the client and Google's edge, but it does not control where that data is ultimately stored or processed. Once the encrypted data reaches a GCP service, it can be persisted to a disk in any region, including outside the EU. Data residency requirements mandate the geographic location of data at rest, not just confidentiality during transmission, so HTTPS alone cannot satisfy this compliance need.

Enable Google Workspace's regional storage settings to restrict where emails are stored.

Why it fails: Google Workspace's regional storage settings only govern where Workspace application data such as Gmail messages and Drive files are stored; they have no effect on GCP infrastructure services like Compute Engine, Cloud Storage, or BigQuery. GCP data residency is enforced independently through per-service region selection and the gcp.resourceLocations org policy, not through Workspace admin console settings. Relying on Workspace settings would leave your GCP resources—which are often the actual systems of record—unconstrained to be created in any region.

SOC 2 Type II

Why it fails: SOC 2 Type II is an attestation report based on the AICPA Trust Services Criteria, evaluating the design and operating effectiveness of controls over security, availability, processing integrity, confidentiality, and privacy for a defined period. While Google Cloud undergoes SOC 2 Type II audits, it certifies control effectiveness for specific service commitments, not the formal certification of an information security management system (ISMS) as a whole. ISO/IEC 27001, by contrast, is the international standard that mandates a comprehensive, risk-based ISMS with explicit requirements for continuous improvement, making it the appropriate certification for the scenario.

PCI DSS

Why it fails: PCI DSS is a contractual industry standard created by the PCI Security Standards Council to protect cardholder data in payment card transactions. It applies specifically to organizations that store, process, or transmit cardholder data, and compliance is validated through self-assessment questionnaires or external QSA audits, not third-party certification of an ISMS. Its scope is narrowly focused on payment card security controls, unlike the comprehensive management-system certification provided by ISO/IEC 27001, which covers all information assets and risk management processes.

FedRAMP

Why it fails: FedRAMP is a U.S. federal government program that standardizes security assessment, authorization, and continuous monitoring for cloud products and services used by federal agencies. It is not an international ISMS certification; rather, it is a compliance authorization tailored to U.S. government risk tolerance and legal requirements such as FISMA. While FedRAMP includes many security controls, it does not certify the organization's overall information security management system to an international standard like ISO/IEC 27001 does.

VPN — employees connect to the corporate VPN which provides access to all apps.

Why it fails: A VPN establishes an encrypted tunnel between an employee's device and the corporate network, authenticating the device or user to the network gateway. That network-level access does not propagate to individual applications; each app still needs to know who the user is, so the user must authenticate separately to every service unless an SSO layer is also present. VPNs solve transport and perimeter access, not identity federation, so they do not eliminate per-application password prompts or enable a single authentication event to cover all apps.

Cloud Armor — blocks unauthorized access attempts to applications.

Why it fails: Cloud Armor is a distributed denial-of-service (DDoS) mitigation and web application firewall (WAF) service that protects applications at the edge by filtering traffic based on IP addresses, geographic regions, and configurable Layer 7 rules. It does not participate in authentication or identity federation; it cannot verify a user's identity or issue security assertions. While it can block a malicious request volume, it has no knowledge of a user's session or password, so it cannot provide single sign-on or remove the need for separate app credentials.

Shared service account — all employees use the same credential.

Why it fails: A shared service account means all employees authenticate with the same credentials—a single username and password. This destroys any individual audit trail, as the actions of every user become indistinguishable, and violates the principle of least privilege because every user gets the same access rights. It also does not achieve SSO; rather, it replaces many unique passwords with one shared password, and if that credential leaks, the entire organization is compromised without any way to know who exposed it.

Password complexity requirements — enforcing long, complex passwords.

Why it fails: Enforcing long, complex passwords increases the search space for brute-force attacks and slows down password guessing, but it remains a single knowledge factor. If a user's password is phished or lifted by a keylogger, complexity does nothing to stop reuse of that stolen credential. MFA adds a second independent factor that an attacker cannot obtain from the same breach.

IP allowlisting — only allowing access from office IP addresses.

Why it fails: IP allowlisting restricts access to traffic originating from approved network ranges, but network location is not a user attribute and can be shared, spoofed, or reached via VPN. It also breaks legitimate access for remote employees on non-approved networks. MFA verifies possession or inherence factors tied to the user, not the originating network address.

Session timeout — automatically logging out users after 30 minutes of inactivity.

Why it fails: A 30-minute session timeout is a session management control that terminates an authenticated session after inactivity, limiting the damage from an abandoned workstation. It does not verify the user's identity during login; an attacker with a valid password can still authenticate. MFA strengthens the initial authentication step rather than managing post-login session lifecycle.