Supporting compliance requirements · Topic 2 of 2
Assured Workloads, Access Transparency, Access Approval and Residency
Configure Assured Workloads, organization policies, Access Transparency, Access Approval and data regionalization for compliance on Google Cloud.
- 5 min
- Assured Workloads applies a control package to a folder: locations, services, keys and personnel.
- Organization policies enforce residency, allowed services, CMEK and no public data.
- Access Transparency logs Google staff access after it happens.
What it is
Some regulations care about more than your own configuration. They ask where data lives, which Google staff can touch it, and whether you can see and approve that access. Google Cloud answers with Assured Workloads, organization policies, Access Transparency, Access Approval and regional controls.
How it works
Assured Workloads
Assured Workloads creates a folder configured for a chosen control package. Regulatory packages include Data Boundary for FedRAMP Moderate or FedRAMP High, IL4, IL5, CJIS and ITAR, and US Data Boundary for Healthcare and Life Sciences for HIPAA workloads; regional packages include EU Data Boundary and EU Data Boundary and Support, and Sovereign Controls by Partners is a separate family. Projects in that folder inherit the controls.
| What it sets | Effect |
|---|---|
| Resource location restrictions | Resources only in regions allowed by the package |
| Service restrictions | Only services approved for the package can be used |
| Key requirements | CMEK where the package requires it |
| Personnel controls | Support from Google staff who meet the package's criteria, such as location or citizenship |
| Violation monitoring | Alerts when a change breaks the package's policies |
Choose Assured Workloads when a regime needs a combination of residency, service limits and personnel controls. Setting a few organization policies yourself does not give the personnel and support guarantees.
Organization policies for compliance
| Need | Constraint |
|---|---|
| Data residency | gcp.resourceLocations with values such as in:eu-locations |
| Only approved services | gcp.restrictServiceUsage |
| Customer-managed keys required | gcp.restrictNonCmekServices and gcp.restrictCmekCryptoKeyProjects |
| No external sharing | iam.allowedPolicyMemberDomains |
| No public data | storage.publicAccessPrevention, sql.restrictPublicIp |
| Confidential computing required | compute.restrictNonConfidentialComputing |
name: folders/987654321/policies/gcp.resourceLocations
spec:
rules:
- values:
allowedValues:
- in:eu-locationsAccess Transparency
Access Transparency produces logs of actions taken by Google personnel on your content, for example during a support case. Each entry records what was accessed, when, and the justification, such as a customer-initiated support request.
It is enabled for the organization, and the logs arrive in Cloud Logging next to your own audit logs. Route them through your aggregated sink so the SOC sees them.
Access Approval
Access Approval goes one step further: Google personnel must get your explicit approval before accessing content in supported services. You receive requests by email or Pub/Sub, then approve or dismiss them in the console or through the API.
| Feature | Access Transparency | Access Approval |
|---|---|---|
| When | After access happens | Before access happens |
| Your action | Review logs | Approve or dismiss each request |
| Coverage | Supported services | Supported services, with documented exceptions |
With Cloud EKM, Key Access Justifications adds a further check: each request to use your external key carries a reason, and your key manager policy can refuse it.
Regionalization of data and services
| Area | Control |
|---|---|
| New resources | gcp.resourceLocations on the organization or folder |
| Storage, BigQuery, Cloud SQL | Choose regional or allowed multi-regional locations at creation; changing location later usually means copying to a new resource |
| Logs | Set the default storage location for log buckets and keep sink destinations in the same region |
| Secrets and keys | User-managed replication for Secret Manager; KMS key rings in matching locations |
| Processing | Regional services and endpoints, and AI resources created in allowed regions |
| Backups and copies | Restrict backup and replication targets to allowed regions |
gcloud logging settings update --organization=123456789012 \
--storage-location=europe-west3Remember that global resources, such as some networking and IAM configuration, are not stored in one region. Check each service's data residency documentation before promising residency.
A worked example
A German public sector body requires EU-only data, EU-based Google support, customer-controlled keys, and visibility of any Google access. The engineer creates an Assured Workloads folder with the EU Data Boundary and Support control package, which sets location and service restrictions and EU-based support.
Within it, CMEK keys come from a key project in europe-west3, Access Transparency and Access Approval are enabled, and the logging default location is set to the same region. Access Transparency logs are routed to the SOC through the existing aggregated sink.
How the exam asks about this
- "A US government workload must meet FedRAMP High, with support only from qualified US personnel." Assured Workloads with the Data Boundary for FedRAMP High control package.
- "The company must approve any access by Google support staff to its data before it happens." Access Approval.
- "Security wants logs of every action Google personnel take on its content." Access Transparency.
What to remember for the exam
- Assured Workloads applies a control package to a folder: locations, services, keys and personnel.
- Organization policies enforce residency, allowed services, CMEK and no public data.
- Access Transparency logs Google staff access after it happens.
- Access Approval requires your approval before Google staff access content.
- Residency needs location policies plus correct choices for logs, backups, keys and secrets.
Data locations are hard to change after creation. A dataset or bucket in the wrong region usually has to be copied to a new resource, so set location policies before teams start building.
Common mistakes
Confusing Access Transparency and Access Approval. Transparency shows access afterwards; Approval blocks it until you approve.
Using only gcp.resourceLocations for a regulated government workload. It restricts locations but not personnel or services. Use Assured Workloads when the regime requires those.
Forgetting logs in residency designs. Log buckets and sinks also store data. Set their locations to match the rule.
Check yourself
What does Assured Workloads create, and what does it apply?
A folder with a control package that applies location and service restrictions, key requirements and personnel controls to projects inside it.
Which service makes Google staff wait for your approval before accessing content?
Access Approval, for supported services.
How do you keep new log buckets in one region across the organization?
Set the organization's default log storage location, for example with gcloud logging settings update.
Topic 2 of 2 in Supporting compliance requirements
Test yourself on Supporting compliance requirements
The full Google Cloud Professional Cloud Security Engineer question bank has 749 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Google Cloud. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.