ExamGecko
Search Search Login
Home Home / Google / Professional Cloud DevOps Engineer
Question list
Search
Search

List of questions

Search
Open VPLUS File
Convert VPLUS to PDF

Related questions

Your applications performance in Google Cloud has degraded since the last release You suspect that downstream dependencies might be causing some requests to take longer to complete You need to investigate the issue with your application to determine the cause What should you do?
You are managing the production deployment to a set of Google Kubernetes Engine (GKE) clusters. You want to make sure only images which are successfully built by your trusted CI/CD pipeline are deployed to production. What should you do?
You are creating a CI/CD pipeline in Cloud Build to build an application container image The application code is stored in GitHub Your company requires thai production image builds are only run against the main branch and that the change control team approves all pushes to the main branch You want the image build to be as automated as possible What should you do? Choose 2 answers
You are implementing a CI'CD pipeline for your application in your company s multi-cloud environment Your application is deployed by using custom Compute Engine images and the equivalent in other cloud providers You need to implement a solution that will enable you to build and deploy the images to your current environment and is adaptable to future changes Which solution stack should you use'?
You are writing a postmortem for an incident that severely affected users. You want to prevent similar incidents in the future. Which two of the following sections should you include in the postmortem? (Choose two.)
You created a Stackdriver chart for CPU utilization in a dashboard within your workspace project. You want to share the chart with your Site Reliability Engineering (SRE) team only. You want to ensure you follow the principle of least privilege. What should you do?
The new version of your containerized application has been tested and is ready to be deployed to production on Google Kubernetes Engine (GKE) You could not fully load-test the new version in your pre-production environment and you need to ensure that the application does not have performance problems after deployment Your deployment must be automated What should you do?
You are using Terraform to manage infrastructure as code within a Cl/CD pipeline You notice that multiple copies of the entire infrastructure stack exist in your Google Cloud project, and a new copy is created each time a change to the existing infrastructure is made You need to optimize your cloud spend by ensuring that only a single instance of your infrastructure stack exists at a time. You want to follow Google-recommended practices What should you do?
You are deploying a Cloud Build job that deploys Terraform code when a Git branch is updated. While testing, you noticed that the job fails. You see the following error in the build logs: Initializing the backend. .. Error: Failed to get existing workspaces : querying Cloud Storage failed: googleapi : Error 403 You need to resolve the issue by following Google-recommended practices. What should you do?
Your company operates in a highly regulated domain that requires you to store all organization logs for seven years You want to minimize logging infrastructure complexity by using managed services You need to avoid any future loss of log capture or stored logs due to misconfiguration or human error What should you do?

Question 134 - Professional Cloud DevOps Engineer discussion

Report
Export

You are designing a system with three different environments: development, quality assurance (QA), and production.

Each environment will be deployed with Terraform and has a Google Kubemetes Engine (GKE) cluster created so that application teams can deploy their applications. Anthos Config Management will be used and templated to deploy

infrastructure level resources in each GKE cluster. All users (for example, infrastructure operators and application owners) will use GitOps. How should you structure your source control repositories for both Infrastructure as Code (laC) and application code?

A.
Cloud Infrastructure (Terraform) repository is shared: different directories are different environments GKE Infrastructure (Anthos Config Management Kustomize manifests) repository is shared: different overlay directories are different environments Application (app source code) repositories are separated: different branches are different features
Answers
A.
Cloud Infrastructure (Terraform) repository is shared: different directories are different environments GKE Infrastructure (Anthos Config Management Kustomize manifests) repository is shared: different overlay directories are different environments Application (app source code) repositories are separated: different branches are different features
B.
Cloud Infrastructure (Terraform) repository is shared: different directories are different environments GKE Infrastructure (Anthos Config Management Kustomize manifests) repositories are separated: different branches are different environments Application (app source code) repositories are separated: different branches are different features
Answers
B.
Cloud Infrastructure (Terraform) repository is shared: different directories are different environments GKE Infrastructure (Anthos Config Management Kustomize manifests) repositories are separated: different branches are different environments Application (app source code) repositories are separated: different branches are different features
C.
Cloud Infrastructure (Terraform) repository is shared: different branches are different environments GKE Infrastructure (Anthos Config Management Kustomize manifests) repository is shared: different overlay directories are different environments Application (app source code) repository is shared: different directories are different features
Answers
C.
Cloud Infrastructure (Terraform) repository is shared: different branches are different environments GKE Infrastructure (Anthos Config Management Kustomize manifests) repository is shared: different overlay directories are different environments Application (app source code) repository is shared: different directories are different features
D.
Cloud Infrastructure (Terraform) repositories are separated: different branches are different environments GKE Infrastructure (Anthos Config Management Kustomize manifests) repositories are separated: different overlay directories are different environments Application (app source code) repositories are separated: different branches are different features
Answers
D.
Cloud Infrastructure (Terraform) repositories are separated: different branches are different environments GKE Infrastructure (Anthos Config Management Kustomize manifests) repositories are separated: different overlay directories are different environments Application (app source code) repositories are separated: different branches are different features
Suggested answer: B

Explanation:

The correct answer is B. Cloud Infrastructure (Terraform) repository is shared: different directories are different environments. GKE Infrastructure (Anthos Config Management Kustomize manifests) repositories are separated: different branches are different environments. Application (app source code) repositories are separated: different branches are different features.

This answer follows the best practices for using Terraform and Anthos Config Management with GitOps, as described in the following sources:

For Terraform, it is recommended to use a single repository for all environments, and use directories to separate them. This way, you can reuse the same Terraform modules and configurations across environments, and avoid code duplication and drift. You can also use Terraform workspaces to isolate the state files for each environment12.

For Anthos Config Management, it is recommended to use separate repositories for each environment, and use branches to separate the clusters within each environment. This way, you can enforce different policies and configurations for each environment, and use pull requests to promote changes across environments. You can also use Kustomize to create overlays for each cluster that apply specific patches or customizations34.

For application code, it is recommended to use separate repositories for each application, and use branches to separate the features or bug fixes for each application. This way, you can isolate the development and testing of each application, and use pull requests to merge changes into the main branch. You can also use tags or labels to trigger deployments to different environments5 .

1: Best practices for using Terraform | Google Cloud

2: Terraform Recommended Practices - Part 1 | Terraform - HashiCorp Learn

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

4: Using Kustomize with Anthos Config Management | Anthos Config Management Documentation | Google Cloud

5: Deploy Anthos on GKE with Terraform part 3: Continuous Delivery with Cloud Build | Google Cloud Blog

: GitOps-style continuous delivery with Cloud Build | Cloud Build Documentation | Google Cloud

Show Answer
asked 18/09/2024
Andre Beary
29 questions
PreviousPreviousNextNext
User
Your answer:
0 comments
Sorted by

Leave a comment first

ExamGecko

Copyright @2023 ExamGecko | All right reserved

Mail us: [email protected]
About us
Contact us
Twitter X
Facebook
Medium
Convert VPLUS to PDF
Open VPLUS files Easily and Quickly
Privacy Policy
Disclaimer
Terms