Free Google Cloud Professional Cloud Architect Practice Questions: Security and Compliance
Practice 10 free Google Cloud Professional Cloud Architect questions on Security and Compliance, with answers, explanations, and the IT Mastery next step.
Try the IT Mastery web app for a richer interactive practice experience with mixed sets, timed mocks, topic drills, explanations, and progress tracking.
Topic snapshot
| Field | Detail |
|---|---|
| Exam route | Google Cloud Professional Cloud Architect |
| Topic area | Designing for Security and Compliance |
| Blueprint weight | 19% |
| Page purpose | Focused sample questions before returning to mixed practice |
How to use this topic drill
Use this page to isolate Designing for Security and Compliance for Google Cloud Professional Cloud Architect. Work through the 10 questions first, then review the explanations and return to mixed practice in IT Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 19% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
Sample questions
These are original IT Mastery practice questions aligned to this topic area. They are not official exam questions, copied live-exam content, or exam dumps. Use them for self-assessment, scope review, and deciding what to drill next.
Question 1
Topic: Designing for Security and Compliance
A retail company lets a partner contractor deploy a production Cloud Run service from the partner’s CI system. A security review finds the following access pattern.
Exhibit: Access finding
Principal used: partner-deploy@prod.iam.gserviceaccount.com
Current grant: roles/editor on the production project
Credential: user-managed JSON key stored in partner CI
External identity source: partner OIDC-capable CI runner
Requirement: deploy only the prod-api Cloud Run service
What is the best access-control correction?
Options:
A. Create Google user accounts for partner engineers and grant project Editor
B. Use Workload Identity Federation and service account impersonation with least privilege
C. Require Cloud VPN before allowing the same service account key
D. Rotate the JSON key and restrict partner access by source IP
Best answer: B
Explanation: For an external CI system, the durable correction is Workload Identity Federation, not a stored service account key. The partner’s OIDC identity can be trusted through a workload identity pool, allowed to impersonate a deployment service account, and granted only the permissions needed to deploy the specific Cloud Run workload. This addresses both risks visible in the exhibit: a long-lived credential outside Google Cloud and an overly broad project-level Editor role. Network controls such as VPN or IP restrictions may reduce exposure, but they do not fix identity, key-management, or least-privilege problems.
- Key rotation only leaves a reusable secret in the partner CI system and does not reduce the project-level Editor grant.
- User accounts for engineers are not the right identity model for an automated external workload and would preserve excessive privilege.
- VPN access can protect network paths, but it does not replace long-lived service account keys or narrow IAM permissions.
Question 2
Topic: Designing for Security and Compliance
A company is designing its initial Google Cloud hierarchy. Which resource hierarchy should the architect recommend?
Exhibit: Governance excerpt
| Requirement | Detail |
|---|---|
| Central governance | Security owns baseline org policies and audit logging for all resources. |
| Delegated administration | Each division needs one inherited boundary to manage only its own cloud workloads. |
| Environment controls | Production requires stricter policies than development/test. |
| Workload isolation | Each application environment needs separate quota, billing, and lifecycle control. |
Options:
A. Separate organizations for each division with duplicated policies
B. Organization, environment folders, shared division projects
C. Organization, one platform folder, labels for divisions and environments
D. Organization, division folders, environment subfolders, application-environment projects
Best answer: D
Explanation: The hierarchy should place the organization at the top for central governance, then use folders for inherited policy and delegated administration boundaries. Because the exhibit says each division needs one inherited boundary to manage only its own workloads, division folders are the right first-level folder design. Environment subfolders under each division let security apply stricter production controls while preserving the division boundary. Separate projects per application environment provide cleaner IAM scope, quota tracking, billing attribution, and lifecycle management than shared projects or labels. The key takeaway is to design folders around where policies and administration must inherit, and use projects as the main workload isolation unit.
- Environment-first folders make production policy inheritance easy but do not provide the requested single inherited division administration boundary.
- Labels-only separation helps reporting but does not enforce IAM, organization policies, quotas, or lifecycle boundaries.
- Separate organizations add governance duplication and reduce central visibility when one organization can satisfy the stated requirements.
Question 3
Topic: Designing for Security and Compliance
A healthcare company stores regulated patient data in BigQuery and Cloud Storage in two production projects. Analysts and a Vertex AI workflow in separate approved projects must continue using the data, but security is concerned that compromised credentials could copy data to an unmanaged Google Cloud project. The company wants minimal latency impact, no data relocation, and low operational disruption. Which recommendation best balances these requirements?
Options:
A. Apply a targeted VPC Service Controls perimeter with approved ingress and egress policies
B. Encrypt the datasets with CMEK and scan them with Sensitive Data Protection
C. Block all internet egress from analyst VPCs with firewall rules
D. Move all regulated data into a new isolated project with no external access
Best answer: A
Explanation: VPC Service Controls is designed to reduce data exfiltration risk for supported Google Cloud services by creating a service perimeter around projects that contain sensitive resources and the projects that are allowed to process them. In this scenario, the best fit is a scoped perimeter protecting BigQuery, Cloud Storage, and the approved Vertex AI access path, with explicit ingress and egress rules for required workflows. This avoids relocating data, adds little latency, and limits disruption compared with an organization-wide lockdown. VPC Service Controls complements IAM, encryption, and monitoring; it does not replace them.
- Firewall-only control misses API-based access to Google Cloud services from outside the VPC and does not create a service perimeter.
- Full isolation may reduce risk but violates the need for analysts and Vertex AI workflows to keep operating with low disruption.
- Encryption and scanning improve confidentiality and classification, but they do not prevent copying data to an unmanaged project.
Question 4
Topic: Designing for Security and Compliance
A healthcare company is reviewing a proposed Gemini-based clinical assistant on Google Cloud. The compliance team asks whether the design satisfies its AI privacy, sovereignty, ownership, and evidence requirements.
Exhibit: Design review excerpt
| Requirement | Proposed design |
|---|---|
| PHI, prompts, responses, and AI audit evidence must remain in EU regions. | Cloud Run is in europe-west4; Gemini is called through a global Vertex AI endpoint; prompt/response logs are exported to a US multi-region Cloud Storage bucket. |
| The company retains ownership; shared foundation models must not be trained on its content. | An enterprise Vertex AI service is approved by legal for data-use terms. |
| PHI must be inspected before model input; unsafe output must be blocked. | Model Armor is applied only to generated responses; Cloud Audit Logs are enabled. |
Which interpretation is best?
Options:
A. Nonviable: regulated AI must use a self-hosted model.
B. Compliant: Vertex AI ownership terms and audit logs are sufficient.
C. Compliant if CMEK uses an EU Cloud KMS key.
D. Noncompliant: AI processing, logs, and screening need redesign.
Best answer: D
Explanation: Data sovereignty and privacy requirements apply to every place sensitive AI data flows, including prompts, responses, logs, and audit evidence. The proposed design has an approved enterprise service for ownership and model-training terms, but that does not satisfy the EU-only residency requirement when inference uses a global endpoint and prompt/response logs are stored in a US multi-region bucket. Model Armor is also applied too late to meet the requirement to inspect PHI before model input. A compliant redesign would use approved regional AI endpoints and EU-located storage/log sinks, plus pre-input inspection and output controls. Encryption and audit logging support compliance, but they do not replace location, data-use, and AI safety controls.
- Ownership-only view misses that approved data-use terms do not fix global processing, US log export, or pre-input PHI screening.
- CMEK-only view confuses encryption control with residency; EU keys do not guarantee EU-only processing or storage.
- Self-host-only view is too restrictive; managed Vertex AI can be acceptable when configured and governed to meet the stated requirements.
Question 5
Topic: Designing for Security and Compliance
A healthcare analytics team is moving a document archive and reporting database to Google Cloud. The team prefers one shared landing zone unless the classification policy requires different controls.
Exhibit: Data classification policy
| Class | Examples | Required controls |
|---|---|---|
| Internal | runbooks, release notes | team IAM, standard retention |
| Confidential | customer contact data | least-privilege IAM, CMEK, 7-year retention |
| Regulated | PHI, payment evidence | separate admin boundary, CMEK, immutable 10-year retention, Data Access audit logs |
The proposed design uses one Cloud Storage bucket and one BigQuery dataset in a shared analytics project with Google-managed encryption, one analyst group, and 30-day audit log retention for all classes. What is the best next design action?
Options:
A. Apply regulated retention to all data in the shared project.
B. Use default encryption and focus classification on access reviews.
C. Create separate storage and datasets per class with matching controls.
D. Keep the shared design and record classification with labels.
Best answer: C
Explanation: Data classification is a control driver, not just descriptive metadata. The proposed shared landing zone mixes classes and applies controls that fail the visible policy: Google-managed encryption instead of CMEK, one broad analyst group, 30-day audit log retention, and no separate admin boundary for regulated data. A better design separates data stores by classification, such as distinct buckets, BigQuery datasets, projects, or perimeters when needed, and then applies the required IAM model, Cloud KMS keys, retention settings, and Data Access audit logging to each class. Labels and catalog tags can help discovery and governance, but they do not enforce encryption, retention, or access controls by themselves.
- Labels only identify classification but do not enforce CMEK, IAM boundaries, retention, or audit logging.
- Default encryption protects data at rest, but the policy explicitly requires CMEK for higher classes.
- Blanket retention still leaves shared access, admin boundary, encryption, and audit requirements unresolved.
Question 6
Topic: Designing for Security and Compliance
A healthcare analytics company is moving PHI datasets to BigQuery and Cloud Storage. Its regulator requires encryption keys for PHI to be generated and held in the company’s existing HSM environment, not stored in Google Cloud. The security team also needs centralized audit evidence of key use and the ability to suspend decryption for selected datasets during an incident, with minimal application changes.
Which encryption and key-management design best satisfies these requirements?
Options:
A. Use Cloud KMS software keys as CMEK for all datasets
B. Use Cloud EKM-backed Cloud KMS keys as CMEK for the datasets
C. Use Google-owned and Google-managed encryption keys for all storage
D. Encrypt all records in application code before writing data
Best answer: B
Explanation: The core decision is whether the key material can remain outside Google Cloud while still integrating with managed services. Cloud External Key Manager (Cloud EKM) lets Cloud KMS reference externally held keys, such as keys backed by an approved external HSM or key manager. When used as CMEK for supported services like BigQuery and Cloud Storage, the services can encrypt data without the application handling encryption directly. The security team can control external key availability, collect audit evidence, and suspend decrypt operations for affected datasets without deleting the encrypted data.
Cloud KMS software or HSM keys can satisfy many CMEK controls, but the key material is still managed within Google Cloud. Client-side encryption keeps keys external, but it adds application changes and can reduce managed analytics functionality.
- Default encryption fails because Google-managed keys do not satisfy the requirement for company-held key material.
- Cloud KMS software keys provide CMEK, rotation, and audit controls, but the keys are stored and managed in Google Cloud.
- Application encryption may keep keys outside Google Cloud, but it does not meet the minimal-change requirement for managed BigQuery and Cloud Storage workflows.
Question 7
Topic: Designing for Security and Compliance
A company deploys Cloud Run services and Terraform-managed infrastructure from GitHub Actions. A compliance audit finds service account keys stored as CI secrets, container images pulled by floating tags from public registries, and Terraform modules referenced by branch name. The company must reduce supply-chain risk within 6 weeks, keep weekly releases, and avoid a platform rewrite. What is the best balanced recommendation?
Options:
A. Pause releases until all application and Terraform dependencies are manually approved.
B. Harden the current pipeline with keyless identity, pinned dependencies, provenance, and phased enforcement.
C. Migrate the services to GKE and standardize all deployments on Kubernetes manifests.
D. Move all builds to private workers and restrict VPC egress only.
Best answer: B
Explanation: The highest-priority supply-chain risks are the long-lived CI credentials, mutable dependencies, and unverified build artifacts. A balanced Google Cloud recommendation is to keep the existing workflow but replace service account keys with Workload Identity Federation, pin container and Terraform dependencies to immutable versions or digests, build and store trusted artifacts in Artifact Registry, and use provenance or attestations with progressive policy enforcement. This improves compliance evidence and reduces tampering risk without stopping weekly releases or forcing a large platform migration. Phasing enforcement, for example audit mode before blocking, also matches a small platform team’s readiness.
- Manual approval freeze maximizes caution but violates the weekly-release constraint and creates high operational load.
- Private build networking can reduce exposure but does not fix leaked keys, floating tags, or untrusted artifact provenance.
- Platform migration may help future standardization but is too large for 6 weeks and does not directly address the identified supply-chain gaps.
Question 8
Topic: Designing for Security and Compliance
An architect is reviewing an identity design for a migration to Google Cloud. The security team requires least privilege, per-principal auditability, and no long-lived service account keys.
Exhibit: Access sources
| Access need | Source identity | Constraint |
|---|---|---|
| Project administration | Employees in Google Workspace | Use existing Google groups |
| Deploy Cloud Run | GitHub Actions OIDC token | No stored keys |
| Read audit logs | Partner users in SAML IdP | No Google accounts |
Which design implication best follows from the exhibit?
Options:
A. Map employees to IAM groups, GitHub to service account keys, and auditors to shared service accounts.
B. Map employees to Workload Identity Federation, GitHub to Workload Identity Federation, and auditors to Workload Identity Federation.
C. Map employees to IAM groups, GitHub to Workload Identity Federation, and auditors to Workforce Identity Federation.
D. Map employees to IAM groups, GitHub to Workforce Identity Federation, and auditors to Workforce Identity Federation.
Best answer: C
Explanation: The decisive distinction is the principal type. Employees in Google Workspace are human Google identities, so grant access through IAM roles assigned to Google groups. GitHub Actions is a non-human external workload, so use Workload Identity Federation to exchange its OIDC token for Google credentials, typically by impersonating a deployment service account. Partner auditors are external human users from a SAML IdP, so Workforce Identity Federation provides IAM access without provisioning Google accounts while preserving per-user auditability. Service account keys and shared accounts fail the stated key and auditability requirements. Choose the identity pattern based on whether the caller is a human user, a workload, or an external workforce identity.
- Workforce for GitHub confuses a CI/CD workload with external human workforce identities.
- Service account keys violate the no-long-lived-keys constraint and do not provide per-user auditability for auditors.
- Workload for humans treats administrators or auditors as non-human workloads instead of IAM human principals.
Question 9
Topic: Designing for Security and Compliance
A healthcare SaaS company is classifying data before migrating to Google Cloud. The application currently uses a relational database for transactions, and the team has limited capacity for a data-model rewrite this quarter. Compliance requires reviewable audit evidence for restricted data access.
| Class | Examples | Requirements |
|---|---|---|
| Public | images, help docs | low cost, high read |
| Internal | service logs | 90-day retention, SRE access |
| Restricted | patient IDs, invoices | low-latency transactions, 7-year retention, least privilege, customer-managed keys |
Which recommendation best balances security, compliance, cost, latency, and operational effort?
Options:
A. Store restricted records as archived Cloud Storage objects with signed URLs, Object Versioning, and 7-year retention to minimize database and compute cost.
B. Consolidate the classes into BigQuery, use broad project-level viewer access for developers, and retain everything for 7 years to simplify governance.
C. Tier services and controls by classification, using managed storage for public data, log analytics for internal data, and a CMEK-protected relational database with restricted IAM, retention, and audit logs for restricted data.
D. Apply the restricted-data controls to every class, using CMEK, 7-year retention, Data Access audit logs, and manual approvals for all datasets and objects.
Best answer: C
Explanation: Data classification should drive where data is stored, who can access it, how it is encrypted, how long it is retained, and what audit evidence is captured. Public content can use low-cost Cloud Storage patterns with standard controls. Internal logs fit Cloud Logging or BigQuery with scoped SRE access and a 90-day retention setting. Restricted transactional records need the strongest controls: a managed relational database to preserve latency and reduce rewrite effort, CMEK through Cloud KMS, least-privilege service accounts or groups, 7-year retention through backups or retention processes, and database plus Cloud Audit Logs evidence. Applying the same heavy controls to every class increases cost and operational burden without improving the required risk posture.
- Over-controlling all data adds retention cost, key-management work, and audit noise for public and internal data without a stated compliance need.
- BigQuery consolidation simplifies reporting but conflicts with low-latency relational transactions and broad viewer access violates least privilege.
- Archive object storage minimizes cost but does not meet the transactional database requirement, and signed URLs are a poor regular access model for restricted records.
Question 10
Topic: Designing for Security and Compliance
A financial services company uses a Google Cloud organization with Shared VPC and VPC Service Controls around regulated data projects. Auditors need quarterly evidence that network boundaries and organization policies are enforced, and security teams need to investigate who changed related controls. The company wants evidence that is queryable, repeatable, and not based on screenshots or meeting notes. Which auditing strategy should the architect recommend?
Options:
A. Centralize Cloud Audit Logs and Cloud Asset Inventory exports in BigQuery
B. Enable VPC Flow Logs only on regulated subnets
C. Ask project owners to submit quarterly screenshots of network settings
D. Grant auditors Viewer access to each project for spot checks
Best answer: A
Explanation: A strong audit strategy combines change evidence with configuration-state evidence. Cloud Audit Logs show who changed IAM, network, and policy controls, while Cloud Asset Inventory exports can capture the resource and policy state auditors need to verify. Centralizing this evidence in BigQuery supports repeatable scheduled queries, reports, and retention controls across projects. This is more defensible than informal attestations because the evidence is generated from platform telemetry and inventory data rather than human summaries or screenshots. VPC Flow Logs can help with network traffic analysis, but they do not prove organization policy or boundary configuration by themselves.
- Screenshot reviews are informal, hard to reproduce, and do not reliably show who changed controls.
- Auditor spot checks create manual evidence and may grant broader access than needed.
- VPC Flow Logs only show network flow metadata, not organization policy state or administrative control changes.
Continue in the web app
Use IT Mastery for interactive Google Cloud Professional Cloud Architect practice with mixed sets, timed mocks, topic drills, explanations, and progress tracking.
Try Google Cloud Professional Cloud Architect on Web