This chapter covers Access Transparency and Access Approval, two critical controls for regulatory compliance and data sovereignty in Google Cloud. For the ACE exam, this topic appears in approximately 5-8% of questions, primarily in the Security Compliance domain (Objective 5.1). You must understand the difference between the two services, how they work together, configuration steps, and common exam scenarios. These services are often confused with Cloud Audit Logs or VPC Service Controls, so we will clarify the distinctions.
Jump to a section
Access Transparency and Access Approval work like a hotel safe deposit box system. The hotel (Google Cloud) provides a safe deposit box (your data) in a secure vault (Google's infrastructure). The hotel staff (Google engineers) have keys to the vault but not to individual boxes. Occasionally, they need to access a box for maintenance (e.g., applying a security patch to the server where your data resides). Under normal operations, the staff can open the vault and work around the boxes, but they cannot open any box without the guest's explicit permission. Access Transparency is like a log that records every time a staff member even touches the vault door or a box — including who, when, and why. This log is tamper-proof and available to the guest (you). Access Approval is like a policy that says, 'Before any staff member can open a specific box, they must send a request to the guest via a secure channel. The guest can approve or deny the request, and the request automatically expires after 15 minutes if not approved.' If the guest approves, the staff member gets a one-time code (access token) that works only for that specific box and only for a limited time (e.g., 1 hour). The guest can also set standing rules: 'Never allow access to Box 42' or 'Always allow access for critical security patches.' The hotel cannot override these rules. In the cloud, this means Google engineers cannot access your data without your consent (if enabled), and every attempt is logged immutably.
What Are Access Transparency and Access Approval?
Access Transparency and Access Approval are Google Cloud security features that provide customers with visibility and control over Google personnel's access to their data. They address a fundamental trust issue: even though Google encrypts data at rest and in transit, Google engineers may occasionally need to access customer data for troubleshooting, maintenance, or support. These services ensure that such access is logged (Access Transparency) and optionally requires explicit customer approval (Access Approval).
Access Transparency: Provides near real-time logs of actions performed by Google personnel on your resources. These logs are generated when Google engineers access your data or metadata for operational reasons (e.g., debugging a VM, applying a security patch). The logs include the identity of the Google employee, the resource accessed, the reason for access, and the time. They are stored in Cloud Logging and can be exported to BigQuery or Pub/Sub for analysis.
Access Approval: Adds a consent layer. When enabled, Google must receive explicit approval from an authorized customer administrator before any Google engineer can access your data or metadata. Approval requests are sent to a configured notification channel (e.g., email, Pub/Sub). The administrator can approve or deny each request, and the approval expires after a configurable time (default 1 hour, max 24 hours). Access Approval works in conjunction with Access Transparency: all approved accesses are logged.
How They Work Internally
When a Google engineer attempts to access a customer resource that has Access Approval enabled, the following sequence occurs:
The engineer's request is intercepted by the Access Approval service before it reaches the resource.
The service checks whether the resource has an active Access Approval policy. If yes, it generates an approval request.
The request is sent to the notification channels configured in the policy (e.g., email to a specific group, Pub/Sub topic).
An authorized administrator receives the request and can approve or deny it via the Google Cloud Console, gcloud, or API.
If approved, the Access Approval service generates a one-time access token that is valid for a limited time (default 1 hour, configurable up to 24 hours).
The engineer's request is then allowed to proceed, and the access is logged via Access Transparency.
If denied or not acted upon within the request timeout (default 15 minutes), the request is rejected, and the engineer cannot access the resource.
Access Transparency logs are generated regardless of whether Access Approval is enabled. They capture:
The Google identity (e.g., user@google.com)
The resource name (e.g., //compute.googleapis.com/projects/my-project/zones/us-central1-a/instances/my-vm)
The action (e.g., google.compute.instances.get)
The reason (e.g., CUSTOMER_INITIATED_SUPPORT or GOOGLE_INITIATED_SERVICE)
The timestamp
These logs are immutable and cannot be deleted by Google or the customer (they follow Google's data retention policies).
Key Components, Values, Defaults, and Timers
Access Approval Request Timeout: The time after which an unapproved request expires. Default is 15 minutes. Configurable via the request_timeout field (in seconds) when creating or updating an Access Approval policy.
Access Approval Token Validity: The duration for which an approved access token is valid. Default is 1 hour. Maximum is 24 hours. Configurable via the max_request_approval_duration field (in seconds).
Notification Channels: Can be email (to a Google Group or individual), Pub/Sub topic, or both. Email notifications are sent to the addresses configured in the channel.
Access Transparency Logs: Retained for 400 days by default (same as Cloud Logging's default retention for audit logs). Can be exported to BigQuery or Cloud Storage for longer retention.
Supported Services: Compute Engine, Google Kubernetes Engine, Cloud Storage, BigQuery, Cloud SQL, Cloud Spanner, and many others. Not all services are supported; check the official documentation for the current list.
IAM Permissions: To manage Access Approval, you need accessapproval.settings.update and accessapproval.settings.get. To approve/deny requests, you need accessapproval.requests.approve and accessapproval.requests.dismiss. These are typically granted through custom roles or the roles/accessapproval.approver role.
Configuration and Verification Commands
Enable Access Transparency (per project or organization):
Access Transparency is enabled at the organization level by default for eligible customers (Google Cloud's Assured Workloads customers). For other customers, it can be enabled via the console or API. There is no gcloud command to enable it; it is controlled by the accessTransparencySettings resource.
Enable Access Approval (per project or organization):
gcloud access-approval settings update \
--project=my-project \
--notification-emails=admin@example.com,ops@example.com \
--enrolled-services=allThis enables Access Approval for all supported services in the project. You can also specify individual services.
View Access Approval settings:
gcloud access-approval settings describe --project=my-projectList pending approval requests:
gcloud access-approval requests list --project=my-project --state=pendingApprove a request:
gcloud access-approval requests approve REQUEST_ID --project=my-projectDeny a request:
gcloud access-approval requests dismiss REQUEST_ID --project=my-projectView Access Transparency logs:
Access Transparency logs are stored in Cloud Logging under the log name cloudaudit.googleapis.com/access_transparency. You can view them in the Logs Explorer:
gcloud logging read "logName=projects/my-project/logs/cloudaudit.googleapis.com%2Faccess_transparency" --limit=10Interaction with Related Technologies
Cloud Audit Logs: Access Transparency logs are a separate type of audit log. They are not the same as Admin Activity or Data Access audit logs. Admin Activity logs record actions performed by customers (e.g., creating a VM), while Access Transparency logs record actions performed by Google. Both are immutable.
VPC Service Controls: VPC Service Controls prevent data exfiltration by restricting access to Google Cloud services from outside a VPC. Access Transparency and Access Approval do not replace VPC Service Controls; they complement them by controlling Google personnel access.
Organization Policies: You can use Organization Policies to enforce Access Approval across all projects in an organization. For example, you can define a constraint that requires Access Approval to be enabled for all projects.
Assured Workloads: Access Transparency is automatically enabled for Assured Workloads customers. Access Approval is optional but recommended for regulated workloads.
Common Pitfalls
Misunderstanding scope: Access Approval applies only to Google personnel accessing customer data for operational reasons. It does not affect customer-initiated operations or Google's automated systems (e.g., backup systems that do not involve human access).
Notification channel misconfiguration: If the notification email or Pub/Sub topic is misconfigured, approval requests may not be delivered, causing delays. Always test the notification channel.
Request timeout: If an administrator does not respond within the request timeout (default 15 minutes), the request is automatically denied. For time-sensitive support cases, this can cause delays. Adjust the timeout appropriately.
Token expiration: Approved tokens expire after the configured duration. If the Google engineer does not complete the work within that time, they must request a new approval.
Enable Access Transparency
Access Transparency must be enabled at the organization level. This is typically done by Google Cloud Support for eligible customers (e.g., Assured Workloads). Once enabled, all Google personnel access to customer resources is logged. The logs are sent to Cloud Logging under the log name `cloudaudit.googleapis.com/access_transparency`. You can verify by checking the organization's policy settings in the console or via the API. There is no gcloud command to enable it; it is a Google-managed feature.
Enable Access Approval
Use gcloud or the console to enable Access Approval for a project or organization. Specify notification channels (email addresses or Pub/Sub topics). The command `gcloud access-approval settings update --project=my-project --notification-emails=admin@example.com --enrolled-services=all` enables it for all supported services. You can also enable it for specific services like Compute Engine or BigQuery. After enabling, Access Approval will intercept any Google engineer access request to the enrolled resources.
Google Engineer Requests Access
A Google engineer initiates an access request to a customer resource (e.g., to debug a VM). The request is intercepted by the Access Approval service. The service checks if the resource has an active Access Approval policy. If yes, it generates a pending approval request with details: resource name, action, reason, and requesting engineer. The request is assigned a unique ID and timestamp. The request timeout (default 15 minutes) starts.
Notification Sent to Customer
The Access Approval service sends a notification to the configured channels. For email, it sends an email with a link to the Google Cloud Console where the request can be approved or denied. For Pub/Sub, a message is published to the topic. The customer's authorized administrator receives the notification. The administrator must have the `accessapproval.requests.approve` permission to act on the request. The request remains in 'pending' state until acted upon or timeout.
Administrator Approves or Denies
The administrator logs into the console or uses gcloud to approve or deny the request. If approved, the Access Approval service generates an access token valid for the configured duration (default 1 hour). The token is tied to the specific engineer and resource. The engineer's original request is then allowed to proceed. If denied or timeout, the request is rejected, and the engineer receives an error. All actions (approve/deny) are logged in Cloud Audit Logs.
Google Engineer Accesses Resource
With a valid access token, the Google engineer can access the resource. The access itself is logged via Access Transparency, capturing the engineer's identity, resource, action, and reason. The token is single-use and expires after the validity period. After the token expires, the engineer cannot access the resource again without a new approval request. The customer can review all access in the Access Transparency logs.
Enterprise Scenario 1: Financial Services Compliance
A large bank runs its core banking application on Google Cloud, subject to strict regulatory requirements (e.g., PCI DSS, SOX). The bank must ensure that any access to customer financial data by Google personnel is both logged and explicitly approved. They enable Access Transparency at the organization level and configure Access Approval for all projects containing sensitive data. They set up email notifications to a security operations group and use Pub/Sub to trigger a ticketing system. When a Google support engineer needs to investigate a performance issue, an approval request is sent. The security team reviews the request, verifies the reason, and approves it within the 15-minute timeout. All accesses are logged and later audited. A common issue is that the notification emails go to spam, so the bank whitelists the sender address and tests the flow quarterly.
Enterprise Scenario 2: Healthcare Data Sovereignty
A healthcare provider stores electronic health records (EHR) in Cloud Storage and BigQuery, subject to HIPAA. They need to ensure that no Google engineer can access patient data without explicit consent. They enable Access Approval with a 24-hour maximum token validity to allow for extended maintenance windows. They also set up a deny-all policy for non-critical services. However, they encounter a problem: during a critical security patch, the security team misses the notification because it was sent to a group mailbox that had a delay. They adjust the request timeout to 30 minutes and add SMS alerts via a third-party integration. They also create a standing approval for Google-initiated security patches by using the enrolled_services field to automatically approve requests with reason GOOGLE_INITIATED_SERVICE. This reduces operational friction while maintaining compliance.
Scenario 3: Multi-Org Governance
A multinational corporation has multiple Google Cloud organizations for different business units. They want a centralized governance policy where all Google personnel access to any project must be approved by a central security team. They use Organization Policies to enforce Access Approval across all projects. They configure a single notification channel (a shared email list) for all organizations. However, this creates a bottleneck: approval requests from different time zones pile up. They implement a custom solution using Cloud Functions to auto-approve low-risk requests (e.g., read-only access to non-production resources) and escalate high-risk requests to human approvers. The Access Transparency logs are exported to a central BigQuery dataset for cross-org auditing.
What the ACE Tests (Objective 5.1)
The ACE exam expects you to:
Distinguish between Access Transparency and Access Approval.
Know which services are supported (e.g., Compute Engine, Cloud Storage, BigQuery).
Understand the default timers: request timeout (15 minutes), token validity (1 hour).
Identify the correct IAM roles: roles/accessapproval.approver for approving requests.
Recognize that Access Transparency logs are separate from Admin Activity logs.
Understand that Access Approval is optional but Access Transparency is often mandatory for regulated workloads.
Common Wrong Answers and Traps
'Access Transparency logs can be deleted by the customer.' Reality: They are immutable and cannot be deleted by anyone, including Google.
'Access Approval requires no additional IAM roles.' Reality: Approving requests requires the accessapproval.requests.approve permission.
'Access Transparency logs show all actions by anyone, including customers.' Reality: They only show actions by Google personnel, not customer actions.
'Access Approval automatically approves requests if not acted upon.' Reality: Requests time out and are denied.
'Access Transparency and Access Approval are the same thing.' Reality: Transparency is logging; Approval adds a consent workflow.
Specific Numbers and Terms
Default request timeout: 15 minutes (900 seconds).
Default token validity: 1 hour (3600 seconds).
Maximum token validity: 24 hours (86400 seconds).
Log name: cloudaudit.googleapis.com/access_transparency.
IAM role: roles/accessapproval.approver.
Notification channels: email, Pub/Sub.
Edge Cases
Standing approvals: You can configure Access Approval to automatically approve certain types of requests (e.g., Google-initiated maintenance). This is done via the enrolled_services field with auto_approval_enabled flag.
Cross-project approval: Access Approval is per-project or per-organization. An approver in one project cannot approve requests for another project unless they have permissions in that project.
Service limits: There is a limit of 1000 pending requests per project. If exceeded, new requests are denied.
How to Eliminate Wrong Answers
If the question mentions 'logging Google personnel actions,' it's Access Transparency.
If it mentions 'requiring approval before access,' it's Access Approval.
If it mentions 'customer actions,' it's not related to either service.
If it mentions 'data exfiltration prevention,' think VPC Service Controls, not Access Approval.
Access Transparency logs Google personnel actions; Access Approval adds a consent layer.
Default request timeout for Access Approval is 15 minutes; default token validity is 1 hour.
Access Transparency logs are immutable and stored under log name `cloudaudit.googleapis.com/access_transparency`.
The IAM role `roles/accessapproval.approver` is required to approve or deny requests.
Access Approval supports only a subset of services; check documentation for the current list.
Access Transparency is automatically enabled for Assured Workloads customers.
Standing approvals can be configured using the `auto_approval_enabled` flag in the enrolled services.
These come up on the exam all the time. Here's how to tell them apart.
Access Transparency
Logs Google personnel access to customer data.
Always on when enabled; no customer action required.
Logs are immutable and stored in Cloud Logging.
Provides visibility but does not block access.
Retained for 400 days by default.
Access Approval
Requires customer approval before Google personnel access.
Customer must explicitly approve or deny each request.
Approval requests are sent via email or Pub/Sub.
Blocks access until approved; requests time out after 15 minutes.
Token valid for up to 24 hours after approval.
Mistake
Access Transparency logs all actions in the cloud, including customer actions.
Correct
Access Transparency logs only actions performed by Google personnel. Customer actions are logged in Admin Activity and Data Access audit logs, not Access Transparency.
Mistake
Access Approval allows customers to block all Google personnel access permanently.
Correct
Access Approval only adds a consent step; it does not allow customers to permanently block access. Customers can deny individual requests, but Google may still need access for critical operations (e.g., emergency security patches).
Mistake
Access Transparency logs can be disabled by the customer.
Correct
Once enabled at the organization level, Access Transparency cannot be disabled by the customer. It is a Google-managed feature for regulated workloads.
Mistake
Access Approval works with all Google Cloud services.
Correct
Access Approval supports only a subset of services. Check the documentation for the current list. Common supported services include Compute Engine, Cloud Storage, BigQuery, and Cloud SQL.
Mistake
The default request timeout for Access Approval is 1 hour.
Correct
The default request timeout is 15 minutes. The default token validity is 1 hour. These are different timers.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Access Transparency logs all actions performed by Google personnel on your resources. Access Approval adds a workflow where you must explicitly approve each access request before it can proceed. Transparency is logging only; Approval is a consent mechanism. Both are used together for compliance.
No. Once enabled at the organization level (typically for Assured Workloads customers), Access Transparency cannot be disabled. It is a Google-managed feature to provide visibility into Google personnel access.
The request times out after the configured timeout (default 15 minutes) and is automatically denied. The Google engineer will not be able to access the resource until a new request is submitted and approved.
To manage settings, you need `accessapproval.settings.update` and `accessapproval.settings.get`. To approve/deny requests, you need `accessapproval.requests.approve` and `accessapproval.requests.dismiss`. The predefined role `roles/accessapproval.approver` includes these permissions.
Yes, Cloud Storage is one of the supported services. However, not all Cloud Storage operations may be covered. Check the official documentation for the exact list of supported actions.
Yes. You can configure `auto_approval_enabled` for specific enrolled services. For example, you can automatically approve Google-initiated maintenance requests while requiring manual approval for support requests.
By default, Access Transparency logs are retained for 400 days, consistent with Cloud Logging's default retention for audit logs. You can export them to BigQuery or Cloud Storage for longer retention.
You've just covered Access Transparency and Access Approval — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?