Examkin

All practice questions

174 questions

All types1,598Multiple choice815Multiple select537Numeric8Matching64Ordering174
Question 61Question →

In what sequence should a Cloud Security Architect configure an organization-level aggregated log sink to stream Data Access audit logs from all child projects into a centralized BigQuery dataset within a dedicated logging project?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence to set up an organization-level aggregated log sink to a central BigQuery dataset is: First, create the central logging project and target BigQuery dataset. Second, create the organization-level log sink configured with the --include-children flag and audit log filter. Third, retrieve the auto-generated writer identity service account for the log sink. Fourth, grant that writer identity service account the BigQuery Data Editor role on the destination dataset.
The proper administrative workflow begins by establishing the central destination resource (BigQuery dataset) in a dedicated project. Next, the organization log sink is created targeting this dataset with the aggregated option enabled, which provisions a dedicated service account writer identity. The service account name must then be retrieved so that the final step—granting the BigQuery Data Editor IAM role on the destination dataset—can be completed to permit log ingestion.

Step-by-Step Solution

1
Provision the destination GCP project and the BigQuery dataset.
A valid target destination URI is created for the sink definition.
Creating a log sink requires a valid, pre-existing destination target.
2
Execute the organization-level sink creation command with the audit log filter and --include-children flag.
The aggregated log sink is established at the organization level and a service account writer identity is generated.
The writer identity service account is created as a direct side effect of provisioning the log sink.
3
Identify the writer identity output from the created log sink.
The unique service account email for the sink is retrieved.
You must know the exact service account identity before granting permissions.
4
Assign the BigQuery Data Editor IAM role on the destination dataset to the log sink writer identity.
Data Access audit logs from all existing and future projects start flowing into BigQuery.
Log sinks write data asynchronously using their unique service account identity, requiring write authorization on the destination resource.

Key Concept

Organization-level aggregated log sink provisioning workflow and service account access control
Estimated Time:1m 0s
Question 62Question →

A enterprise security architect is auditing access control evaluation for a Google Cloud environment structured with an Organization node, nested Department and Environment Folders, Workload Projects, and Cloud Storage resources. A user requests `storage.objects.get` on a specific bucket. To verify permission resolution and troubleshoot unexpected access results, the architect must trace the exact sequence of Google Cloud Identity and Access Management (IAM) policy evaluation logic.

In what exact sequence does Google Cloud IAM process policy rules and resource hierarchy grants to determine if the user is authorized to perform the action?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct evaluation order begins with checking IAM Deny policies across all hierarchy levels, followed by collecting IAM Allow bindings top-down from the Organization node, through parent Folders, at the Project node, and finally on the target Resource, concluding with computing the union of all Allow permissions to authorize the request.
Google Cloud evaluates authorization by first checking IAM Deny policies across all ancestral nodes (Organization, Folders, Project). If no Deny rule applies, IAM collects Allow permissions top-down starting from the Organization root node, continuing through parent Folders, down to the Project node, and ending at the target Cloud Storage Bucket resource. Finally, it calculates the union of all granted Allow permissions; if the required permission is present, access is granted.

Step-by-Step Solution

1
Check for IAM Deny overrides across the resource hierarchy.
Confirm that no IAM Deny policy defined at the Organization, Folder, or Project level explicitly blocks `storage.objects.get` for the requesting principal.
Google Cloud IAM enforces Deny policies prior to evaluating any Allow rules. An applicable Deny rule short-circuits evaluation and halts execution with an access denied result.
2
Evaluate top-down inherited IAM Allow permissions from the Organization and Folder nodes.
Collect Allow role bindings inherited from ancestor nodes in the hierarchy tree.
Permissions granted at higher levels in the GCP resource hierarchy automatically propagate down to all child resources due to resource hierarchy inheritance.
3
Evaluate project-level IAM Allow permissions.
Add role bindings granted at the Project containing the target bucket to the candidate permission set.
Project-level role grants complement higher-level folder and organization policies for all resources inside that specific project.
4
Evaluate target resource-level IAM Allow permissions.
Add role bindings defined directly on the Cloud Storage Bucket.
Resource-level IAM policies allow fine-grained access control on individual resources at the leaf node of the hierarchy.
5
Calculate effective authorization by taking the union of all collected Allow permissions.
Authorize the API call if the required permission `storage.objects.get` is contained within the resulting permission set.
IAM permissions in GCP are additive. If any valid Allow binding at any level grants the required permission, and no Deny rule blocks it, access is approved.

Key Concept

Google Cloud IAM Policy Evaluation and Resource Hierarchy Inheritance
Question 63Question →

An enterprise platform engineering team is setting up an automated Terraform provisioning pipeline for a production Cloud SQL for PostgreSQL database. Security and networking policies require that the database must utilize Customer-Managed Encryption Keys (CMEK), be accessible strictly via private IP over Private Services Access, and enforce IAM database authentication. To ensure an automated execution without resource dependency deadlocks or authorization failures, in what chronological order must these deployment steps be executed?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for provisioning Cloud SQL with CMEK and Private Services Access is: 1) Create the Cloud KMS key and grant the Encrypter/Decrypter role to the Cloud SQL Service Agent; 2) Reserve an IP range and configure Private Services Access in the VPC; 3) Provision the Cloud SQL instance with private IP, CMEK reference, and IAM authentication; 4) Create database schemas and IAM database users.
Provisioning Cloud SQL infrastructure with CMEK and private connectivity requires strict adherence to foundational dependency chains. First, key permissions must be assigned to the Cloud SQL Service Agent (`[email protected]`) so GCP can access the CMEK key. Second, Private Services Access peering must be established in the VPC network so Cloud SQL can allocate internal IP addresses in the producer network. Third, the Cloud SQL instance is provisioned referencing the CMEK key and private network. Finally, database schemas and IAM database users are created inside the initialized database instance.

Step-by-Step Solution

1
Set up CMEK security permissions
Cloud SQL Service Agent obtains permissions to encrypt/decrypt using the target CryptoKey
Cloud SQL validates disk encryption permissions during initial instance creation. Lacking this permission causes instance creation to fail immediately.
2
Configure private network infrastructure
VPC peering is established between customer VPC and Google's service producer network
Private IP database instances cannot be attached to a VPC without an established Private Services Access peering connection.
3
Deploy the Cloud SQL instance
The Cloud SQL instance is provisioned with private IP connectivity and CMEK disk encryption
The database instance depends directly on pre-existing KMS role bindings and Private Services Access peering.
4
Configure database objects and access
Database schemas and IAM-mapped users are created
Logical database schemas and user roles are internal to the engine and require an operational database instance.

Key Concept

Cloud SQL Provisioning Dependency Sequencing
Question 64Question →

An enterprise pharmaceutical firm is migrating an on-premises Oracle relational database and historical clinical trial data archives to Google Cloud. The target architecture uses Cloud SQL for PostgreSQL for operational data and Cloud Storage for unstructured archives. To ensure minimal downtime and data integrity during cutover, place the migration workflow steps in the correct chronological order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence for a minimal-downtime database and archive migration is: 1) Establish Dedicated Interconnect hybrid networking, 2) Execute historical transfer via Storage Transfer Service and configure CDC replication via Database Migration Service, 3) Stop incoming write traffic on-premises and wait for replication lag to reach zero, 4) Promote the Cloud SQL target instance and update application connection strings.
The correct order follows standard Google Cloud architecture migration staging patterns: first establishing private hybrid connectivity (Dedicated Interconnect), then running bulk file transfers alongside continuous CDC replication via Database Migration Service, followed by stopping source write traffic to drain remaining replication lag to zero, and finally promoting the destination database while pointing application workloads to the new endpoint.

Step-by-Step Solution

1
Establish hybrid connectivity and network security controls.
On-premises environment securely communicates with the Google Cloud VPC via Dedicated Interconnect.
Data transfer tools require secure, high-bandwidth private network paths before executing data movement.
2
Initiate bulk archival data transfer and start continuous CDC database replication.
Historical files land in Cloud Storage while ongoing transactional changes stream continuously into Cloud SQL.
Combining bulk loading with continuous replication establishes a baseline without disrupting live production traffic.
3
Quiesce the source database and verify zero replication lag.
No new transactions occur on-premises, and all pending changes apply to the target Cloud SQL database.
Pausing writes ensures transaction consistency and prevents split-brain conditions during final cutover.
4
Promote the Cloud SQL instance and switch application configuration endpoints.
Applications resume normal operation pointing directly to Google Cloud infrastructure.
Promoting the database detaches CDC replication and establishes Cloud SQL as the primary operational system.

Key Concept

Staged Migration Workflow and Database Cutover Strategy
Question 65Question →

An enterprise cloud architecture team at a global pharmaceutical corporation is establishing a design framework for a new GCP-based clinical trial telemetry platform. The framework requires systematic translation of business goals into provisioned infrastructure. In which sequential order should the cloud architect arrange the architectural design phases, starting from initial business requirements through to final GCP infrastructure deployment?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with establishing the Conceptual Architecture (business domain and compliance requirements), followed by the Logical Architecture (vendor-neutral functional tiers and data processing contracts), then the Physical Architecture (mapping logical components to specific GCP managed services, VPC topologies, and IAM), and concludes with the Implementation Specification (writing IaC manifests, VPC SC perimeters, and deployment pipelines).
The architectural translation lifecycle begins with Conceptual Architecture (defining business capabilities, compliance, and domain boundaries), progresses to Logical Architecture (defining vendor-neutral functional modules, data contracts, and trust perimeters), translates into Physical Architecture (mapping logical components to concrete GCP services like Pub/Sub and Spanner, along with VPC/IAM topologies), and finishes with Implementation Specification (authoring Terraform IaC code, VPC SC perimeters, and CI/CD deployment pipelines).

Step-by-Step Solution

1
Identify high-level business capabilities, governance policies, and compliance boundaries.
Establishes the Conceptual Architecture phase to ground the architecture in enterprise business objectives.
Architectural design must originate from business requirements, regulatory constraints, and domain boundaries without premature technical bias.
2
Define functional software tiers, messaging contracts, and logical security perimeters.
Establishes the Logical Architecture phase.
Logical design structures software capabilities and data flows into technology-agnostic patterns prior to vendor service selection.
3
Select concrete Google Cloud managed services, regional deployments, and explicit IAM controls matching the logical design.
Establishes the Physical Architecture phase.
Physical design binds logical components to real GCP resources (e.g., Cloud Spanner, Cloud Pub/Sub, CMEK) and physical network boundaries.
4
Translate the physical design blueprint into executable provisioning scripts and pipelines.
Establishes the Implementation Specification phase.
Deployment automation (IaC templates like Terraform and CI/CD pipelines) requires a finalized physical architecture specification to build the environment.

Key Concept

Sequential Translation across Conceptual, Logical, Physical, and Implementation Layers in Cloud Architecture
Question 66Question →

An enterprise cloud security architect is documenting the evaluation order for Google Cloud Identity and Access Management (IAM) permissions. When a principal requests access to a Google Cloud resource, IAM evaluates policies hierarchically. Place the following evaluation steps in the correct order, starting from the initial policy evaluation check to the final access decision.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct evaluation sequence begins with checking IAM Deny policies across the hierarchy, followed by evaluating IAM Allow policy inheritance top-down from Organization to Folder/Project, checking target resource-level IAM Allow policies, and concluding with a final decision that defaults to implicit deny unless an Allow policy matches.
Google Cloud evaluates authorization requests by first checking IAM Deny policies at all hierarchy levels. If no Deny policy blocks the request, IAM checks for Allow policy bindings starting at the top of the resource hierarchy (Organization node), moving down through intermediate Folder and Project nodes, and finally checking resource-level policies. If any evaluated Allow policy grants the required permission, access is granted; otherwise, an implicit deny is enforced.

Step-by-Step Solution

1
Check for explicit IAM Deny policies across the resource hierarchy
If a matching Deny policy is found at any level (Organization, Folder, or Project), evaluation stops and access is immediately denied.
Google Cloud IAM evaluates Deny rules first to ensure security guardrails override any permissive Allow rules.
2
Evaluate Allow policies starting at the Organization level
Permissions granted at the Organization node inherit down to all folders, projects, and resources.
IAM uses additive inheritance down the resource hierarchy starting from the root node.
3
Evaluate Allow policies at Folder and Project levels
Permissions granted at Folder and Project levels add to the inherited permissions evaluated from parent nodes.
Child nodes inherit parent permissions, and child policy bindings add additional permissions to the principal's effective access.
4
Evaluate Allow policies directly attached to the target resource
Resource-level policies are inspected to determine if explicit permissions exist at the resource level.
Some GCP resources support fine-grained IAM policies attached directly to individual resource instances.
5
Synthesize accumulated permissions and emit the final authorization decision
Access is granted if any Allow policy matched; otherwise, access is blocked by implicit deny.
IAM operates on a default-deny model where access requires at least one explicit Allow binding.

Key Concept

Google Cloud IAM Policy Evaluation Logic and Resource Hierarchy Inheritance
Question 67Question →

An organization requires all Data Access audit logs across all projects in their Google Cloud organization to be centralized into a BigQuery dataset housed within a dedicated security governance project for compliance analytics. In what sequential order should a Cloud Security Architect execute these implementation steps to establish this aggregated log export?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with provisioning the target BigQuery dataset in the security project, followed by creating the organization aggregated log sink, retrieving the generated writer service account identity, and finally granting that service account the required IAM role on the destination dataset.
Centralized log aggregation in GCP requires preparing the target storage resource first. Next, creating the organization aggregated log sink establishes the log filter and generates a unique service account writer identity. After retrieving this service account identity, granting it write permissions (such as BigQuery Data Editor) on the target dataset enables authorized log delivery across the organization.

Step-by-Step Solution

1
Create the target BigQuery dataset inside a dedicated security project.
A destination dataset is available to store centralized logs.
Cloud Logging sinks require a pre-existing destination path upon sink creation.
2
Define an organization-level aggregated sink pointing to the dataset with a Data Access log filter.
The aggregated sink route is established, generating a unique writer service account.
Cloud Logging uses distinct service accounts per sink to maintain least-privilege log delivery.
3
Extract the writer service account principal ID from the log sink details.
The specific service account identity is available for role assignment.
The writer service account is dynamically created by GCP during sink definition.
4
Grant the BigQuery Data Editor role to the sink service account on the target dataset.
The sink receives authorization to ingest incoming audit log records.
Without explicit destination permissions, log export calls will be rejected.

Key Concept

Organization Aggregated Log Sinks and Service Account Ingestion Authorization
Estimated Time:1m 30s
Question 68Question →

A cloud architect is establishing a secure provisioning workflow to deploy a multi-cluster Cloud Bigtable database for processing real-time trade data. The database must use Customer-Managed Encryption Keys (CMEK) and be accessible only via private network endpoints. In what order should the architect execute these steps to ensure all security and resource dependencies are satisfied?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct execution sequence is: First, create the Cloud KMS CryptoKey and grant the Cloud Bigtable Service Agent the CryptoKey Encrypter/Decrypter IAM role. Second, configure the VPC network with Private Google Access and Private Services Access IP allocation. Third, provision the Cloud Bigtable instance and clusters referencing the CMEK key. Fourth, create the Bigtable tables and configure column families. Fifth, grant the application service account the Bigtable User IAM role on the target table resources.
Provisioning GCP database infrastructure requires strict adherence to cryptographic and network dependency chains. First, the Cloud KMS key must exist and explicit encrypter/decrypter rights must be granted to the GCP service account for Bigtable. Second, the VPC networking layer and Private Services Access IP allocation must be ready. Third, the Bigtable instance is deployed using the CMEK key and network bindings. Fourth, once the instance is active, table structures and column families are created. Finally, identity permissions (such as Bigtable User) are applied to the application service account for the specific table resources.

Step-by-Step Solution

1
Provision Cloud KMS Key and bind Service Agent IAM role
Cloud Bigtable Service Agent (service-[PROJECT_NUM]@gcp-sa-bigtable.iam.gserviceaccount.com) has cryptographic permissions to wrap/unwrap data keys.
Google Cloud service APIs validate CMEK key permissions during instance instantiation; missing IAM bindings cause immediate deployment failure.
2
Configure VPC Networking and Private Services Access
VPC network contains allocated IP ranges and peered private connection endpoints.
Private network paths and IP ranges must be established prior to creating instance clusters bound to private VPC subnets.
3
Deploy Cloud Bigtable Instance and Regional Clusters
Active Cloud Bigtable instance with storage clusters encrypted using the specified CMEK key.
The parent managed instance resource must be fully initialized before child schema objects can be instantiated.
4
Instantiate Table Schema and Column Families
Tables and column family definitions with garbage collection rules exist inside the instance.
Schema definitions exist within the logical scope of an initialized Bigtable instance.
5
Bind Application Identity IAM Access
Application service account is authorized to perform data-plane reads and writes on specific tables.
Fine-grained IAM policy bindings at the table level require target table resource paths to exist in GCP IAM.

Key Concept

Dependency-Aware Provisioning Workflow for Encrypted GCP Storage
Question 69Question →

You need to configure secure, keyless authentication for an external GitHub Actions CI/CD pipeline accessing Google Cloud resources using Workload Identity Federation. What is the correct sequence of steps to establish this setup?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with creating the target GCP Service Account with minimal IAM roles, creating the Workload Identity Pool and Provider for GitHub, granting the external GitHub principal the Workload Identity User role on the service account, and finally configuring the CI/CD workflow to request short-lived tokens.
Configuring Workload Identity Federation requires defining the target GCP Service Account first, establishing the Workload Identity Pool and OIDC Provider, granting the Workload Identity User role to authorize impersonation by the external identity, and lastly configuring the external workload to exchange tokens.

Step-by-Step Solution

1
Define target identity in GCP
A service account exists with specific permissions granted for resource deployment.
Before configuring external authentication, the target GCP resource identity and its permissions must be defined.
2
Establish external trust infrastructure
Workload Identity Pool and OIDC Provider are configured to recognize tokens from GitHub.
Google Cloud must be configured to trust token assertions from the external identity provider.
3
Authorize impersonation
The external principal is granted the Workload Identity User role on the target service account.
Impersonation rights must be granted so the validated external identity is allowed to act as the GCP service account.
4
Exchange tokens in CI/CD pipeline
Short-lived GCP credentials are used during workflow execution.
The pipeline uses its native OIDC token to request temporary GCP federated credentials.

Key Concept

Workload Identity Federation for keyless authentication
Question 70Question →

A cloud architect is establishing an automated deployment sequence to provision a high-availability Cloud SQL PostgreSQL database instance using Customer-Managed Encryption Keys (CMEK) and Private Services Access (PSA) within a dedicated VPC. To ensure all infrastructure dependencies and security access controls are satisfied before instance initialization, in what correct sequential order should these provisioning steps be executed?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: 1) Enable the required Google Cloud APIs for Cloud SQL, Cloud KMS, and Service Networking, 2) Allocate an internal IP range and establish a Private Services Access connection with the service producer network in the VPC, 3) Grant the Cloud SQL Service Agent the Cloud KMS CryptoKey Encrypter/Decrypter IAM role on the target encryption key, and 4) Provision the regional Cloud SQL PostgreSQL instance configured with Private IP and the customer-managed encryption key.
Provisioning managed database systems with strict security controls requires resolving infrastructure dependencies sequentially. First, service APIs must be enabled to activate Cloud KMS, Service Networking, and Cloud SQL capabilities along with their respective service agents. Second, Private Services Access must be configured by reserving an internal IP block and creating VPC peering so the database can bind to a private IP. Third, IAM access must be delegated to the Cloud SQL Service Agent on the Cloud KMS key so it can encrypt storage blocks during creation. Finally, the Cloud SQL instance can be provisioned referencing both the private network and the CMEK key.

Step-by-Step Solution

1
Enable required Google Cloud Service APIs
Cloud SQL Admin API, KMS API, and Service Networking API become active, spawning the necessary service account identities.
Infrastructure APIs must be activated before downstream networking peering or IAM role assignments can be managed.
2
Set up Private Services Access (PSA)
An IP block is allocated and VPC network peering to Google Service Networking is created.
Cloud SQL instances with Private IP require an established Private Services Access connection to route private network traffic within the VPC.
3
Configure CMEK IAM Permissions
The Cloud SQL Service Agent ([email protected]) receives the roles/cloudkms.cryptoKeyEncrypterDecrypter role.
Cloud SQL validates encryption key access at creation time; omitting this step prior to creation causes instance initialization to fail.
4
Deploy the Cloud SQL Instance
The database instance provisions successfully with private networking and customer-managed encryption.
All prerequisite infrastructure, network routing, and IAM key delegation are ready for resource allocation.

Key Concept

Sequential Dependency Resolution for Cloud SQL Private Services Access and CMEK Provisioning
Question 71Question →

An enterprise organization is establishing a standardized disaster recovery (DR) validation procedure for a critical multi-region application on Google Cloud. The architecture uses Cloud SQL cross-region read replicas and Compute Engine managed instance groups (MIGs). In what operational sequence should a cloud architect execute the disaster recovery failover drill from start to finish?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Verify and request necessary Compute Engine quota increases in the target secondary region, 2) Promote the secondary Cloud SQL read replica to a standalone primary database instance, 3) Update Cloud DNS routing policies to direct user traffic to the secondary region endpoint, and 4) Execute automated synthetic workload tests to validate application integrity, RPO, and RTO metrics.
A sound business continuity validation procedure begins with pre-drill verification of target region compute quotas to guarantee capacity. Once capacity is assured, the secondary database is promoted to primary status so that it can receive writes. Next, network endpoints (Cloud DNS) are switched to route incoming traffic to the secondary region. Finally, synthetic transaction tests run to validate data loss (RPO) and operational restore time (RTO).

Step-by-Step Solution

1
Pre-drill Quota Audit
Ensures the secondary GCP region has sufficient resource capacity to scale up workload instances.
Requesting quota increases during an active failover drill will lead to provisioning failures due to approval processing delays.
2
Database Failover Initiation
Promotes the cross-region read replica into a standalone primary instance.
Application servers in the secondary region require a writable database endpoint to serve traffic properly upon cutover.
3
Traffic Redirection
Switches network routing to point user requests to the secondary regional endpoint.
DNS routing changes should only occur once backend compute and database resources are operational.
4
Post-Failover Validation & Monitoring
Confirms data replication consistency and verifies that Recovery Time Objective (RTO) and Recovery Point Objective (RPO) constraints were met.
Final validation tests establish empirical proof of business continuity readiness.

Key Concept

Disaster Recovery Failover Validation Sequence
Question 72Question →

An architecture team is establishing an automated progressive release pipeline for a mission-critical microservice deployed on Google Kubernetes Engine (GKE). The deployment process must strictly enforce container security attestations, progressive traffic shifting, and continuous automated health monitoring before achieving full production rollout. Place the operational stages of this release strategy in the correct chronological order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct execution order begins with building and storing the container image in Artifact Registry, followed by Container Analysis scanning and Binary Authorization attestation signing. Next, Cloud Deploy provisions the workload to the staging environment. Once staging tests pass, Cloud Deploy routes 10% of live traffic to the canary release. Finally, Cloud Monitoring evaluates real-time SLIs before Cloud Deploy automatically promotes the release to 100% production traffic.
The sequence follows standard Google Cloud continuous delivery best practices: Code must first be compiled into an artifact in Artifact Registry. Security verification via Container Analysis and Binary Authorization attestation occurs next to ensure image compliance. The image is then deployed to staging via Google Cloud Deploy. Following successful staging validation, Cloud Deploy shifts a initial fraction (10%) of production traffic to the canary pods. Cloud Monitoring continuously tracks error rates and latency during this canary phase, permitting final promotion to 100% traffic only after stability criteria are satisfied.

Step-by-Step Solution

1
Source Compilation & Artifact Build
Container image created and pushed to Artifact Registry with a unique digest.
Source code must be packaged into an immutable container artifact before security scanning or deployment.
2
Vulnerability Scanning & Policy Attestation
Binary Authorization attestor generates a cryptographic signature confirming compliance.
GKE Binary Authorization admission controllers block deployments unless the image digest contains required attestations.
3
Staging Environment Deployment
Cloud Deploy renders Kubernetes manifests and deploys the workload to the staging target.
Initial deployment to non-production environments verifies deployment rendering and pre-release integration tests.
4
Canary Traffic Shifting
GKE ingress/service routes a controlled 10% fraction of user traffic to the canary pods.
Progressive delivery minimizes blast radius by testing new code against a small portion of live production traffic.
5
Automated SLI Validation & Production Promotion
Cloud Deploy shifts remaining 90% traffic to complete the production rollout after metrics verification.
Real-time monitoring of error rates and latency guarantees system stability before full traffic promotion.

Key Concept

Automated CI/CD Pipeline Execution Order with Progressive Canary Delivery and Binary Authorization
Question 73Question →

An organization is implementing a zero-trust credential architecture to allow workloads running on an external on-premises Kubernetes cluster to retrieve sensitive credentials stored in Google Cloud Secret Manager. To comply with strict security standards, you must eliminate all static, long-lived service account keys and enforce least privilege. Arrange the operational and architectural steps in the correct chronological order required to establish Workload Identity Federation and securely retrieve the secret payload.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins by creating the target Google Cloud Service Account with restricted Secret Manager Accessor permissions, followed by creating the Workload Identity Pool and OIDC Provider, granting the Workload Identity User role to the specific external principal subject, exchanging the external OIDC token for a short-lived GCP token via STS, and finally accessing the secret payload.
The sequence follows the compulsory architectural workflow for Workload Identity Federation: first defining the GCP service account with least privilege permissions, establishing the external trust boundary via Workload Identity Pool and Provider, binding the federated principal to the service account via Workload Identity User role, performing the runtime token exchange with STS, and using the resulting temporary token to access Secret Manager.

Step-by-Step Solution

1
Provision the Google Cloud identity and grant resource-level permissions.
A dedicated Service Account exists with `roles/secretmanager.secretAccessor` granted specifically on the required secret resource.
Before external access can be granted, the target identity and its least-privilege access permissions must exist inside GCP.
2
Define external identity trust mechanisms in GCP IAM.
A Workload Identity Pool and OIDC Provider are established, pointing to the external Kubernetes issuer URL.
GCP must be configured to validate tokens signed by the external OIDC identity provider.
3
Configure IAM impersonation policy for federated principals.
The external workload identity subject is bound to the GCP Service Account via `roles/iam.workloadIdentityUser`.
This establishes the authorization bridge enabling the specific external pod identity to impersonate the GCP Service Account.
4
Execute runtime token exchange via Security Token Service (STS).
The workload obtains a short-lived GCP access token in exchange for its native Kubernetes service account JWT.
Workload Identity Federation relies on short-lived STS credential exchange rather than stored service account keys.
5
Access secret payload using short-lived credentials.
The workload successfully authenticates to Secret Manager and retrieves the secret data.
The temporary access token provides the necessary identity authorization to perform the API call.

Key Concept

Workload Identity Federation & Service Account Key Elimination
Question 74Question →

An organization is executing a planned disaster recovery (DR) simulation for a critical web application hosted on Google Cloud. Arrange the standard operational steps in the correct chronological sequence to perform the failover and validation procedure.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with verifying regional resource quotas, followed by database synchronization and promotion, then updating Cloud DNS routing to point to the failover region, and concludes with validating application health and SLO metrics.
The correct procedure follows a logical operational dependency chain: first ensure compute quota capacity in the destination region, promote the replicated database to ensure state consistency, update Cloud DNS to switch live traffic to the target environment, and finally conduct health and SLO checks to validate success.

Step-by-Step Solution

1
Pre-failover Quota Verification
Ensures the destination region has sufficient quota allocations to launch required Compute Engine and network resources.
Requesting quota increases takes time and must be done prior to failover execution to prevent resource allocation failure.
2
Database Promotion and Data Integrity Check
Ensures data replication is up-to-date and sets the secondary storage tier to read-write mode.
The database tier must be active and consistent before application instances can process user transactions.
3
Traffic Redirection via Cloud DNS
Directs incoming user traffic from the primary environment to the secondary region endpoint.
Traffic routing should only be switched after target compute and database services are fully ready to process requests.
4
Post-failover Validation and Operational Monitoring
Confirms that latency, throughput, and error rates conform to target SLOs/SLIs.
Empirical validation verifies that business continuity requirements are fully met under disaster conditions.

Key Concept

Disaster Recovery Failover Execution and Validation Workflow
Estimated Time:1m 0s
Question 75Question →

A principal attempts to execute an API call on a Compute Engine instance residing in a project nested within a folder hierarchy under an Organization node. IAM Deny policies and IAM Allow policies are configured across multiple levels of the resource hierarchy. In what correct chronological order does Google Cloud IAM evaluate these policies to determine whether to authorize or reject the request?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with top-down evaluation of IAM Deny policies starting from the Organization level, followed by intermediate Folder levels, and then the Project level. Next, inherited and direct IAM Allow policies across the entire hierarchy are evaluated in effective union. Finally, the system renders an authorization decision granting access only if a valid Allow policy exists and no Deny policies apply.
In Google Cloud IAM, policy evaluation follows a strict order: Deny policies are evaluated first, starting at the root Organization node and moving down through Folders to the target Project. If no Deny policy matches, IAM computes the union of all inherited and direct Allow policies across Organization, Folder, Project, and Resource levels. If at least one Allow policy grants the permission, access is authorized.

Step-by-Step Solution

1
Evaluate Organization-level Deny policies
Highest priority Deny rules checked first
Google Cloud IAM Deny policies take precedence over Allow policies and are evaluated starting from the root Organization node.
2
Evaluate Folder-level Deny policies
Hierarchical Deny check traverses intermediate parent folders
Deny policies set at parent folder levels inherit downwards and block access before project policies or allow policies are considered.
3
Evaluate Project-level Deny policies
Project container Deny rules checked
Project-scoped Deny policies form the final layer of explicit denial checks before evaluating permissions.
4
Evaluate effective Union of IAM Allow policies across all levels
Aggregated inherited and direct permissions evaluated
IAM Allow policies are additive across Organization, Folder, Project, and Resource nodes. If no Deny rule matched, all granted roles are evaluated together.
5
Render authorization decision
Access authorized or implicitly denied
If an Allow rule grants the required permission, access is authorized; if no matching Allow rule is found, IAM denies access by default.

Key Concept

GCP IAM Policy Evaluation Order and Resource Hierarchy Inheritance
Question 76Question →

An enterprise security architect needs to configure an organization-wide aggregated Cloud Audit Log pipeline to stream Data Access audit logs from all current and future child projects into a centralized BigQuery dataset in a security management project. Arrange the deployment steps in the correct chronological order required to successfully establish this aggregated sink with least privilege access.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins by creating the destination BigQuery dataset, followed by creating the organization-level aggregated log sink with child inclusion enabled. Next, the auto-generated writer identity service account for the sink is retrieved, and finally, the service account is granted the BigQuery Data Editor role on the target dataset.
Establishing an organization-wide aggregated log sink requires creating the target dataset first, defining the organization sink with child inclusion to generate a dedicated service account identity, extracting that service account identity, and applying dataset-level IAM permissions to grant write access.

Step-by-Step Solution

1
Provision the destination storage resource in the security project.
A BigQuery dataset is created to serve as the destination URI for incoming audit log entries.
Cloud Logging sinks require an existing destination resource upon creation.
2
Execute the organization sink creation command defining the log filter and enabling child project aggregation.
The aggregated log sink is established at the organization root, and Cloud Logging creates a unique service account writerIdentity.
Creating an organization sink with the include-children parameter ensures log collection across the entire resource hierarchy.
3
Inspect the created sink properties to extract the writerIdentity service account string.
The sink's service account email address is obtained.
The service account identity is needed to grant target dataset access.
4
Apply IAM binding granting the writer identity service account BigQuery Data Editor permissions on the target dataset.
Logs begin successfully streaming from child projects into the centralized BigQuery dataset.
Least-privilege authorization must be explicitly configured on the destination resource for log writing to succeed.

Key Concept

Organization-Aggregated Cloud Audit Log Sinks and Service Account Authorization
Estimated Time:1m 30s
Question 77Question →

An enterprise architecture team is designing an automated, secure CI/CD pipeline for a microservices application targeted for Cloud Run. To satisfy security and operational requirements, the pipeline must incorporate automated unit testing, container registry storage, security vulnerability scanning, policy validation, and progressive deployment. What is the correct chronological sequence of pipeline steps from initial source code commit to final production release?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct pipeline sequence begins with committing code to trigger Cloud Build, followed by running unit tests and compiling the container image, pushing the container to Artifact Registry to trigger Container Analysis, evaluating vulnerability scan results as a security gate, and finally deploying the release via Cloud Deploy to Cloud Run using a progressive canary strategy.
A secure, continuous delivery pipeline must follow a strict logical progression: code ingestion triggers the CI runner (Cloud Build), unit tests validate functional code before packaging, artifacts are stored in Artifact Registry to trigger Container Analysis, security scanning policy gates release creation, and finally Cloud Deploy manages progressive deployment to the runtime platform (Cloud Run).

Step-by-Step Solution

1
Initiate automated trigger
Cloud Build pipeline starts execution upon receiving the repository commit event.
CI/CD automation begins at code check-in.
2
Build and test container
Code passes unit tests and is packaged into an OCI-compliant container image.
Testing and container creation are required prior to image publishing.
3
Store artifact and scan
Container image is uploaded to Artifact Registry, initiating automatic Container Analysis scanning.
Container Registry storage enables automated security scanning against known vulnerability databases.
4
Evaluate security gating
Pipeline validates scan results and approves release creation in Cloud Deploy.
Deployment releases must be gated by security analysis checks to prevent vulnerable code from entering target environments.
5
Execute progressive deployment
Cloud Deploy deploys the application to Cloud Run with canary traffic splitting.
Progressive release delivery reduces blast radius and validates production telemetry before full traffic cutover.

Key Concept

CI/CD Pipeline Sequencing and Security Gating in GCP
Estimated Time:1m 30s
Question 78Question →

An enterprise cloud security architect is auditing how access rights are evaluated across a Google Cloud environment. When a principal attempts an action on a specific resource, IAM permissions are evaluated along the resource hierarchy. Arrange the following evaluation steps in the correct order, starting from the highest ancestor node in the hierarchy down to the specific target resource.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for IAM policy inheritance and evaluation moves down the resource hierarchy: Organization level -> Folder level -> Project level -> Resource level.
Google Cloud IAM follows a strict top-down resource hierarchy structure (Organization -> Folder -> Project -> Resource). Policies set at any node in the hierarchy are inherited by all of its descendants. Therefore, evaluating effective permissions begins at the Organization level, proceeds through parent Folders, checks Project bindings, and concludes at the specific Resource level.

Step-by-Step Solution

1
Identify the top-most root node of the Google Cloud resource hierarchy.
Organization-level IAM policies are evaluated first as the root ancestor.
Permissions granted at the organization level inherit down to all child nodes in the organization tree.
2
Trace policy inheritance through intermediate grouping containers.
Folder-level IAM policies are evaluated next along the parent folder path.
Folders allow grouping projects and inherit policies from the organization while passing them to child projects.
3
Evaluate access at the project container level.
Project-level IAM policies are evaluated.
Projects contain individual resources and inherit all permissions assigned at organization and folder ancestors.
4
Check permissions directly attached to the target service instance.
Resource-level IAM policies are evaluated to determine final effective access.
Fine-grained permissions can be bound directly to specific resources like BigQuery datasets or Cloud Storage buckets.

Key Concept

Google Cloud IAM Policy Inheritance and Resource Hierarchy Evaluation
Estimated Time:1m 30s
Question 79Question →

An organization is executing a planned disaster recovery (DR) validation drill for a mission-critical web application on Google Cloud. Arrange the following steps into the correct sequence from first to last to ensure a successful failover test.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence for DR validation is: (1) Verify resource quota limits and capacity availability in the target disaster recovery region, (2) Verify database replication catch-up and confirm that the Recovery Point Objective (RPO) target is met, (3) Promote the secondary database replica to primary status and scale up standby compute workloads, and (4) Update Cloud DNS records and global Cloud Load Balancing routing to direct client traffic to the secondary region.
A structured DR validation procedure progresses systematically: verifying environmental capacity (quotas), confirming data state and RPO compliance, promoting infrastructure and databases, and finally updating network routing to shift user traffic.

Step-by-Step Solution

1
Perform regional quota and capacity pre-checks.
Ensures that target Compute Engine and network quotas in the DR region are sufficient for failover.
Failing to check quota availability first can cause failover operations to fail mid-execution.
2
Check replication state and validate RPO compliance.
Confirms data catch-up state between primary and standby database instances.
Promoting a standby database before verifying replication status can cause data loss exceeding RPO limits.
3
Promote database and activate application instances.
Establishes a fully operational primary data layer and application pool in the secondary region.
Backend services must be online and healthy before accepting user requests.
4
Switch DNS and load balancer traffic routing.
User traffic is seamlessly redirected to the newly promoted secondary environment.
Routing traffic prior to infrastructure readiness results in failed user connections and outage errors.

Key Concept

Disaster Recovery Validation Procedure Sequence
Question 80Question →

A national smart power grid operator ingests real-time telemetry from millions of edge meters into Google Cloud across a primary region (us-central1) and a secondary disaster recovery region (us-east4). The organization must execute a scheduled business continuity validation drill to prove recovery capability without corrupting live state or exceeding target Recovery Point Objective (RPO) and Recovery Time Objective (RTO) limits. In what sequential order should the cloud architecture team execute the following procedure steps to validate regional disaster recovery failover?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with pre-drill quota and capacity reservation validation in the target region, followed by database state transition and integrity verification, then live traffic redirection via Cloud DNS and Global Load Balancing, followed by synthetic workload testing for RPO/RTO validation, and concludes with restoring cross-region database replication back to the primary region.
Disaster recovery validation requires a strict dependency order: verifying infrastructure capacity prerequisites (quota and reservations), transitioning the persistent state layer (database failover), shifting network ingress routing (DNS and load balancing), validating application health against RPO/RTO metrics using synthetic tests, and finally re-establishing reverse data replication to guarantee ongoing business continuity.

Step-by-Step Solution

1
Pre-drill infrastructure audit
Ensures us-east4 has sufficient quota and reserved compute instances ready to launch.
Failing to check quota prior to failover can lead to instance launch failures during peak load migration.
2
Database failover and data integrity check
Transitions database write leadership to us-east4 and confirms zero data loss.
Data persistence integrity must be guaranteed before live network traffic is allowed to write to the secondary location.
3
Network traffic steering transition
Switches ingress endpoints and DNS records to target us-east4 services.
Routing live client connections to an unready or non-primary database destination will cause system outages.
4
RPO/RTO validation and synthetic testing
Verifies that service performance and data integrity meet business continuity objectives.
Validation drills require explicit verification against business SLOs while operating in the secondary region.
5
Replication re-establishment and stabilization
Restores bidirectional or target-to-primary data sync for failback readiness.
A secondary region operating without an active replication target invalidates high availability post-failover.

Key Concept

Disaster Recovery Validation Procedures and Operational Execution Order
PreviousPage 4 / 9Next
All practice questions — Google Cloud Professional Cloud Architect | Examkin