Trust and security with Google Cloud practice questions

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

Why wrong: Encryption is automatic and requires no configuration. There is no 'enable encryption' setting in Cloud Storage — all data is encrypted by default.

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

Why wrong: Encryption is applied to all storage tiers equally — Standard, Nearline, Coldline, and Archive are all encrypted by default.

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

Why wrong: Security Command Center is a security monitoring service; it doesn't control data encryption. Encryption is automatic and included in the base service at no additional charge.

Perimeter security model

Why wrong: Perimeter security (castle and moat) trusts everything inside the network perimeter. Zero Trust is the opposite — it distrusts all requests regardless of network location.

Defense in depth model

Why wrong: Defense in depth uses multiple security layers. While complementary to Zero Trust, it doesn't specifically describe the 'verify every request regardless of network location' principle.

Principle of least privilege

Why wrong: Least privilege grants only the minimum permissions needed — an important security principle but not the same as Zero Trust's 'always verify regardless of network location' approach.

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

Why wrong: Access control (who can connect to the database, with what permissions) is always the customer's responsibility. Google never controls customer data access policies.

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

Why wrong: While Cloud SQL offers managed backups (which Google operates), enabling and managing backup policies is a customer responsibility. Google provides the capability; customers configure it.

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

Why wrong: Compliance requirements are determined by the customer's industry and regulatory environment. Google provides compliance certifications for its infrastructure; customers are responsible for their application-level compliance.

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

Why wrong: HIPAA compliance is not automatic. Using Google Cloud's HIPAA-eligible services plus signing a BAA provides the foundation, but customers must implement their own administrative, technical, and physical safeguards.

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

Why wrong: HIPAA explicitly allows use of cloud services with appropriate BAAs and technical safeguards. Many healthcare organizations successfully operate HIPAA-compliant workloads on Google Cloud.

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

Why wrong: Encryption at rest and in transit addresses specific HIPAA technical safeguards but HIPAA has many additional requirements: access controls, audit controls, integrity controls, and transmission security — all requiring customer configuration.

`roles/bigquery.admin`

Why wrong: BigQuery Admin grants full control including dataset creation, deletion, and IAM management — far more than the data engineer needs and a violation of least privilege.

`roles/viewer` (project-level Viewer)

Why wrong: Project-level Viewer grants read access to all resources in the project — broader than just BigQuery access. Least privilege means scoping to only the needed service.

`roles/bigquery.dataEditor`

Why wrong: dataEditor grants read AND write access to data within datasets (insert, update, delete table data). This exceeds the requirement — the engineer should only have read access.

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

Why wrong: SCC provides security findings about GCP configuration misconfigurations and threats. Sensitive data classification is done by Cloud DLP, which integrates with SCC as a finding source.

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

Why wrong: Cloud Monitoring tracks metrics, not data content. Custom SQL queries could detect some patterns but can't scale to the comprehensive sensitive data detection that DLP provides.

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

Why wrong: Audit logs record who accessed what when, but don't classify data content or automatically identify where sensitive data lives in BigQuery tables.

It prevents unauthorized users from accessing the Google Cloud Console.

Why wrong: HTTPS encrypts data in transit between browser and server. Console access is controlled by IAM authentication, not by HTTPS on the application.

It encrypts data stored in the server's database.

Why wrong: HTTPS only protects data in transit. Database encryption (at rest) is a separate mechanism handled by Google Cloud's automatic encryption of stored data.

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

Why wrong: TLS/HTTPS establishes an encrypted channel and authenticates the SERVER (via certificate), but does not authenticate the user. User authentication requires credentials (password, SSO, etc.).

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

Why wrong: Regional service availability is documented in Google Cloud's documentation, not in Access Transparency. Access Transparency specifically logs Google personnel access to customer content.

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

Why wrong: This is the opposite of Access Transparency's purpose. It exists to make Google's access to customer data visible to customers, not to make customer data visible to Google.

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

Why wrong: Security vulnerability dashboards are provided by Security Command Center. Access Transparency is specifically about logging Google staff's access to customer content.

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

Why wrong: Google explicitly limits and logs personnel access to customer data. Access is tightly controlled, needs business justification, and is logged in Access Transparency.

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

Why wrong: Google contractually commits that it does not use customer data to train AI models or for advertising. Customer data belongs to the customer.

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

Why wrong: Government access requires legal process (court orders, etc.). Google has a government transparency report and commits to challenging overbroad requests. Data is not 'automatically accessible' by governments.

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

Why wrong: Cloud Armor controls which IP addresses can send requests TO the application — it doesn't control where data is stored or processed. It doesn't enforce data residency.

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

Why wrong: HTTPS encrypts data in transit but doesn't prevent data from being stored or processed outside the EU. Data residency requires choosing EU regions, not just encryption.

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

Why wrong: Google Workspace regional storage applies to Workspace data (emails, Drive files). GCP infrastructure data residency is controlled separately through region selection and org policies.

SOC 2 Type II

Why wrong: SOC 2 (System and Organization Controls 2) reports on controls relevant to security, availability, processing integrity, confidentiality, and privacy — specifically for service organizations. It's a different standard from ISO 27001 ISMS.

PCI DSS

Why wrong: PCI DSS (Payment Card Industry Data Security Standard) is specific to organizations handling credit card data. It's an industry standard for payment security, not a general ISMS certification.

FedRAMP

Why wrong: FedRAMP (Federal Risk and Authorization Management Program) is a US government authorization for cloud services used by federal agencies. It's US-government-specific, not an international ISMS certification.

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

Why wrong: VPN provides network access, not authentication federation. VPN doesn't enable single sign-on or eliminate app-specific passwords.

Cloud Armor — blocks unauthorized access attempts to applications.

Why wrong: Cloud Armor is a security service for blocking malicious traffic. SSO and identity federation are handled by Google Workspace and authentication protocols, not Cloud Armor.

Shared service account — all employees use the same credential.

Why wrong: Shared credentials eliminate individual accountability and auditability. SSO provides each user with their own authenticated session through their personal Google identity.

Password complexity requirements — enforcing long, complex passwords.

Why wrong: Strong passwords improve security but are still a single factor. Multi-factor authentication adds a second independent factor (something you have or are) that is much more resistant to compromise.

IP allowlisting — only allowing access from office IP addresses.

Why wrong: IP allowlisting restricts access by network location. It doesn't verify user identity beyond the network they're on, and blocks legitimate remote access from trusted employees.

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

Why wrong: Session timeout limits exposure from unattended sessions but doesn't verify identity at login. MFA is an authentication mechanism, not a session management policy.

Biometric authentication and badge access controls at multiple security perimeters.

Why wrong: Biometric access (iris, fingerprint) combined with electronic badges is a real Google data center physical security measure — this is a genuine protection layer.

24/7 on-site security personnel who monitor the facility continuously.

Why wrong: Continuous on-site security personnel are a real Google data center physical security measure.

Secure hardware destruction procedures for decommissioned storage devices.

Why wrong: Google uses approved methods for destroying storage media containing customer data (degaussing, shredding) — this is a real practice.

Data Access audit logs — they capture all read and write operations.

Why wrong: Data Access audit logs capture API calls that read/write user data. They are NOT always-on by default (they must be explicitly enabled and can be very high volume). Admin Activity logs capture administrative changes.

System Event audit logs — they capture all Google Cloud operations.

Why wrong: System Event audit logs capture automated GCP actions (e.g., auto-scaling events) initiated by Google, not user/admin actions. They don't cover user administrative activities.

Cloud Monitoring logs — they track all changes to monitored resources.

Why wrong: Cloud Monitoring tracks metrics (performance data), not administrative audit events. Audit logging is in Cloud Logging's audit logs feature.

Cloud Armor — it inspects device fingerprints on incoming requests.

Why wrong: Cloud Armor is a WAF/DDoS service that inspects HTTP request attributes (IPs, headers, content). It doesn't perform device trust/posture evaluation for access decisions.

Cloud Firewall rules that allow only corporate office IP ranges.

Why wrong: IP-based rules block non-office IP addresses but don't evaluate device trust. An attacker from the office would bypass this, and legitimate remote employees would be blocked.

Two-step verification — the second factor proves the device is trusted.

Why wrong: 2SV proves the user has a second factor (phone, security key) but doesn't verify that the device they're working on is managed and compliant. A FIDO key can be used on any device.

Google transfers customer data to new hardware first, then ships the old hardware to the customer for self-destruction.

Why wrong: Google never ships used hardware to customers. Google is responsible for secure destruction of decommissioned hardware within its facilities.

Customer data on decommissioned hardware is automatically encrypted, making it safe to discard without wiping.

Why wrong: While encryption at rest protects data while the hardware is in use, decommissioned hardware goes through explicit destruction procedures — encryption alone isn't the only safeguard.

Customers must pay a data destruction fee to ensure their data is wiped from decommissioned hardware.

Why wrong: Google includes secure hardware disposition in its standard operations — no additional customer payment or action is required.

Selecting EU regions for all resources in the Cloud Console.

Why wrong: Region selection keeps data at rest in EU regions but doesn't restrict Google operations personnel access or provide contractual sovereignty guarantees beyond standard terms.

VPC Service Controls — they prevent data from leaving the VPC boundary.

Why wrong: VPC Service Controls prevent data exfiltration between GCP services/projects. They don't restrict Google operations personnel access or provide the contractual sovereignty guarantees required.

Cloud Armor — it blocks requests originating from outside the EU.

Why wrong: Cloud Armor can restrict traffic sources to EU IP ranges but doesn't address data storage location, Google personnel access restrictions, or data sovereignty contractual requirements.

Cloud Monitoring — it detects security anomalies through metric analysis.

Why wrong: Cloud Monitoring tracks performance metrics and can alert on anomalies, but it's not a security posture management platform. It doesn't discover misconfigurations or scan for vulnerabilities.

Cloud Audit Logs — they show all API calls that could indicate security issues.

Why wrong: Audit logs capture what happened but require manual analysis to identify security issues. SCC automatically analyzes configurations and behaviors to surface security findings.

Cloud DLP — it scans all resources for sensitive data exposure.

Why wrong: Cloud DLP scans data content for sensitive information (PII, credentials in data). SCC addresses infrastructure security posture — misconfigurations, vulnerabilities, and threats across the entire org.

Google has no obligation to notify customers of data breaches — customers must discover breaches themselves.

Why wrong: Google's Cloud DPA includes contractual breach notification commitments. In regulated jurisdictions (GDPR), these are legally required within specific timeframes.

Google will notify all media outlets immediately upon breach detection to maximize transparency.

Why wrong: Google notifies affected customers (not media) through proper channels. Media notification for specific customer breaches would violate customer privacy and is not the appropriate process.

Breach notification is only available to customers with Premium support tier.

Why wrong: Breach notification is a contractual commitment in the Cloud DPA available to all Google Cloud customers, not a support tier feature.