Examkin

All practice questions

174 questions

All types1,598Multiple choice815Multiple select537Numeric8Matching64Ordering174
Question 101Question →

A cloud engineering team is designing a secure, automated Continuous Integration and Continuous Delivery (CI/CD) pipeline on Google Cloud to deploy containerized microservices to Google Kubernetes Engine (GKE) using Cloud Build, Artifact Registry, Binary Authorization, and Cloud Deploy. Arrange the operational pipeline stages in the correct chronological execution order from initial code commit to production rollout.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence of pipeline stages is: (1) Source code commit triggers Cloud Build to compile code and push the container image to Artifact Registry, (2) Container Analysis scans the image and Cloud KMS signs the digest for Binary Authorization, (3) Cloud Deploy creates a release and deploys the attested image to the staging GKE cluster, (4) Integration tests pass in staging and Cloud Deploy requests explicit manual approval, and (5) Cloud Deploy executes a progressive canary rollout to the production GKE cluster upon approval.
The proper sequence aligns with Google Cloud CI/CD best practice architecture: artifact compilation (Cloud Build to Artifact Registry) -> security vulnerability scanning and attestation (Container Analysis and Binary Authorization) -> non-production deployment (Cloud Deploy to staging GKE) -> automated qualification testing and approval gating -> production rollout (Cloud Deploy progressive canary deployment).

Step-by-Step Solution

1
Identify the build phase (Continuous Integration)
Developers push code, which triggers Cloud Build to build the container image and upload it to Artifact Registry.
Building and publishing the container artifact must take place before security attestation scanning or deployment can begin.
2
Identify image security verification and attestation
Container Analysis performs vulnerability scanning and a KMS key signs the image digest for Binary Authorization.
GKE clusters configured with Binary Authorization require cryptographic attestations created from image digests prior to cluster admission.
3
Identify non-production release creation and deployment
Cloud Deploy creates a release specifying the signed digest and deploys to the staging GKE cluster.
Cloud Deploy manages continuous delivery across target environments, deploying first to pre-production targets.
4
Identify environment qualification and approval gating
Staging integration tests succeed and Cloud Deploy triggers a manual approval requirement for production rollout.
Enterprise governance requires automated staging validation followed by human authorization before production changes occur.
5
Identify final production deployment execution
Cloud Deploy carries out a progressive canary deployment to the production GKE cluster.
Canary rollouts safely update production workloads incrementally while monitoring for metrics regressions.

Key Concept

Continuous Integration and Continuous Delivery (CI/CD) Pipeline Design
Estimated Time:1m 30s
Question 102Question →

Your engineering team is executing a blue-green deployment strategy for a stateless microservice on Google Kubernetes Engine (GKE) that relies on a Cloud SQL database. In what sequence should you execute these deployment steps to achieve a zero-downtime release?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for a zero-downtime blue-green deployment starts with applying backward-compatible database schema updates. Next, deploy the new green application version to GKE, followed by running internal smoke tests to validate its readiness. After successful validation, update Cloud Load Balancing to route user traffic to the green deployment. Finally, monitor service health and decommission the old blue deployment.
Applying backward-compatible database migrations first guarantees that active users on the blue environment experience no disruption. Deploying and validating the green application in isolation minimizes risk. Updating Cloud Load Balancing instantly shifts user traffic to the green release without dropping connections, and retaining the blue version during a brief soak period provides a quick rollback option before cleanup.

Step-by-Step Solution

1
Execute backward-compatible database schema migrations.
The database supports both legacy and new application code models concurrently.
Prevents runtime database errors for users currently on the active blue version.
2
Provision the green workload on Google Kubernetes Engine.
The green pods launch in parallel without receiving public traffic.
Establishes the new application version in an isolated environment.
3
Validate the green environment using internal endpoints.
Functional readiness and health of the green application are confirmed.
Prevents routing end-user traffic to a broken or misconfigured release.
4
Reconfigure Cloud Load Balancing to target the green backend service.
All incoming user requests instantly switch to the green application.
Executes the instantaneous traffic cutover required for zero-downtime deployment.
5
Decommission the blue GKE deployment after a soak period.
Old cluster resources are deleted once stability is assured.
Preserves an instant rollback path during initial monitoring before freeing infrastructure resources.

Key Concept

Blue-Green Deployment Lifecycle & Database Schema Compatibility
Estimated Time:1m 15s
Question 103Question →

A principal cloud architect is tasked with bringing an unmanaged, production Google Cloud environment containing critical Compute Engine and VPC resources under Terraform management. The solution must enforce remote state locking, prevent resource destruction, ensure zero downtime, and align with Google Cloud security best practices. What is the correct sequence of operational steps to safely import the infrastructure and establish managed IaC execution?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for adopting existing GCP resources into Terraform management is to first initialize a Cloud Storage remote backend with state locking, declare matching resource configurations, execute terraform import for existing resource IDs, run terraform plan to eliminate attribute drift, and finally commit the code to trigger a least-privilege CI/CD deployment pipeline.
Safely bringing existing live infrastructure under IaC management requires establishing a secure central backend first to maintain state integrity. Once initialized, target resource structures must be declared in code so `terraform import` can map live GCP resource IDs into state without destroying or replacing resources. A subsequent planning step is essential to reconcile discrepancies between code declarations and actual infrastructure attributes before handing off execution to an automated CI/CD pipeline configured with granular IAM permissions.

Step-by-Step Solution

1
Initialize remote Cloud Storage backend with state locking enabled using `terraform init`.
Establishes a centralized, lock-protected state environment.
Prevents state file loss and race conditions during initial resource onboarding.
2
Draft matching resource HCL blocks in configuration files.
Creates valid resource targets for the state import engine.
Terraform import requires a declared resource address to map imported attributes.
3
Run `terraform import <resource_address> <gcp_resource_id>` for each target component.
Metadata and current state of live cloud resources are written into the remote state file.
Connects live GCP resource IDs to Terraform state without modifying running infrastructure.
4
Run `terraform plan` and update local code attributes until no infrastructure changes are indicated.
Achieves parity between code configuration, state file, and live infrastructure.
Prevents unintended replacement or modification of critical production resources.
5
Commit configurations to Git and enforce pipeline execution with least-privilege service accounts.
Establishes secure, automated IaC lifecycle governance.
Eliminates manual console/CLI execution and enforces strict auditing and IAM control.

Key Concept

Brownfield IaC Adoption and State Import Workflow
Question 104Question →

An enterprise organization is designing a secure CI/CD pipeline on Google Cloud to deploy microservices to Google Kubernetes Engine (GKE). The pipeline architecture must enforce automated container vulnerability scanning, software supply chain security using Binary Authorization attestations, and progressive delivery governance across staging and production environments. Sequence the steps required to execute a secure deployment from initial source code commit to final production rollout in the correct chronological order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for a secure Google Cloud CI/CD pipeline is: 1) Trigger Cloud Build to compile code and run unit tests; 2) Perform Container Analysis scanning and generate Binary Authorization attestations via Cloud KMS; 3) Publish the signed container image and attestation metadata to Artifact Registry; 4) Use Cloud Deploy to create a release and deploy to the Staging GKE cluster; 5) Obtain operational approval and execute a canary rollout to the Production GKE cluster via Cloud Deploy.
A secure end-to-end cloud release pipeline begins by triggering Cloud Build to compile code and execute unit tests. Following image compilation, Container Analysis performs vulnerability scanning and Cloud Build uses Cloud KMS to produce a Binary Authorization attestation. The container digest and signed attestation are then published to Artifact Registry. Cloud Deploy picks up the release to deploy it first into the Staging GKE cluster. Finally, upon explicit operational approval, Cloud Deploy executes a progressive canary deployment to the Production GKE cluster.

Step-by-Step Solution

1
Trigger build and test execution in Continuous Integration tool
Cloud Build compiles the source code into a container artifact and validates logic using unit testing.
Building and testing source code is the entry point of any CI/CD pipeline before artifacts are evaluated or promoted.
2
Perform security scanning and Binary Authorization attestation signing
Container Analysis scans the image for vulnerabilities, and Cloud Build uses Cloud KMS to cryptographically sign a payload attesting security compliance.
Attestations must be produced at build time so Binary Authorization policy enforcers on GKE cluster admission controllers can evaluate compliance.
3
Publish immutable container digest and attestation metadata
Artifact Registry receives and stores the container image digest and associated attestation details.
Centralizing attested container images in Artifact Registry provides an immutable source of truth for deployment targets.
4
Initiate Cloud Deploy release to staging environment
Cloud Deploy creates a pipeline release using the Artifact Registry digest and deploys the workload to the Staging GKE cluster.
Deploying to pre-production staging environments allows automated end-to-end integration and smoke testing before production promotion.
5
Approve and execute progressive production delivery
After manual approval, Cloud Deploy executes a canary release strategy to shift production traffic incrementally to the new GKE deployment.
Production deployments require administrative approval gates and progressive delivery mechanisms (such as canary rollouts) to minimize blast radius.

Key Concept

Continuous Integration and Continuous Delivery (CI/CD) Pipeline Design
Estimated Time:2m 0s
Question 105Question →

An engineering team needs to migrate their local Terraform state file to a centralized Google Cloud Storage (GCS) bucket for collaborative management. Arrange the operational steps in the correct sequential order to complete this state migration.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational order begins with adding the `backend "gcs"` configuration block, executing `terraform init`, confirming the state transfer prompt, and finishing with `terraform plan` to verify remote state synchronization.
Safely migrating local Terraform state to a remote GCS backend requires defining the backend block in code, running `terraform init` to initiate migration, agreeing to transfer existing state data, and running `terraform plan` to confirm remote state integrity.

Step-by-Step Solution

1
Declare the GCS backend in Terraform configuration
The Terraform project code now specifies the destination GCS bucket and state prefix.
Terraform must be informed of the new state backend target before any migration commands can run.
2
Run `terraform init`
Terraform detects the added backend block and triggers the migration routine.
The init command configures the backend plugins and prepares to transfer existing state to the new location.
3
Confirm the state copy prompt
The local state data is safely uploaded into the GCS bucket.
Explicit user approval ensures that local state is transferred rather than generating a fresh empty state.
4
Execute `terraform plan` for validation
Confirmation of zero unexpected infrastructure changes.
Running plan verifies that the remote state file is functioning properly and matches actual GCP resources.

Key Concept

Terraform Remote State Migration to Google Cloud Storage
Question 106Question →

A biotechnology firm is setting up a secure, isolated environment for a genomic data analytics pipeline in Google Cloud. The lead cloud security architect must establish a resource hierarchy and grant access using custom IAM roles while maintaining minimal operational overhead and strict least-privilege access controls. Arrange the implementation steps in the correct chronological sequence from first to last to establish the resource hierarchy and role inheritance correctly.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order to establish the resource hierarchy and IAM role inheritance is: 1) Create the 'Genomics-Pipeline' folder under the Organization node, 2) Define the Custom IAM Role at the Organization level, 3) Bind the Custom IAM Role to the service account at the folder level, and 4) Provision the GCP Project inside the folder.
The correct implementation sequence establishes administrative containers first (Folder under Organization), centralizes privilege definitions (Organization-level Custom IAM Role), applies policy bindings to the folder container, and finally provisions child resources (GCP Project inside the Folder) that inherit the established policies. This adheres to Google Cloud recommended practices for least privilege and resource hierarchy inheritance.

Step-by-Step Solution

1
Establish the resource hierarchy folder container.
The folder node exists under the Organization to act as an administrative boundary.
Creating the folder first defines the parent node where policy inheritance will be enforced.
2
Define the Custom IAM Role at the Organization level.
The role definition is centralized and accessible across the entire resource hierarchy.
Organization-level role definition enables broad reusability and centralized maintenance across folders and projects.
3
Attach the role binding to the target service account at the folder level.
IAM policy binding is associated with the folder node.
Applying the binding at the folder level allows all descendant projects to inherit the access control policy.
4
Create the GCP project within the folder.
The project inherits folder-level IAM policies immediately upon creation.
Placing the project inside the folder ensures resources inherit access policies without requiring manual per-project permission grants.

Key Concept

IAM Resource Hierarchy Inheritance and Organization-Level Custom Role Scoping
Question 107Question →

A cloud platform team needs to provision a high-throughput Cloud Bigtable database environment for a real-time analytics application on Google Cloud. The deployment must comply with corporate security standards requiring Customer-Managed Encryption Keys (CMEK) for data at rest, and governance policies requiring application workload separation using App Profiles. In which sequence should the platform engineering team execute these provisioning steps to ensure successful deployment without authorization or dependency failures?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct provisioning order is: 1) Create the Cloud KMS KeyRing and CryptoKey, 2) Grant the Cloud Bigtable Service Agent the Cloud KMS CryptoKey Encrypter/Decrypter role, 3) Provision the Cloud Bigtable instance and cluster specifying the CMEK key URI, and 4) Create the Bigtable tables and configure App Profiles.
The deployment sequence must follow Google Cloud resource dependency and security authorization requirements. First, the Cloud KMS key must be created to obtain a valid resource path. Second, the service-managed Cloud Bigtable Service Agent account (`[email protected]`) must be granted the Cloud KMS CryptoKey Encrypter/Decrypter role so GCP can access the key. Third, the Cloud Bigtable instance and cluster are created using the KMS key URI. Finally, tables and App Profiles are deployed into the running instance to complete application onboarding.

Step-by-Step Solution

1
Create the Cloud KMS KeyRing and CryptoKey in the designated deployment region.
A valid KMS key resource identifier is instantiated.
Downstream IAM role assignments and resource encryption references depend on the existence of the KMS key.
2
Bind the `roles/cloudkms.cryptoKeyEncrypterDecrypter` role to the Cloud Bigtable Service Agent on the CryptoKey.
The Bigtable service account gains permission to wrap and unwrap data encryption keys.
Attempting to create a CMEK-encrypted instance without granting this role first causes immediate provisioning failure during key validation.
3
Deploy the Cloud Bigtable instance and cluster referencing the CMEK key URI.
The parent database infrastructure is provisioned and encrypted.
Parent instance infrastructure must be fully provisioned before child objects such as tables and app profiles can be created.
4
Create Bigtable tables and set up App Profiles for application workload isolation.
Database tables and routing profiles become operational for client applications.
Child resources depend strictly on an existing, ready Cloud Bigtable instance.

Key Concept

Cloud Bigtable CMEK Provisioning Workflow and Resource Dependency Management
Question 108Question →

A fintech organization is deploying compliance-critical payment processing microservices to Google Kubernetes Engine (GKE). The enterprise security team requires a zero-trust delivery pipeline that enforces container vulnerability scanning, cryptographic build provenance verification, binary authorization policy gates, and automated progressive rollout to prevent unvetted code from reaching production. Place the automated pipeline execution stages in the correct chronological sequence from source commit to production deployment.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with Cloud Build building and pushing the container image to Artifact Registry, followed by Container Analysis vulnerability scanning and signing attestations via Cloud KMS, followed by Binary Authorization policy validation during release creation, and concludes with Cloud Deploy executing progressive canary rollout to GKE targets.
The pipeline flow strictly follows the software supply chain security lifecycle: code compilation and container build with Cloud Build pushing to Artifact Registry, vulnerability scanning with Container Analysis to produce KMS-signed attestations, pre-deployment policy verification via Binary Authorization, and finally progressive canary release management using Cloud Deploy.

Step-by-Step Solution

1
Build and Artifact Storage
Container image created and stored in private Artifact Registry.
Source code compilation and container image creation must precede security auditing and deployment stages.
2
Vulnerability Scanning and Attestation
Container Analysis scans the image and signs an attestation using Cloud KMS keys.
Cryptographic attestations must be generated based on successful security scanning results before admission control policies can be evaluated.
3
Admission Control Gate Enforcement
Binary Authorization verifies required signatures and grants release creation.
Policy validation must occur prior to rendering delivery manifests or deploying workloads to Kubernetes clusters.
4
Progressive CD Delivery Execution
Cloud Deploy manages canary deployment and automated promotion to production GKE clusters.
Progressive traffic allocation and target deployments represent the final operational phase of the pipeline.

Key Concept

Secure CI/CD Pipeline Design with Container Attestations, Binary Authorization, and Cloud Deploy
Question 109Question →

A Google Cloud Security Architect is documenting how IAM permissions are evaluated for a principal requesting access to a Cloud Storage bucket inside a multi-tier folder environment. Arrange the resource hierarchy levels in the correct order of policy evaluation and inheritance, starting from the root parent node down to the individual target resource.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of IAM policy evaluation across the Google Cloud resource hierarchy starts at the Organization node, descends through the Folder node, proceeds to the Project node, and finishes at the Resource-level (Cloud Storage bucket).
In Google Cloud, IAM access policy evaluation follows the strict top-down structure of the resource hierarchy: Organization -> Folder -> Project -> Resource. Permissions granted at higher nodes inherit downward and accumulate, determining the effective access granted to a principal.

Step-by-Step Solution

1
Identify the top root level of the resource hierarchy.
The Organization node is evaluated first.
IAM policy inheritance flows downwards starting from the Organization node at the top of the hierarchy.
2
Evaluate policies attached to grouping containers below the organization.
Parent Folder nodes are evaluated second.
Folders inherit permissions from the Organization and pass accumulated permissions to nested folders and projects.
3
Evaluate policies at the main service container level.
The Project node policy is evaluated third.
Projects reside inside folders and inherit all permissions assigned at higher levels.
4
Evaluate policies directly bound to the target resource.
The Cloud Storage bucket policy is evaluated last.
Resource-level policies provide fine-grained control directly on the target resource within the project.

Key Concept

Google Cloud IAM permissions are inherited down the resource hierarchy (Organization -> Folder -> Project -> Resource). Permissions are additive, meaning access granted at a higher level cannot be denied or restricted at a lower child level.
Question 110Question →

A cloud architect is establishing a standard operating procedure for validating disaster recovery (DR) failover of a mission-critical workload from a primary GCP region to a secondary target region. What is the correct sequence of steps to safely execute and validate this DR drill without impacting live production systems?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with auditing regional resource quotas, followed by creating isolated database clones, provisioning compute infrastructure via IaC, running synthetic validation tests, and concluding with environment teardown and metric logging.
Validating a DR environment safely requires a structured sequence: first ensuring GCP resource quotas in the target region are sufficient, isolating test data via point-in-time database cloning, deploying compute infrastructure via automated IaC templates, conducting synthetic transaction testing to verify RTO/RPO metrics, and finally cleaning up test resources while recording compliance results.

Step-by-Step Solution

1
Audit and request regional quota increases in the DR target region.
Guarantees target region capacity can host failover workloads without encountering quota limits.
Quota pre-checking avoids capacity failure during DR testing or actual failover.
2
Generate point-in-time database clones in the DR region.
Establishes a sandbox copy of production data for testing.
Prevents validation tests from modifying live database replicas or interrupting replication streams.
3
Deploy compute instances using Infrastructure as Code connected to the clone.
Establishes a functioning application tier in the DR region.
Ensures reproducible environment configuration aligned with production specifications.
4
Execute synthetic workload transactions and measure baseline metrics.
Confirms application functionality and validates compliance with RPO and RTO SLAs.
Synthetic testing verifies system readiness under simulated operational conditions.
5
Deprovision test infrastructure and record compliance logs.
Cleans up resources to avoid unnecessary cloud costs and records validation evidence.
Completes the validation lifecycle securely and cleanly.

Key Concept

Disaster Recovery Validation Procedures
Estimated Time:1m 30s
Question 111Question →

Your Cloud Operations team is preparing to execute a blue-green release strategy for an application update on Google Cloud that includes a database schema change. To ensure zero downtime and maintain backward compatibility throughout the release, in what sequence should you perform the following operational steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: first, apply backward-compatible database schema migrations; second, deploy the updated application revision to the Green environment; third, update Cloud Load Balancing to route traffic to the Green environment; and fourth, decommission the legacy Blue environment infrastructure after stability confirmation.
In a zero-downtime blue-green deployment involving a shared database, schema changes must always be executed first and designed to be backward-compatible. This ensures that the active Blue environment remains fully functional. Once the schema supports both releases, the new code can be safely deployed into the Green environment for validation. After passing health checks, load balancer routing is updated to direct traffic to Green. Finally, after a period of stable monitoring, the legacy Blue infrastructure is safely decommissioned.

Step-by-Step Solution

1
Execute additive, backward-compatible database migrations on the existing database instance.
The database schema supports both old and new application code versions concurrently.
Applying non-breaking schema updates first prevents downtime or database exceptions on the live Blue instances.
2
Provision and deploy the new application code release into the inactive Green environment.
The Green environment is fully staged and ready for internal testing.
Isolating the new version allows automated integration and health checks without affecting live users.
3
Reconfigure Cloud Load Balancing backend service settings to shift 100% of user traffic to the Green backend.
Production traffic instantly flows to the Green application release.
Load balancer traffic shifting enables an instantaneous cutover with quick rollback capability if errors spike.
4
Monitor operational metrics and decommission the original Blue environment resource group once stability is verified.
Legacy resources are cleaned up, leaving only the active Green environment.
Teardown of legacy resources completes the deployment process and avoids unnecessary cloud infrastructure costs.

Key Concept

Zero-Downtime Blue-Green Deployment Lifecycle with Database Migration Coordination
Question 112Question →

An enterprise financial technology platform requires a highly secure, automated continuous integration and deployment pipeline for containerized microservices running on Google Kubernetes Engine (GKE). The security policy strictly dictates that all artifacts must pass automated container scanning, have a Cryptographic Build Attestation signed by Cloud KMS, pass Binary Authorization policy checks, and follow a controlled canary release pattern using Cloud Deploy with automated metric validation. In what chronological sequence must the pipeline execute these operations from source code push to full release?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct end-to-end pipeline ordering is: (1) Image build, Artifact Registry push, and vulnerability scanning, (2) Cryptographic Binary Authorization attestation signing via Cloud KMS, (3) Cloud Deploy release to staging with Binary Authorization signature verification, (4) Cloud Deploy canary rollout in production with telemetry monitoring, and (5) Promotion to 100% production traffic.
The proper secure CI/CD pipeline progression establishes software supply chain security first (building, vulnerability scanning, and signing attestations via Cloud KMS), followed by environment delivery execution (Binary Authorization verification during deployment via Cloud Deploy to staging), and concludes with controlled progressive deployment (canary traffic split and monitoring evaluation prior to 100% promotion).

Step-by-Step Solution

1
Build container image and complete vulnerability scan in Artifact Registry.
Immutable container digest is generated and verified clear of critical security vulnerabilities.
Container digest immobilizes code state, which is mandatory before cryptographically attesting security compliance.
2
Generate and sign Binary Authorization attestation with Cloud KMS.
Container digest is linked to a signed security attestation stored in Container Analysis.
Attestations prove build integrity and scan compliance prior to target cluster deployment authorization.
3
Deploy release candidate to Staging environment using Cloud Deploy.
GKE Binary Authorization admission controller verifies KMS signature before allowing container creation.
Enforcing policy on staging guarantees that unvetted binaries are rejected before entering release pipelines.
4
Initiate Canary deployment phase to Production GKE environment via Cloud Deploy.
A controlled fraction of live user traffic reaches the new container while Cloud Monitoring evaluates SLO metrics.
Canary progression isolates potential runtime defects without risking complete service outage.
5
Promote release to 100% production traffic.
Full production environment updated successfully.
Final promotion completes the continuous delivery pipeline after empirical runtime telemetry validation.

Key Concept

Secure Software Supply Chain & Automated Release Pipeline Integration
Question 113Question →

A DevOps team is establishing a secure continuous delivery pipeline on Google Cloud to deploy microservices to Google Kubernetes Engine (GKE) using Cloud Build, Artifact Registry, Binary Authorization, and Cloud Deploy. Place the operational steps of the deployment pipeline in the correct chronological order from initial code commit to final production deployment.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological order of the CI/CD pipeline execution is: (1) Push source code to Git to trigger Cloud Build, (2) Execute tests, build the container image, and push it to Artifact Registry, (3) Perform vulnerability scanning and sign a Binary Authorization attestation, (4) Create a Cloud Deploy release to deploy the workload to the staging cluster under Binary Authorization policy enforcement, and (5) Promote the release rollout to the production cluster upon validation.
The deployment sequence follows secure software supply chain best practices on Google Cloud: Source control trigger -> Cloud Build artifact generation -> Binary Authorization attestation signing -> Staging deployment via Cloud Deploy -> Production promotion.

Step-by-Step Solution

1
Trigger continuous integration upon code commit.
Cloud Build pipeline execution is initiated by Git repository webhook integration.
CI pipelines begin with source code updates to validate changes early.
2
Build and store the container image.
Container image is compiled, verified via unit tests, and published to Google Cloud Artifact Registry.
Centralizing artifacts in Artifact Registry is required before vulnerability scanning or deployment can take place.
3
Enforce supply chain security via digital attestations.
Binary Authorization attestation is generated using Cloud KMS after security checks pass.
Binary Authorization policy mandates that container images carry valid signed attestations prior to cluster deployment.
4
Deploy workload to staging via Cloud Deploy.
Cloud Deploy creates a release and provisions the deployment into the staging GKE cluster.
Deploying to non-production environments first ensures runtime stability and validation before production promotion.
5
Promote release to production target.
Cloud Deploy executes the production deployment rollout.
Promoting through predefined target delivery pipelines guarantees progressive and reliable release management.

Key Concept

Continuous Integration and Continuous Delivery (CI/CD) Pipeline Design
Question 114Question →

An enterprise investment bank is modernizing its portfolio risk analytics platform on Google Cloud. You are serving as the Lead Cloud Architect responsible for translating business requirements into a complete cloud solution architecture. In which chronological order should you execute the architectural design stages, from high-level domain mapping down to concrete GCP resource specification?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order follows the standard architecture design lifecycle: (1) Establish the Conceptual Architecture to capture business capabilities, (2) Develop the Logical Architecture to define functional components and data flows, (3) Map the Logical Architecture to Physical Architecture by selecting specific Google Cloud services, and (4) Detail the Physical Architecture implementation with concrete network, security, and resource parameters.
The standard architectural design process progresses systematically from business intent to concrete technical execution: Conceptual Architecture defines high-level business domain capabilities; Logical Architecture defines technology-neutral functional tiers and data flows; Physical Architecture service mapping selects specific GCP products; and Physical Architecture detailing establishes exact operational and security parameters for deployment.

Step-by-Step Solution

1
Identify the conceptual design phase.
Establish high-level business capabilities without technology lock-in.
Architecture starts with understanding business goals and domain boundaries at the conceptual level.
2
Identify the logical design phase.
Define technology-agnostic service tiers and interaction patterns.
Logical architecture structures the solution into functional modules and data flows based on conceptual requirements.
3
Identify the physical service selection phase.
Map logical tiers to concrete GCP services.
Physical design translates logical requirements into specific GCP products that satisfy SLA, throughput, and operational needs.
4
Identify the physical parameterization phase.
Configure concrete infrastructure parameters like subnet CIDRs, IAM bindings, and CMEK settings.
Final deployment readiness requires explicit configuration of network topologies, access rules, and security keys.

Key Concept

Sequential architectural translation from conceptual model (business focus) to logical model (functional tiers) to physical model (GCP product selection and explicit parameterization).
Question 115Question →

An enterprise security architect is transitioning an external CI/CD pipeline hosted on Azure DevOps from legacy static service account keys to short-lived federated credentials using Workload Identity Federation to securely access Secret Manager secrets.

In which sequential order should the architect execute the steps to configure this keyless authentication and authorization workflow?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins by creating the Workload Identity Pool and Provider, defining attribute mappings and conditions, assigning the workloadIdentityUser role to the external principal set on the target Service Account, granting the secretAccessor role to the Service Account on the secret, and finally executing the token exchange in the pipeline.
The sequence follows the logical dependency chain of Workload Identity Federation setup: first establishing trust via the Pool and Provider, defining mapped attribute conditions for security filtering, granting impersonation rights via workloadIdentityUser on the service account, granting least-privilege secret accessor permissions to the service account, and executing the client-side credential exchange.

Step-by-Step Solution

1
Establish the federated trust anchor by creating a Workload Identity Pool and an OIDC Provider.
Google Cloud STS is configured to accept tokens issued by the external Azure DevOps issuer.
You must create the pool and provider infrastructure before referencing them in attribute rules or IAM policy bindings.
2
Define attribute mappings and assertion conditions on the provider.
Claims from the Azure DevOps JWT are mapped to GCP principal attributes (e.g., google.subject, attribute.repository).
Attribute mappings establish fine-grained identity filters so only authorized repositories or environments can authenticate.
3
Bind roles/iam.workloadIdentityUser on the target Service Account to the mapped principal set.
The external workload identity is authorized to impersonate the specific GCP Service Account.
Workload Identity Federation relies on the workloadIdentityUser role on the service account resource to authorize impersonation.
4
Grant roles/secretmanager.secretAccessor to the GCP Service Account on the secret.
The Service Account gains least-privilege read access to Secret Manager secret versions.
The service account itself must possess resource-level authorization to read secret payloads.
5
Update the pipeline script to call the GCP Security Token Service (STS) and IAM Credentials API.
The pipeline acquires a short-lived access token and fetches secret values dynamically.
Credential exchange and secret fetching can only succeed after all underlying IAM roles and trust relationships are provisioned.

Key Concept

Workload Identity Federation and Service Account Lifecycle Security
Question 116Question →

An enterprise financial organization is establishing an automated testing and validation procedure for a high-throughput transaction microservice on Google Kubernetes Engine (GKE). The Cloud Architect must define a sequential validation procedure that ensures static configuration integrity, resource quota readiness, synthetic performance compliance, and production canary safety. In what chronological sequence should the cloud team execute these validation steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: static analysis and dry-run plan execution, followed by resource quota and security perimeter verification, then ephemeral cluster provisioning for synthetic SLO load testing, and finally canary deployment with error budget monitoring.
Technical solution validation follows a progressive risk-reduction sequence. First, static IaC analysis verifies configuration correctness without resource cost. Second, environmental prerequisites (GCP quotas and VPC SC perimeters) are verified to ensure execution readiness. Third, ephemeral staging environments are provisioned for synthetic load and SLO testing. Finally, canary deployments validate production behavior under real user traffic.

Step-by-Step Solution

1
Perform static analysis and dry-run checks on IaC configurations.
Identifies syntax errors and security policy non-compliance without instantiating GCP resources.
Static checks are fast, low-cost, and catch syntax or compliance failures before cloud resource allocation.
2
Check regional quotas and VPC Service Controls boundaries.
Ensures the target project environment has sufficient CPU/IP quotas and compliant network perimeters.
Verifying quota availability prevents provisioning failures during downstream automated cluster scaling.
3
Provision temporary staging infrastructure for synthetic load testing.
Validates application performance metrics and system stability against defined SLOs under heavy load.
Synthetic stress testing proves performance compliance in an isolated setting before introducing production traffic.
4
Execute canary deployment in production with phased traffic routing.
Validates real-world behavior and error budget consumption under production conditions.
Canary deployment provides the ultimate validation step with minimal risk exposure prior to full release.

Key Concept

Developing Sequential Infrastructure and Solution Validation Procedures
Question 117Question →

Your organization is executing a major application update for a mission-critical microservice running on Google Kubernetes Engine (GKE). The release requires a non-backward-compatible database schema change. To meet business requirements of zero downtime and zero data loss, your architecture team chose an Expand-Contract deployment pattern combined with a Blue-Green release traffic shift via GKE Gateway API HTTPRoute resources. Arrange the operational steps below in the correct logical execution sequence from start to finish.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with applying additive, non-breaking database schema changes (Expand phase), followed by deploying the Green workload to GKE with zero traffic, executing data backfill and synchronization scripts, updating the GKE Gateway HTTPRoute to switch production traffic to Green, and finally removing the legacy Blue workload and deleting deprecated database schema elements (Contract phase).
The correct operational sequence follows the Expand-Contract database pattern paired with Blue-Green traffic routing. First, the database schema must be expanded additively so existing Blue instances remain functional. Second, the Green application is deployed with zero traffic to isolate verification. Third, data backfill and dual-writing occur to synchronize historical data. Fourth, traffic is shifted to Green via GKE Gateway HTTPRoute configuration. Finally, after confirming operational stability, legacy Blue deployment resources are removed and deprecated database columns are dropped during the Contract phase.

Step-by-Step Solution

1
Expand Database Schema
Database supports both old and new schema requirements without breaking the active Blue deployment.
Prevents downtime for current Blue pods while preparing the data layer for Green pods.
2
Deploy Green Workload to GKE
Green pods are running and pass health checks, but receive 0% live traffic.
Allows verification of application startup and connectivity without exposing end users to unvalidated code.
3
Perform Data Backfill & Synchronization
Historical and active data are fully synchronized across expanded schema columns.
Guarantees zero data loss or data corruption when users switch to the Green version.
4
Shift Ingress Traffic to Green
GKE Gateway API HTTPRoute directs 100% of user traffic to Green pods.
Executes the zero-downtime cutover to the new application revision.
5
Contract Phase & Legacy Cleanup
Deprecated database fields are dropped and legacy Blue GKE resources are terminated.
Frees cluster resources and finalizes the schema refactoring safely after stability verification.

Key Concept

Expand-Contract Database Migration with Blue-Green Traffic Shifting
Question 118Question →

Your Cloud Operations team is designing an automated deployment pipeline for a high-availability microservice hosted on Google Kubernetes Engine (GKE) using GKE Enterprise Service Mesh and Cloud SQL. The application update introduces a database schema change. To ensure zero-downtime and preserve the service error budget, you must execute a canary release pattern using the expand-contract strategy.

Arrange the following steps in the correct chronological sequence to execute this release strategy safely.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with applying backwards-compatible database schema expansion to Cloud SQL, deploying candidate (v2) pods to GKE without external traffic, configuring the Service Mesh VirtualService for a 5% canary split, monitoring SLIs and error budgets during soak, and finally promoting v2 to 100% traffic while executing the database contract phase.
Safely deploying application updates with database changes requires decoupling schema expansion from schema contraction. Expanding the schema first ensures backwards compatibility for legacy v1 instances. Once v2 workload pods are provisioned on GKE, canary traffic splitting via Service Mesh allows real-time telemetry observation. After verifying SLI health, shifting 100% of traffic and executing the contract phase completes the zero-downtime release.

Step-by-Step Solution

1
Database Schema Expansion
Cloud SQL accepts queries from both v1 and v2 software versions without failure.
Applying non-breaking database schema changes (expand phase) ensures running v1 application instances continue operating without downtime when v2 is deployed.
2
Deploy Candidate Workload
v2 pods pass health checks on GKE while v1 continues handling 100% of live traffic.
Candidate containers must be provisioned and healthy before receiving live user requests.
3
Configure Service Mesh Canary Traffic Split
5% of inbound requests route to v2 pods and 95% continue to v1 pods.
Declarative traffic splitting via Service Mesh enables fine-grained exposure to test v2 under real user conditions.
4
SLI and Error Budget Soak Monitoring
Performance and reliability metrics confirm no regressions on the canary deployment.
Automated telemetry analysis ensures issue detection before exposing the full user base.
5
Full Promotion and Schema Contracting
100% of traffic routes to v2, v1 is retired, and legacy database structures are safely removed.
The contract phase finishes the release lifecycle after v1 is fully drained and retired.

Key Concept

Expand-Contract Database Migration in Canary Deployments
Question 119Question →

An enterprise security policy prohibits the use of downloadable JSON service account keys on developer workstations. A developer needs to run a local Python application that uses Google Cloud Client Libraries to query BigQuery tables in Project-B using a target service account (`[email protected]`).

Arrange the following operational steps in the correct chronological order to configure local credentials and execute the application using Google Cloud best practices for service account impersonation.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct workflow starts by authenticating the developer's identity with gcloud auth login, granting the Service Account Token Creator role on the target service account, initializing Application Default Credentials (ADC) with the service account impersonation flag, and finally executing the Python SDK application.
Proper setup of programmatic GCP interaction using service account impersonation requires authenticating the user identity first, delegating token creation privileges via roles/iam.serviceAccountTokenCreator on the target service account, generating impersonated Application Default Credentials locally, and finally running the SDK code which seamlessly picks up the ADC credentials.

Step-by-Step Solution

1
Authenticate user identity
Initializes active user credentials in gcloud CLI.
Service account impersonation requires an authenticated user identity to authorize the token generation request.
2
Assign IAM Token Creator role
User receives permission to impersonate the target service account.
Without roles/iam.serviceAccountTokenCreator granted on the service account, the gcloud ADC impersonation call will fail with a 403 Forbidden error.
3
Create impersonated Application Default Credentials
Creates a local ADC credential file pointing to the target service account.
Application Default Credentials allow Google Cloud Client Libraries to transparently acquire short-lived tokens without storing permanent keys.
4
Run the SDK application
Application authenticates as sa-b and successfully queries BigQuery.
Client libraries automatically resolve ADC from default environment paths and handle token lifecycle management implicitly.

Key Concept

Service account impersonation and Application Default Credentials (ADC) configuration
Question 120Question →

A Cloud Architect is auditing permission inheritance for a team accessing data inside Google Cloud. Arrange the levels of the Google Cloud resource hierarchy in order from the highest scope of IAM policy inheritance (broadest level) to the most granular scope of IAM policy inheritance (lowest level).

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct evaluation order from broadest scope of inheritance to most granular scope is Organization Node Level, followed by Folder Level, Project Level, and finally Resource Level.
Google Cloud IAM follows a strict top-down resource hierarchy inheritance model: Organization -> Folder -> Project -> Resource. Permissions granted at a parent level automatically inherit down to all descendant nodes and cannot be restricted by lower-level policies.

Step-by-Step Solution

1
Identify the root container of the GCP resource hierarchy.
The Organization node is the root container.
IAM bindings at the Organization level apply globally across all sub-nodes.
2
Identify intermediate grouping structures beneath the Organization.
Folders act as intermediate grouping mechanisms.
Folders allow administrative isolation and IAM policy inheritance across groups of projects.
3
Identify the project container level.
Projects are the primary organizational units for resources.
IAM roles granted at the project level inherit down to all service instances inside that project.
4
Identify individual service resource nodes.
Individual resources form the leaves of the hierarchy tree.
Resource-level IAM policies (where supported, like Cloud Storage buckets) apply directly to that specific asset.

Key Concept

IAM policy inheritance down the Google Cloud Resource Hierarchy
PreviousPage 6 / 9Next
All practice questions — Google Cloud Professional Cloud Architect | Examkin