CCNA Managing and Provisioning a Solution Infrastructure Questions — Page 2 of 2

MCQmedium

A cloud architect is designing a CI/CD pipeline for a microservices application. Each service is deployed to Cloud Run. They want to use Cloud Build to automate building and deploying services only when changes occur in their respective directories. Which Cloud Build feature should they configure?

A.Build steps in cloudbuild.yaml

B.Build triggers with included files filter

C.Cloud Build's 'includedFiles' option in the build configuration

D.Artifact Registry triggers

AnswerB

Cloud Build triggers support an included files filter, so a trigger fires only when commits touch paths matching the specified glob patterns. This satisfies the stem's requirement to build and deploy each service only when its own directory changes, avoiding unnecessary builds.

Why this answer

Build triggers with an included files filter is correct because Cloud Build triggers support an 'includedFiles' field that uses glob patterns to fire a build only when files in specified paths change. This lets a monorepo deploy each microservice independently — for example, a trigger scoped to 'services/payments/**' runs only when payment-service code is modified. This is the native, supported mechanism for path-based CI/CD in Cloud Build.

Exam trap

The trap is confusing build configuration (what runs) with trigger configuration (when it runs) — candidates pick 'includedFiles in cloudbuild.yaml' because the name sounds right, but the filter belongs on the trigger.

How to eliminate wrong answers

Option A is wrong because build steps in cloudbuild.yaml define what the build does, not when it runs — they cannot by themselves restrict execution to changes in specific directories. Option C is wrong because 'includedFiles' is a property of a build trigger, not a standalone option inside the build configuration file; placing it in cloudbuild.yaml has no effect. Option D is wrong because Artifact Registry triggers do not exist as a Cloud Build trigger type — Artifact Registry stores and scans artifacts, it does not initiate builds based on source changes.

Practice this question →

MCQmedium

A team wants to collect and analyze logs from multiple projects into a centralized BigQuery dataset for long-term retention and SQL querying. They want to exclude health check logs to reduce costs. Which approach should they use?

A.Use Cloud Monitoring to exclude health check logs

B.Create a log metric for health check logs and filter in BigQuery

C.Create a log sink to BigQuery and add a log exclusion filter for health check logs

D.Set up a Cloud Function to delete health check logs from BigQuery

AnswerC

A BigQuery log sink routes selected log entries into a dataset for SQL querying and retention, while an exclusion filter drops health check entries before ingestion. It satisfies both the centralisation and cost-reduction constraints in the stem.

Why this answer

A log sink routes log entries from Cloud Logging to a destination such as BigQuery, and an exclusion filter on the sink prevents matching entries (health check logs) from being exported, reducing cost. This is the native, supported way to centralize logs in BigQuery while filtering out unwanted entries at the source. The sink can be created at the organization or folder level to aggregate multiple projects.

Exam trap

PCA often tests the difference between log metrics and log sinks; candidates mistakenly think a log metric can exclude logs from export, but only a sink exclusion filter prevents export.

How to eliminate wrong answers

Option A is wrong because Cloud Monitoring is for metrics and alerting, not for excluding logs from export; it cannot filter logs destined for BigQuery. Option B is wrong because a log metric does not remove logs from export; it only creates a metric, and filtering in BigQuery after ingestion still incurs storage and query costs. Option D is wrong because a Cloud Function that deletes logs from BigQuery is an anti-pattern: it adds latency, cost, and complexity, and does not prevent the logs from being written in the first place.

Practice this question →

Multi-Selectmedium

A data engineering team wants to ingest streaming data from Pub/Sub, transform it using Apache Beam, and load it into BigQuery for real-time analytics. They need a fully managed solution that handles autoscaling and does not require managing servers. Which TWO Google Cloud services should they use?

Select 2 answers

A.Cloud Dataproc

B.Cloud Dataflow

C.Cloud Dataprep

D.Cloud Composer

E.Cloud Pub/Sub

AnswersB, E

Cloud Dataflow is the fully managed, serverless runner for Apache Beam pipelines, providing the autoscaling the team requires. It executes the transform stage and writes results into BigQuery, so no compute infrastructure needs provisioning or management.

Why this answer

Option B, Cloud Dataflow, is correct because it is Google Cloud's fully managed, serverless runner for Apache Beam pipelines, automatically handling autoscaling of worker instances and eliminating server management for the transform-and-load stage into BigQuery. Option E, Cloud Pub/Sub, is correct because it is the fully managed, serverless messaging service used to ingest the streaming data that Dataflow then reads and processes. Together, Pub/Sub provides the ingestion layer and Dataflow provides the managed Beam processing that writes results to BigQuery for real-time analytics.

Option A, Cloud Dataproc, is not appropriate because it is a managed Spark/Hadoop cluster service that still requires cluster provisioning and management rather than being serverless. Option C, Cloud Dataprep, is a data-wrangling UI for preparing data, not a streaming Beam execution engine. Option D, Cloud Composer, is a managed Apache Airflow workflow orchestrator for scheduling batch pipelines, not a streaming data processing service.

Exam trap

PCA often tests the difference between Dataflow (serverless Beam) and Dataproc (managed Spark/Hadoop), catching candidates who assume any data processing service is serverless.

Practice this question →

MCQmedium

A company uses Cloud Deploy for continuous delivery. They have a delivery pipeline with multiple targets: dev, staging, and prod. They want to require manual approval before deploying to prod. How should they configure this?

A.Add a Cloud Build trigger that pauses and waits for approval

B.Use IAM conditions to restrict deployment to prod

C.Configure an approval gate on the prod target in the delivery pipeline

D.Set up a Pub/Sub notification and a Cloud Function to approve

AnswerC

Approval gates are defined per target within the delivery pipeline, pausing a rollout before it advances. Placing a gate on the prod target blocks promotion until a human approves, satisfying the manual-approval constraint without altering dev or staging.

Why this answer

Google Cloud Deploy supports approval gates on targets, which pause a rollout and require manual approval before proceeding to the next target. Configuring an approval gate on the prod target in the delivery pipeline enforces the manual approval requirement natively.

Exam trap

The trap is overcomplicating the solution with custom Pub/Sub or Cloud Functions, when Cloud Deploy has a native approval gate feature on targets.

How to eliminate wrong answers

Option A is wrong because Cloud Build triggers are for building and testing, not for gating deployments; using a trigger to pause would be a custom workaround, not the intended mechanism. Option B is wrong because IAM conditions restrict who can perform actions but do not provide a manual approval step in the deployment flow. Option D is wrong because Pub/Sub and Cloud Functions could be used to build a custom approval system, but Cloud Deploy already provides a built-in approval gate, making this unnecessarily complex.

Practice this question →

Multi-Selectmedium

A logistics company is deploying a new three-tier application on Google Cloud. The architecture team must choose a managed database for the order-processing tier that provides automatic failover across zones with no application connection string changes, and they must also ensure that the database can scale read traffic independently of writes. (Choose two.)

Select 2 answers

A.Use Cloud SQL for PostgreSQL with a regional instance and a high-availability configuration.

B.Attach read replicas to the Cloud SQL instance to serve read-heavy reporting queries.

C.Use a Memorystore for Redis instance as the primary order database and persist snapshots to Cloud Storage.

D.Use Cloud SQL for MySQL with a single-zone instance and configure a read replica in another zone for failover.

E.Use Cloud Spanner with a regional configuration and rely on its built-in replication for failover.

AnswersA, B

A regional Cloud SQL instance maintains a standby in a second zone and performs automatic failover to it if the primary zone fails, while the application keeps using the same connection endpoint. This satisfies the automatic cross-zone failover and no connection string change requirement, and read replicas can be added separately to offload read traffic.

Why this answer

A regional Cloud SQL instance with high availability keeps a standby in a second zone and fails over automatically while the application continues using the same connection endpoint. Adding read replicas lets reporting and read-heavy queries run against separate copies, scaling reads independently of writes. Together these two choices meet the failover, connection stability, and read-scaling requirements without over-engineering the deployment.

Exam trap

The trap here is confusing asynchronous read replicas with a synchronous high-availability standby, so a replica is mistakenly treated as an automatic failover target.

Practice this question →

MCQhard

An organization wants to export their Cloud Logging logs to a centralized BigQuery dataset for long-term analysis. They also need to exclude logs from a specific source (e.g., a test project) to reduce costs. How should they set this up?

A.Disable logging in the test project

B.Create a log sink to BigQuery and add a log exclusion filter that excludes the test project's logs

C.Create two separate sinks: one for production logs to BigQuery and another for test logs to Cloud Storage

D.Create a log sink to BigQuery and use IAM to restrict access to the test project's logs

AnswerB

A log sink routes matching entries to the BigQuery dataset, while the exclusion filter prevents the test project's logs from being exported at all, so they are never billed for BigQuery ingestion or storage. Both the destination and the cost-reducing exclusion are satisfied in one sink configuration.

Why this answer

A log sink to BigQuery with an exclusion filter is the correct way to export logs to a centralized dataset while excluding logs from a specific source. The exclusion filter is applied at the sink level, so logs from the test project are not exported, reducing costs. This setup can be created at the organization level to aggregate logs from multiple projects.

Exam trap

The trap is thinking that IAM or separate sinks can exclude logs from export; only a sink exclusion filter prevents logs from being written to the destination, which is what reduces cost.

How to eliminate wrong answers

Option A is wrong because disabling logging in the test project stops all logging there, which may be undesirable and does not centralize logs. Option B is wrong because creating two separate sinks does not exclude test logs from BigQuery; it just routes them elsewhere, and the question asks to exclude them to reduce costs. Option D is wrong because IAM restricts access to logs but does not prevent them from being exported and stored in BigQuery, so costs are not reduced.

Practice this question →

Multi-Selecteasy

A cloud architect needs to implement a CI/CD pipeline for a team developing a Python-based microservice. The team uses GitHub as their source repository. The pipeline should automatically run unit tests and deploy the service to Cloud Run when changes are pushed to the main branch. Which THREE Google Cloud services should they use?

Select 3 answers

A.Artifact Registry

B.Cloud Run

C.Cloud Deploy

D.Cloud Source Repositories

E.Cloud Build

AnswersA, B, E

Artifact Registry stores the container images built from the Python microservice, providing the repository Cloud Run pulls from during deployment. It satisfies the pipeline's need for a managed Docker image store integrated with Cloud Build, distinct from source hosting in GitHub and from Cloud Run's runtime itself.

Why this answer

Cloud Build (E) is the correct CI/CD engine here: it can be triggered by GitHub pushes to the main branch, run the Python unit tests in a build step, and then deploy the resulting container to Cloud Run. Artifact Registry (A) is needed to store and version the container images that Cloud Build builds, since Cloud Run pulls its images from a registry rather than building them itself. Cloud Run (B) is the target compute platform for the microservice, hosting the containerized Python service that the pipeline deploys.

Cloud Deploy (C) is not required because it is a managed continuous-delivery service for GKE and Cloud Run that adds release/pipeline abstractions, which is unnecessary for this simple test-and-deploy flow. Cloud Source Repositories (D) does not belong because the team already uses GitHub as its source repository, so a second Google-hosted Git repo is redundant.

Exam trap

PCA often tests whether candidates over-engineer the pipeline by including Cloud Deploy or Cloud Source Repositories — the trap is adding tools that are not required for the stated GitHub-to-Cloud-Run flow.

Practice this question →

MCQmedium

A company uses Cloud Deployment Manager to manage infrastructure. They want to roll back to a previous deployment state after a failed update. What is the recommended approach?

A.Use gcloud deployment-manager deployments rollback --deployment <name>

B.Use the --update-policy=PARTIAL flag to selectively revert changes

C.Delete the deployment and recreate it from the previous template

D.Run gcloud deployment-manager deployments update --config <previous_manifest>

AnswerD

Redeploying the previous manifest restores the last known-good configuration, satisfying the rollback requirement after a failed update. Deployment Manager is declarative, so reapplying the prior manifest reconciles resources back to that state rather than attempting an in-place undo.

Why this answer

Cloud Deployment Manager does not provide a native rollback command; the documented way to revert to a prior state is to re-run an update using the previous configuration and manifest files. Running 'gcloud deployment-manager deployments update --config <previous_manifest>' reapplies the earlier desired state, effectively rolling the deployment back to that point.

Exam trap

PCA often tests whether candidates invent CLI subcommands — the trap is assuming a 'rollback' verb exists because other tools have one, when Deployment Manager requires re-applying a prior manifest.

How to eliminate wrong answers

Option A is wrong because there is no 'rollback' subcommand in the gcloud deployment-manager CLI — this command does not exist and would fail. Option B is wrong because '--update-policy=PARTIAL' is not a valid rollback mechanism; update policies control how resources are previewed or applied, not how to revert to a prior state. Option C is wrong because deleting and recreating the deployment destroys resource history and can cause downtime or orphaned resources, and it is not the recommended approach.

Practice this question →

Multi-Selectmedium

A team is building a CI/CD pipeline for a Java application that will run on GKE. They want to automatically build the application, run unit tests, create a Docker image, push it to Artifact Registry, and deploy to GKE. Which two GCP services should be combined? (Choose two.)

Select 2 answers

A.Cloud Functions

B.Compute Engine

C.Cloud Run

D.Cloud Deploy

E.Cloud Build

AnswersD, E

Cloud Deploy provides the managed continuous delivery layer that handles progressive rollout of the containerised Java application to GKE clusters, satisfying the deployment stage of the pipeline after the image is pushed to Artifact Registry.

Why this answer

Cloud Build (E) is the correct service for the build-and-test stage: it can compile the Java application, run unit tests, build the Docker image, and push it to Artifact Registry as part of a CI pipeline defined in cloudbuild.yaml. Cloud Deploy (D) is the correct service for the delivery/deployment stage: it is a managed continuous delivery service that takes the built image and progressively deploys it to GKE targets (with rollout and approval controls). Together, Cloud Build handles CI and Cloud Deploy handles CD to GKE, matching the requested pipeline.

Cloud Functions (A) is for event-driven serverless functions, not container image builds or GKE deployments. Compute Engine (B) provides VMs and is not the managed CI/CD service needed here. Cloud Run (C) runs containerized services serverlessly but does not build images or deploy workloads to GKE.

Practice this question →