Google Professional Cloud DevOps Engineer Exam Practice Test Instant Access

Question 1

You deployed an application into a large Standard Google Kubernetes Engine (GKE) cluster. The application is stateless and multiple pods run at the same time. Your application receives inconsistent traffic. You need to ensure that the user experience remains consistent regardless of changes in traffic. and that the resource usage of the cluster is optimized.

What should you do?

AConfigure a cron job to scale the deployment on a schedule.

BConfigure a Horizontal Pod Autoscaler.

CConfigure a Vertical Pod Autoscaler.

DConfigure cluster autoscaling on the node pool.

Answer : B

Question 2

You need to introduce postmortems into your organization. You want to ensure that the postmortem process is well received. What should you do?

Choose 2 answers

ACreate a designated team that is responsible for conducting all postmortems.

BEncourage new employees to conduct postmortems to learn through practice.

CEnsure that writing effective postmortems is a rewarded and celebrated practice.

DEncourage your senior leadership to acknowledge and participate in postmortems.

EProvide your organization with a forum to critique previous postmortems.

Answer : C, D

Question 3

You need to introduce postmortems into your organization during the holiday shopping season. You are expecting your web application to receive a large volume of traffic in a short period. You need to prepare your application for potential failures during the event What should you do?

Choose 2 answers

AMonitor latency of your services for average percentile latency.

BReview your increased capacity requirements and plan for the required quota management.

CCreate alerts in Cloud Monitoring for all common failures that your application experiences.

DEnsure that relevant system metrics are being captured with Cloud Monitoring and create alerts at levels of interest.

EConfigure Anthos Service Mesh on the application to identify issues on the topology map.

Answer : B, D

Question 4

Your company operates in a highly regulated domain. Your security team requires that only trusted container images can be deployed to Google Kubernetes Engine (GKE). You need to implement a solution that meets the requirements of the security team, while minimizing management overhead. What should you do?

AGrant the roles/artifactregistry. writer role to the Cloud Build service account. Confirm that no employee has Artifact Registry write permission.

BUse Cloud Run to write and deploy a custom validator Enable an Eventarc trigger to perform validations when new images are uploaded.

CConfigure Kritis to run in your GKE clusters to enforce deploy-time security policies.

DConfigure Binary Authorization in your GKE clusters to enforce deploy-time security policies

Answer : D

Question 5

Your organization stores all application logs from multiple Google Cloud projects in a central Cloud Logging project. Your security team wants to enforce a rule that each project team can only view their respective logs, and only the operations team can view all the logs. You need to design a solution that meets the security team's requirements, while minimizing costs. What should you do?

AExport logs to BigQuery tables for each project team. Grant project teams access to their tables. Grant logs writer access to the operations team in the central logging project.

BCreate log views for each project team, and only show each project team their application logs. Grant the operations team access to the _ Al Il-jogs View in the central logging project.

CGrant each project team access to the project _ Default view in the central logging project. Grant logging viewer access to the operations team in the central logging project.

DCreate Identity and Access Management (IAM) roles for each project team and restrict access to the _ Default log view in their individual Google Cloud project. Grant viewer access to the operations team in the central logging project.

Answer : B

Create log views for each project team, and only show each project team their application logs.Grant the operations team access to the _AllLogs View in the central logging project1.

This approach aligns with the Google Cloud's recommended methodologies for Professional Cloud DevOps Engineers1. Log views allow you to create and manage access control at a finer granularity for your logs. By creating a separate log view for each project team, you can ensure that they only have access to their respective logs. The operations team, on the other hand, can be granted access to the _AllLogs view in the central logging project, allowing them to view all logs as required.

This solution not only meets the security team's requirements but also minimizes costs as it leverages built-in features of Google Cloud's logging and does not require exporting logs to another service like BigQuery (as suggested in option A), which could incur additional costs1.

Question 6

Your company runs applications in Google Kubernetes Engine (GKE) that are deployed following a GitOps methodology.

Application developers frequently create cloud resources to support their applications. You want to give developers the ability to manage infrastructure as code, while ensuring that you follow Google-recommended practices. You need to ensure that infrastructure as code reconciles periodically to avoid configuration drift. What should you do?

AInstall and configure Config Connector in Google Kubernetes Engine (GKE).

BConfigure Cloud Build with a Terraform builder to execute plan and apply commands.

CCreate a Pod resource with a Terraform docker image to execute terraform plan and terraform apply commands.

DCreate a Job resource with a Terraform docker image to execute terraforrm plan and terraform apply commands.

Answer : A

The best option to give developers the ability to manage infrastructure as code, while ensuring that you follow Google-recommended practices, is to install and configure Config Connector in Google Kubernetes Engine (GKE).

Config Connector is a Kubernetes add-on that allows you to manage Google Cloud resources through Kubernetes. You can use Config Connector to create, update, and delete Google Cloud resources using Kubernetes manifests. Config Connector also reconciles the state of the Google Cloud resources with the desired state defined in the manifests, ensuring that there is no configuration drift1.

Config Connector follows the GitOps methodology, as it allows you to store your infrastructure configuration in a Git repository, and use tools such as Anthos Config Management or Cloud Source Repositories to sync the configuration to your GKE cluster. This way, you can use Git as the source of truth for your infrastructure, and enable reviewable and version-controlled workflows2.

Config Connector can be installed and configured in GKE using either the Google Cloud Console or the gcloud command-line tool. You need to enable the Config Connector add-on for your GKE cluster, and create a Google Cloud service account with the necessary permissions to manage the Google Cloud resources. You also need to create a Kubernetes namespace for each Google Cloud project that you want to manage with Config Connector3.

By using Config Connector in GKE, you can give developers the ability to manage infrastructure as code, while ensuring that you follow Google-recommended practices. You can also benefit from the features and advantages of Kubernetes, such as declarative configuration, observability, and portability4.

1: Overview | Artifact Registry Documentation | Google Cloud

2: Deploy Anthos on GKE with Terraform part 1: GitOps with Config Sync | Google Cloud Blog

3: Installing Config Connector | Config Connector Documentation | Google Cloud

4: Why use Config Connector? | Config Connector Documentation | Google Cloud

Question 7

You are deploying an application to Cloud Run. The application requires a password to start. Your organization requires that all passwords are rotated every 24 hours, and your application must have the latest password. You need to deploy the application with no downtime. What should you do?

AStore the password in Secret Manager and send the secret to the application by using environment variables.

BStore the password in Secret Manager and mount the secret as a volume within the application.

CUse Cloud Build to add your password into the application container at build time. Ensure that Artifact Registry is secured from public access.

DStore the password directly in the code. Use Cloud Build to rebuild and deploy the application each time the password changes.

Answer : B

The correct answer is B, Store the password in Secret Manager and mount the secret as a volume within the application.

Secret Manager is a service that allows you to securely store and manage sensitive data such as passwords, API keys, certificates, and tokens. You can use Secret Manager to rotate your secrets automatically or manually, and access them from your Cloud Run applications1.

There are two ways to use secrets from Secret Manager in Cloud Run:

As environment variables: You can set environment variables that point to secrets in Secret Manager. Cloud Run will resolve the secrets at runtime and inject them into the environment of your application. However, this method has some limitations, such as:

The environment variables are cached for up to 10 minutes, so you may not get the latest version of the secret immediately.

The environment variables are visible in plain text in the Cloud Console and the Cloud SDK, which may expose sensitive information.

The environment variables are limited to 4 KB of data, which may not be enough for some secrets.2

As file system volumes: You can mount secrets from Secret Manager as files in a volume within your application. Cloud Run will create a tmpfs volume and write the secrets as files in it. This method has some advantages, such as:

The files are updated every 30 seconds, so you can get the latest version of the secret faster.

The files are not visible in the Cloud Console or the Cloud SDK, which provides better security.

The files can store up to 64 KB of data, which allows for larger secrets.3

Therefore, for your use case, it is better to use the second method and mount the secret as a file system volume within your application. This way, you can ensure that your application has the latest password, and you can deploy it with no downtime.

To mount a secret as a file system volume in Cloud Run, you can use the following command:

gcloud beta run deploy SERVICE --image IMAGE_URL --update-secrets=/path/to/file=secretName:version

where:

SERVICE is the name of your Cloud Run service.

IMAGE_URL is the URL of your container image.

/path/to/file is the path where you want to mount the secret file in your application.

secretName is the name of your secret in Secret Manager.

You can also use the Cloud Console to mount secrets as file system volumes. For more details, see Mounting secrets from Secret Manager.

1: Overview | Secret Manager Documentation | Google Cloud

2: Using secrets as environment variables | Cloud Run Documentation | Google Cloud

3: Mounting secrets from Secret Manager | Cloud Run Documentation | Google Cloud