GCP CI/CD with Cloud Build u0026 Deployment Manager Quiz Quiz

Explore core concepts of CI/CD using Cloud Build and Deployment Manager. Assess your grasp of GCP automation workflows, build triggers, and best deployment practices to improve your cloud development skills.

1. Understanding Build Triggers

   Which action would best enable automated builds to initiate each time a new commit is pushed to a specific development branch?

   1. Manually approving builds after each push
   2. Creating a build trigger linked to the branch
   3. Scheduling builds using a weekly cron job
   4. Cloning the repository on the build server

   Explanation: Creating a build trigger linked to the specific branch ensures builds start automatically with every new commit, automating the CI workflow. Manually approving builds after each push requires human intervention and is not automated. Scheduling builds weekly using a cron job introduces delays and does not respond to individual commits. Cloning the repository on the build server is a single action and does not tie the build process to repository changes.

2. YAML Build Definitions

   In Cloud Build, what is the primary role of the cloudbuild.yaml file in a typical CI/CD pipeline?

   1. Defining the sequence of build steps and required resources
   2. Listing all team members involved in the project
   3. Storing secrets and configuration values for runtime
   4. Providing version control settings for the codebase

   Explanation: The cloudbuild.yaml file details the order and instructions for build steps, such as building images or running tests. It does not serve as a directory of team members, nor is it a secure location for storing secrets or sensitive data. Version control settings are managed elsewhere and are not the primary focus of the build definition file.

3. Infrastructure as Code Concepts

   When using Deployment Manager, which statement best describes how resources are managed for infrastructure deployments?

   1. Resources are defined in configuration files and managed declaratively
   2. Resources are created by manually running deployment scripts
   3. Resources are hardcoded into application code
   4. Resources are assigned interactively through the cloud console only

   Explanation: Deployment Manager uses configuration files to declare desired resources, ensuring consistent and repeatable deployments. Manual deployment scripts do not provide the same level of automation or maintainability. Assigning resources interactively breaks automation and reproducibility. Hardcoding resources in application code is not a scalable or recommended approach.

4. Securing Deployment Pipelines

   What is a recommended method for managing sensitive credentials, such as database passwords, during automated build and deployment processes?

   1. Keeping passwords in a shared team document for copying
   2. Storing credentials in a secure secret management service
   3. Placing passwords in plain text within build configuration files
   4. Embedding passwords directly in source code files

   Explanation: Securing credentials using a dedicated secret management service helps protect sensitive data and ensures only authorized processes can access them. Embedding passwords in source code or build files exposes them to unnecessary risk. Keeping credentials in shared documents is insecure and prone to accidental leaks. Plain text storage within configuration files is not safe and should be strictly avoided.

5. Rollback Strategies in CI/CD

   After a failed deployment caused by a faulty configuration in infrastructure code, what is the best-practice response to quickly restore service?

   1. Manually editing infrastructure resources in the dashboard
   2. Re-deploying the faulty code repeatedly
   3. Delaying any action and monitoring for automatic recovery
   4. Reverting to a previous stable configuration version

   Explanation: Rolling back to a known stable configuration allows quick and reliable restoration of services. Re-deploying the faulty code likely repeats the failure. Manual dashboard edits introduce inconsistency and are not scalable. Waiting for automatic recovery is ineffective when the root cause is a configuration defect.