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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: The compute.instanceAdmin role includes compute.instances.delete permission, which would allow developers to delete instances.

Cloud Data Loss Prevention (DLP)

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

Encryption of data at rest by default

Why wrong: Google encrypts data at rest by default; customer can opt for additional controls.

Network infrastructure maintenance

Why wrong: Google maintains the underlying network infrastructure.

Physical security of data centers

Why wrong: This is Google's responsibility.

Access is allowed only to resources tagged with 'production'.

Why wrong: Resource tags, such as 'production', are represented in IAM conditions through attributes like `resource.labels` or `resource.name`. This policy's condition does not reference any `resource.*` attribute, so it cannot limit access to resources carrying a 'production' tag; it only restricts the caller's network location.

Access is allowed only with two-factor authentication.

Why wrong: Requiring two-factor authentication would be expressed with IAM condition attributes like `request.auth.claims` or `gcp.auth` (e.g., checking `request.auth.claims.nonexpiring` or `gcp.auth.level`). No such authentication-related attribute appears in the condition, so the policy cannot enforce MFA; it only checks the source IP address.

Access is allowed only during business hours.

Why wrong: Restricting access to business hours would require a temporal condition using `request.time` (or `resource.creation_time`), such as comparing the current time against a fixed window. Since this condition contains no `request.time` predicate, it does not limit access by time of day; the sole determining factor is the requester's IP address.

The project has reached its compute instance quota.

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

The user updated the IAM policy on the bucket.

Why wrong: The method is not setIamPolicy.

The user attempted to delete the object 'secret.pdf'.

Why wrong: The method is 'storage.objects.get', not delete.

The user successfully read the object 'secret.pdf'.

Why wrong: The log has severity ERROR, indicating the operation failed.

Network vulnerability scanning

Why wrong: Network vulnerability scanning is an infrastructure security concern that involves probing services, ports, and system configurations for exploitable weaknesses. This is not a feature of Cloud DLP, which is scoped to content inspection and de-identification of data rather than network-level threat detection. On Google Cloud, such scanning is typically performed by Cloud Security Scanner for App Engine or by third-party vulnerability management tools, and DLP does not interact with network stacks.

Removal of malware from uploaded files

Why wrong: Cloud DLP does not execute files or analyze binary signatures to detect malware, as that falls into antivirus or endpoint detection and response (EDR) product categories. Its inspection engine is designed to parse text, structured data, and common file formats (like PDFs and spreadsheets) for sensitive data patterns, not malicious code. Malware removal would require a separate solution, such as VirusTotal, Chronicle, or a custom file scanning pipeline, none of which are part of Cloud DLP's core functionality.

Creation of IAM policies

Why wrong: Cloud DLP is a consumer of IAM policies but does not create them. IAM policy creation is handled by Cloud IAM, where administrators define principals, roles, and condition bindings that control access to resources like projects, buckets, and datasets. While Cloud DLP requires IAM permissions to access data and invoke services, it cannot author or modify IAM policies; its role is to inspect and protect data content, not to manage resource-level access control.

Use the same SSH key for all Compute Engine instances.

Why wrong: Sharing a single SSH key across all Compute Engine instances collapses access management into one point of failure; if the private key is exfiltrated, every instance is compromised. It also prevents per-user accountability, since use of the shared key cannot be traced to an individual person, and forces a blanket rotation for all instances even if only one user leaves. Best practice is to use unique keys per user or integrate with OS Login / Cloud IAP to provide identity-based access.

Export service account keys and use them in on-premises applications for authentication.

Why wrong: Exporting service account keys converts a managed cloud identity into a static, long-lived secret that remains valid until manually rotated. Distributing that key to on-premises systems expands the trust boundary far beyond GCP, making it difficult to control access or revoke privileges if the external environment is breached. Google recommends avoiding the creation and export of service account keys entirely, and instead using workload identity federation or short-lived OAuth tokens to authenticate on-premises workloads.

Rotate service account keys every month.

Why wrong: Monthly key rotation is not a universal or sufficient security practice; the real risk is the existence of long-lived static keys, regardless of how frequently they are replaced. A rotated key may still have been leaked, and rotation only protects against future misuse—it does not detect or neutralize an active compromise. Modern GCP best practice is to avoid the use of service account keys altogether by leveraging workload identity federation or auto-rotated, short-lived credentials, which eliminate the need for manual rotation schedules.

Immediately revoke all service account keys and reissue them, then reset all user passwords.

Why wrong: This is a reactive security measure but not a investigation step; it may be taken after analysis.

Enable Cloud IDS to detect similar attacks and block the malicious IP address.

Why wrong: Cloud IDS is for real-time network detection, not historical investigation of storage access.

Export VPC Flow Logs to BigQuery and analyze for the attacker's IP address.

Why wrong: VPC Flow Logs show network flows but do not include user identity or API-level access to Cloud Storage.

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

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