CCNA Deploying applications Questions — Page 2 of 2

MCQmedium

A company has a monolithic application that needs to be migrated to Cloud Run. The application currently writes logs to a local file. What is the best practice for handling logs in Cloud Run?

A.Use a third-party logging agent installed in the container image.

B.Write logs to stdout and stderr; Cloud Run automatically sends them to Cloud Logging.

C.Use a sidecar container to ship logs to Stackdriver.

D.Continue writing to a local file; Cloud Run will persist it.

AnswerB

Cloud Run collects stdout and stderr and sends them to Cloud Logging.

Why this answer

Cloud Run is a serverless compute platform that automatically integrates with Cloud Logging. The best practice is to write logs to stdout and stderr because Cloud Run's runtime captures these streams and forwards them to Cloud Logging without any additional agents or sidecars. This approach aligns with the 12-factor app methodology and ensures logs are available for monitoring and troubleshooting.

Exam trap

The trap here is that candidates may overcomplicate the solution by thinking a logging agent or sidecar is needed, when Cloud Run's serverless model already provides automatic log ingestion from stdout/stderr, and they may forget that the local filesystem is ephemeral and not suitable for persistent log storage.

How to eliminate wrong answers

Option A is wrong because installing a third-party logging agent in the container image adds unnecessary complexity and overhead; Cloud Run natively handles log collection from stdout/stderr, making agents redundant. Option C is wrong because sidecar containers are not supported in Cloud Run (it runs a single container per revision) and would violate the serverless architecture; log shipping should rely on the built-in stdout/stderr mechanism. Option D is wrong because Cloud Run provides ephemeral filesystem storage that is not persisted across instances or after the container stops; writing to a local file would cause logs to be lost and not be available in Cloud Logging.

Practice this question →

MCQmedium

You deployed a microservice on Cloud Run. Users report intermittent 503 errors. The service uses Cloud SQL with connection pooling. What is the most likely cause?

A.The service is not using a VPC connector for Cloud SQL access.

B.The connection pool is drained due to CPU throttling on Cloud Run.

C.The Cloud SQL auth proxy is not configured.

D.The Cloud Run service name is not resolvable via Cloud DNS.

AnswerB

When no requests, CPU is throttled, causing idle connections to be dropped by the database.

Why this answer

When Cloud Run CPU throttling occurs (e.g., during cold starts or when the instance is processing requests beyond its allocated CPU), the connection pool can become drained because existing connections are held open while new requests cannot be processed. This leads to intermittent 503 errors as the service cannot establish new database connections or respond to incoming requests in time. Connection pooling does not protect against CPU throttling; it only manages database connections efficiently.

Exam trap

The PCD exam often tests the misconception that 503 errors from Cloud Run are always due to database connectivity issues (like missing auth proxy or VPC), when in fact CPU throttling and connection pool exhaustion are the primary causes in serverless environments.

How to eliminate wrong answers

Option A is wrong because a VPC connector is not required for Cloud SQL access when using the Cloud SQL proxy or private IP; 503 errors are not typically caused by missing VPC connectors. Option C is wrong because the Cloud SQL auth proxy is a recommended method for secure access but its absence would cause persistent connection failures, not intermittent 503 errors. Option D is wrong because Cloud Run service names are resolved internally by Google Cloud's DNS and are not related to Cloud SQL connectivity or 503 errors.

Practice this question →

Multi-Selecthard

Which TWO statements about deploying applications on Google Kubernetes Engine (GKE) are correct?

Select 2 answers

A.HorizontalPodAutoscaler can use custom metrics from Cloud Monitoring.

B.Kubernetes Secrets are encrypted at rest by default.

C.A zonal GKE cluster automatically uses regional persistent disks for high availability.

D.PodDisruptionBudget can be used to ensure a minimum number of pods are available during node repair.

E.To expose a Deployment externally, you must create an Ingress resource.

AnswersA, D

HPA supports custom metrics via the custom.metrics.k8s.io API.

Why this answer

HorizontalPodAutoscaler (HPA) in GKE can scale pods based on custom metrics from Cloud Monitoring (formerly Stackdriver). This is achieved by using the custom.metrics.k8s.io API, which allows HPA to query metrics like custom application latency or queue depth, not just default CPU/memory. This enables fine-grained, application-specific autoscaling.

Exam trap

The PCD exam often tests the misconception that Secrets are encrypted by default, but the trap here is that base64 encoding is not encryption, and candidates overlook the need for explicit encryption configuration.

Practice this question →

MCQhard

Your company runs a multi-tier application on GKE. The frontend is a Deployment with 5 replicas, backend is a StatefulSet with 3 replicas, and a database runs on Cloud SQL. Recently, after a cluster upgrade, the frontend pods are failing with 'Connection refused' errors when trying to reach the backend service. The backend pods are running and healthy. You have verified that the Service and Endpoints objects exist. The backend service is of type ClusterIP on port 8080, and the frontend uses the service name 'backend-svc'. The frontend pods are in a different namespace 'frontend-ns', while the backend is in 'backend-ns'. What is the most likely cause of the error?

A.The backend Service is not exposed via an Ingress, so it is not reachable from other namespaces.

B.The StatefulSet pods are not part of the backend Service's selector.

C.A NetworkPolicy is blocking traffic between the namespaces.

D.The frontend pods are not using the correct DNS name that includes the namespace.

AnswerD

Cross-namespace access requires the full DNS name.

Why this answer

When a frontend pod in namespace 'frontend-ns' uses the service name 'backend-svc' to reach a backend service in namespace 'backend-ns', the DNS resolution will only work if the fully qualified domain name (FQDN) is used: 'backend-svc.backend-ns.svc.cluster.local'. Without the namespace qualifier, the DNS query resolves to a non-existent service in the same namespace, causing 'Connection refused'. Option A is incorrect because ClusterIP services are accessible cluster-wide provided the correct DNS name is used; an Ingress is not required.

Option B is incorrect because we verified that Endpoints exist for the backend service, indicating the StatefulSet pods are correctly selected. Option C is incorrect because a NetworkPolicy blocking traffic would typically result in a timeout or no route, not an immediate 'Connection refused'; the error here is due to DNS resolution to a nonexistent endpoint.

Practice this question →

Multi-Selecteasy

Which TWO Google Cloud services are suitable for deploying serverless applications that scale automatically based on demand?

Select 2 answers

A.Cloud Storage.

B.Google Kubernetes Engine.

C.Cloud Functions.

D.Compute Engine with managed instance groups.

E.Cloud Run.

AnswersC, E

Fully managed, event-driven serverless compute.

Why this answer

Cloud Functions (option C) is a serverless execution environment that automatically scales instances from zero to thousands in response to event triggers, such as HTTP requests or Cloud Pub/Sub messages, without requiring any infrastructure management. Cloud Run (option E) is a managed compute platform that runs stateless containers in a fully serverless manner, scaling each revision automatically based on incoming request concurrency (up to 80 concurrent requests per container instance by default). Both services abstract away underlying servers and scale to zero when idle, making them ideal for serverless applications.

Exam trap

The trap is that any autoscaling service might be mistaken for serverless, but Compute Engine with managed instance groups (option D) autoscales yet still requires managing underlying VMs, making it IaaS, not serverless.

Practice this question →

MCQhard

A team deploys a microservices architecture on GKE with Istio service mesh. They want to enforce mutual TLS (mTLS) between services. After enabling Istio with the default configuration, some services report connection errors. What is the most likely cause?

A.The services need a ServiceEntry to communicate with each other.

B.The namespace is not labeled with istio-injection=enabled.

C.Some services do not have Istio sidecar injected, so strict mTLS fails.

D.The services are using a different service mesh protocol.

AnswerC

Strict mTLS requires all services to have sidecars to handle TLS.

Why this answer

Istio's default configuration enables 'STRICT' mTLS mode, which requires all services to have an Envoy sidecar proxy injected to handle TLS handshakes. If any service lacks the sidecar, it cannot participate in mTLS, causing connection errors when other services attempt to communicate with it using TLS. The error typically manifests as 'upstream connect error' or 'TLS handshake failure' in the sidecar logs.

Exam trap

The trap here is that candidates often assume the default Istio configuration uses PERMISSIVE mTLS (allowing both plaintext and TLS), but the actual default is STRICT, and they overlook the requirement that every service must have a sidecar for mTLS to work.

How to eliminate wrong answers

Option A is wrong because ServiceEntry is used to register external services (outside the mesh) for discovery and routing, not for internal service-to-service communication within the same mesh. Option B is wrong because while namespace labeling with 'istio-injection=enabled' is required for automatic sidecar injection, the question states Istio is already enabled with default configuration, implying injection is active; the issue is that some services were deployed before injection was enabled or were manually excluded. Option D is wrong because Istio uses a single service mesh protocol (based on Envoy and xDS APIs) for all traffic; different protocols like HTTP or gRPC are application-level and do not affect mTLS enforcement.

Practice this question →

MCQhard

A company is deploying a multi-region application on Cloud Run to serve global users. They want low latency and automatic failover. Which approach is best?

A.Deploy to multiple regions and use DNS round-robin.

B.Deploy to multiple Cloud Run regions behind an external HTTP(S) Load Balancer with global backend.

C.Use Cloud Run for Anthos on-premises.

D.Deploy to a single region and use Cloud CDN.

AnswerB

Global load balancer routes to nearest healthy region, providing low latency and automatic failover.

Why this answer

Deploying Cloud Run services across multiple regions behind an external HTTP(S) Load Balancer with a global backend provides both low latency (via Google's global anycast IP and nearest-region routing) and automatic failover (the load balancer health checks automatically route traffic away from unhealthy backends). This architecture uses the load balancer's global external backend service to direct requests to the closest healthy Cloud Run service, ensuring high availability and performance for global users.

Exam trap

The PCD exam often tests the misconception that DNS round-robin (Option A) is sufficient for automatic failover and low latency, but it lacks health-based routing and can cause prolonged outages due to client-side DNS caching.

How to eliminate wrong answers

Option A is wrong because DNS round-robin does not provide automatic failover; if a region goes down, clients may still receive the IP of the failed region until DNS TTL expires, and it cannot route based on latency or health. Option C is wrong because Cloud Run for Anthos on-premises is designed for on-premises deployments, not for serving global users with low latency and automatic failover across multiple cloud regions. Option D is wrong because deploying to a single region with Cloud CDN caches static content but does not provide automatic failover or low latency for dynamic API calls; if the single region fails, the entire application becomes unavailable.

Practice this question →

MCQeasy

A developer deploys the above app.yaml to App Engine standard environment. The deployment succeeds, but the application fails to connect to the database. What is the most likely reason?

A.The runtime 'python39' is not supported in App Engine standard environment.

B.The $PORT environment variable is not set in App Engine standard environment.

C.The application is trying to connect to a local database on localhost, which is not available in the App Engine sandbox.

D.The entrypoint command is incorrect because gunicorn is not allowed.

AnswerC

App Engine standard does not allow connections to localhost; use Cloud SQL.

Why this answer

In App Engine standard environment, applications run in a sandboxed environment that does not support connections to a local database on localhost. The application code is attempting to connect to a database at 127.0.0.1 or localhost, which is not available in the sandbox. Instead, the application must connect to a Cloud SQL instance using a Unix socket or a private IP, or use a fully managed database service like Firestore.

Exam trap

The PCD exam often tests the misconception that localhost connections are available in App Engine standard environment, leading candidates to overlook the sandbox restrictions and incorrectly assume the issue is with runtime support or environment variables.

How to eliminate wrong answers

Option A is wrong because runtime 'python39' is fully supported in App Engine standard environment; Python 3.9 is a valid runtime. Option B is wrong because the $PORT environment variable is automatically set by App Engine standard environment and is used by the entrypoint (e.g., gunicorn) to bind the server; it is not missing. Option D is wrong because gunicorn is allowed in App Engine standard environment for Python runtimes; the entrypoint command using gunicorn is correct and commonly used.

Practice this question →

MCQmedium

A company has a multi-region deployment on GKE and needs to route traffic to the closest regional cluster based on user location. They want to minimize latency. Which approach should they use?

A.Use a global external HTTP(S) Load Balancer with backend services pointing to NEGs in each region.

B.Create separate internal load balancers in each region and use Cloud DNS geo-routing.

C.Configure an external TCP/UDP Network Load Balancer in each region and use Cloud DNS geo-routing.

D.Deploy a single regional cluster and use Cloud CDN to cache content globally.

AnswerA

Global LB with NEGs can route to the nearest backend based on client geography.

Why this answer

A global external HTTP(S) Load Balancer uses Anycast IP addresses and is backed by backend services that reference Network Endpoint Groups (NEGs) in each regional GKE cluster. This allows the load balancer to direct traffic to the closest healthy backend based on the user's geographic location and the load balancer's proximity algorithm, minimizing latency without requiring DNS-based routing.

Exam trap

The PCD exam often tests the misconception that DNS-based geo-routing (e.g., Cloud DNS geo-routing) is the optimal solution for global traffic steering, but the trap here is that DNS-based methods suffer from client-side caching and lack the sub-second failover and true anycast proximity of a global load balancer with NEGs.

How to eliminate wrong answers

Option B is wrong because internal load balancers are only reachable from within the same VPC network and cannot serve external user traffic; Cloud DNS geo-routing would still require public endpoints and does not provide the same anycast-based proximity optimization. Option C is wrong because external TCP/UDP Network Load Balancers are regional, not global, and using multiple regional load balancers with DNS geo-routing introduces DNS caching and failover delays, and lacks the single anycast IP and automatic failover of a global load balancer. Option D is wrong because a single regional cluster cannot minimize latency for users far from that region, and Cloud CDN only caches static content, not dynamic application traffic, so it does not solve the need for low-latency routing to the closest cluster.

Practice this question →

MCQmedium

A developer runs the command above and receives the error. The developer has just been granted the 'roles/cloudbuild.builds.editor' role on the project. What is the most likely reason for the permission error?

A.The project ID 'my-project' does not exist or the developer typed it incorrectly.

B.The container registry (gcr.io) is incorrect; should use us.gcr.io.

C.The Cloud Build API is not enabled for the project.

D.The developer is using the wrong region; Cloud Build must be enabled per region.

AnswerC

Correct: If the API is not enabled, even with proper IAM roles, the call is denied.

Why this answer

The error occurs because the Cloud Build API has not been enabled for the project. Even with the 'roles/cloudbuild.builds.editor' IAM role, the Cloud Build service itself must be explicitly enabled via the Google Cloud Console or using the `gcloud services enable cloudbuild.googleapis.com` command. Without enabling the API, any attempt to run a build will fail with a permission error, as the service is not available to process the request.

Exam trap

The PCD exam often tests the distinction between IAM role assignments and API enablement, as candidates may assume that granting a role automatically enables the underlying service, which is not the case in Google Cloud.

How to eliminate wrong answers

Option A is wrong because if the project ID 'my-project' did not exist or was typed incorrectly, the error would typically indicate an invalid project ID or a 404 error, not a permission error. Option B is wrong because the container registry hostname (gcr.io) is correct for global access; using a regional registry like us.gcr.io would only be necessary for specific regional requirements or to reduce latency, and the error is not related to registry location. Option D is wrong because Cloud Build is a global service and does not need to be enabled per region; it operates at the project level and can be used in any region once the API is enabled.

Practice this question →

MCQhard

A team is deploying a critical microservice on GKE. They want to minimize risk by gradually shifting traffic from old to new version. They use a Deployment with a single Service. What deployment strategy should they implement?

A.Use a rolling update with maxSurge=1 and maxUnavailable=0.

B.Use a single Deployment with a readinessProbe that fails for the new version until ready.

C.Create two separate Deployments and switch the Service selector to the new version after testing.

D.Create two Deployments (stable and canary) with different numbers of replicas and use the same Service label.

AnswerD

Canary with multiple Deployments allows traffic splitting based on replica count.

Why this answer

It implements a canary deployment pattern on GKE: two separate Deployments (stable and canary) share the same Service label, allowing the Service to distribute traffic to both based on replica counts. This enables gradual traffic shifting by adjusting the number of canary replicas, minimizing risk while the new version is validated.

Exam trap

The PCD exam often tests the distinction between a rolling update (which is automatic and immediate) and a canary deployment (which requires manual or tool-driven replica scaling to control traffic percentage), leading candidates to mistakenly choose a rolling update option when gradual traffic shifting is explicitly required.

How to eliminate wrong answers

Option A is wrong because a rolling update with maxSurge=1 and maxUnavailable=0 shifts traffic automatically and immediately as pods are replaced, without a controlled gradual shift or the ability to hold traffic at a small percentage for validation. Option B is wrong because a readinessProbe that fails for the new version until ready would prevent the new version from receiving traffic at all, defeating the purpose of gradually shifting traffic; it does not enable a canary-style incremental rollout. Option C is wrong because switching the Service selector to the new version after testing causes an abrupt cutover, not a gradual traffic shift, and the old version becomes unreachable immediately.

Practice this question →

MCQeasy

A developer deploys a containerized application on Cloud Run. The application needs to access a Cloud SQL instance securely without exposing it to the internet. What is the best practice?

A.Whitelist the Cloud Run IP range in Cloud SQL authorized networks.

B.Use Cloud Run's VPC connector and configure private IP for Cloud SQL.

C.Use a Cloud SQL proxy sidecar container in the same pod.

D.Use Cloud NAT to route traffic.

AnswerB

This is the best practice for secure access.

Why this answer

Cloud Run services cannot directly connect to Cloud SQL using private IP without a VPC connector. The VPC connector allows Cloud Run to send traffic to a VPC network, where the Cloud SQL instance with a private IP resides, ensuring traffic never traverses the public internet. This is the recommended pattern for secure, low-latency access to Cloud SQL from serverless environments.

Exam trap

The PCD exam often tests the misconception that Cloud SQL proxy can be run as a sidecar in Cloud Run, but Cloud Run's single-container-per-instance model means the proxy must be bundled into the same container image or deployed as a separate service, not as a sidecar in the Kubernetes sense.

How to eliminate wrong answers

Option A is wrong because Cloud Run does not have a static, whitelistable IP range; its egress IPs are ephemeral and shared, making IP-based allowlisting unreliable and insecure. Option C is wrong because Cloud Run does not support sidecar containers in the same pod; it runs a single container per instance, and the Cloud SQL proxy must be deployed as a separate service or within the same container image, not as a sidecar. Option D is wrong because Cloud NAT is used for outbound internet access from private VMs, not for routing traffic to Cloud SQL private IP; it does not enable connectivity from serverless services like Cloud Run to a VPC.

Practice this question →

MCQeasy

A developer wants to automatically deploy a new version of an application to App Engine Standard every time code is pushed to the main branch of a Cloud Source Repositories repository. Which service should be used?

A.Cloud Build

B.Cloud Run

C.Cloud Scheduler

D.Cloud Deploy

AnswerA

Cloud Build can automatically trigger on source repo pushes and deploy to App Engine.

Why this answer

Cloud Build is the correct service because it is a fully managed CI/CD platform that integrates natively with Cloud Source Repositories and App Engine Standard. You can configure a Cloud Build trigger to automatically build and deploy your application whenever code is pushed to the main branch, using a cloudbuild.yaml file that specifies the build steps and the `gcloud app deploy` command.

Exam trap

The trap here is that candidates confuse Cloud Deploy (which is for GKE/Cloud Run delivery pipelines) with Cloud Build (the actual CI/CD service that can deploy to App Engine), or they mistakenly think Cloud Run can deploy to App Engine Standard when it is a separate compute platform.

How to eliminate wrong answers

Option B (Cloud Run) is wrong because Cloud Run is a serverless compute platform for running containers, not a CI/CD service for building and deploying to App Engine Standard. Option C (Cloud Scheduler) is wrong because Cloud Scheduler is a cron job service for scheduling tasks, not a continuous deployment tool triggered by code pushes. Option D (Cloud Deploy) is wrong because Cloud Deploy is a delivery pipeline service for GKE and Cloud Run, not for App Engine Standard, and it does not directly integrate with Cloud Source Repositories triggers.

Practice this question →