An enterprise organization is designing an automated CI/CD pipeline in Google Cloud to build and manage container images across staging and production environments. The cloud architecture and security teams have established the following requirements: Build executions must adhere to the principle of least privilege rather than relying on default broad project permissions. The build process must be standardized and reusable across environments using a single build configuration file. Build artifacts must be versioned, stored securely, and automatically analyzed for vulnerabilities. The pipeline must generate verifiable build provenance metadata for software supply chain compliance. Which solution should the cloud architect implement?

Configure Cloud Build triggers with user-specified service accounts granted scoped IAM roles, define parameterized substitutions in cloudbuild.yaml, push images to Artifact Registry, and enable Artifact Analysis for vulnerability scanning and build provenance.: ### What the Solution Is This architecture leverages **Google Cloud Build** triggers configured with dedicated **user-specified service accounts**, parameterized **build substitutions**, and **Google Cloud Artifact Registry** integrated with **Artifact Analysis** for end-to-end supply chain security. ### How It Meets the Requirements - **Principle of least privilege**: By configuring triggers with dedicated **user-specified service accounts** and assigning granular roles (such as `roles/artifactregistry.writer` and `roles/logging.logWriter`), you prevent builds from executing with broad default project-level permissions. - **Standardized and reusable pipelines**: Using Cloud Build's built-in default substitutions (like `$PROJECT_ID`) and **user-defined substitutions** (such as `${_LOCATION}` and `${_REPOSITORY}`) in a single `cloudbuild.yaml` allows the exact same build template to deploy across staging and production environments dynamically. - **Secure versioning and vulnerability scanning**: Pushing container images directly to **Artifact Registry** enables centralized, versioned package management, while **Artifact Analysis** automatically scans images for common vulnerabilities and exposures (CVEs). - **Supply chain security & provenance**: Cloud Build automatically records non-falsifiable **build provenance** (compliant with SLSA standards) and security insights into Artifact Analysis, providing verifiable audit trails of the source, toolchain, and artifact digests. ### Key Advantages - **Granular Access Control**: Isolates build permissions per project or pipeline phase. - **Automated Security Gates**: Proactively surfaces dependency vulnerabilities and software bill of materials (SBOM) data. - **Maintainable CI/CD Templates**: Reduces configuration drift across multi-environment deployments. - **Native SLSA Provenance**: Ensures compliance with enterprise software supply chain security standards. ### Why This Is Optimal Native integration between Cloud Build, Artifact Registry, and Artifact Analysis provides fully managed, serverless, and hardened CI/CD execution without needing third-party plugins or managing underlying build runner infrastructure.

StudyCerts

Cloud Build Artifact Registry Cicd Pipeline | Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam! | StudyCerts

Professional Cloud Architect

Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Cloud Build Artifact Registry Cicd Pipeline

Section: Deployment and release management

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

An enterprise organization is designing an automated CI/CD pipeline in Google Cloud to build and manage container images across staging and production environments. The cloud architecture and security teams have established the following requirements:

Build executions must adhere to the principle of least privilege rather than relying on default broad project permissions.
The build process must be standardized and reusable across environments using a single build configuration file.
Build artifacts must be versioned, stored securely, and automatically analyzed for vulnerabilities.
The pipeline must generate verifiable build provenance metadata for software supply chain compliance.

Which solution should the cloud architect implement?

Configure Cloud Deploy to compile application source code and generate containers, push built artifacts to an Artifact Registry remote repository pointing to Docker Hub, and disable vulnerability scanning.

Configure Cloud Build triggers with user-specified service accounts granted scoped IAM roles, define parameterized substitutions in cloudbuild.yaml, push images to Artifact Registry, and enable Artifact Analysis for vulnerability scanning and build provenance.

Generate long-lived JSON service account keys, store them in the source Git repository, execute builds using local Docker daemons, and push images to Google Cloud Storage buckets.

Use the default Cloud Build service account with Project Editor permissions, create environment-specific static cloudbuild.yaml files, push images to Artifact Registry, and use Cloud Workstations to manually verify image digests.

Professional Cloud Architect

Cloud Build Artifact Registry Cicd Pipeline

Related questions