ExamFinch.com My Study

Study guide

12.2 Build Provenance and Admission Concepts

Practice this exam

Google Cloud Professional Cloud Developer Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Exam and Compute Platform Decisions

1.1 Current Exam, Sources, and Scenario Method 1.2 Cloud Run Execution and Platform Selection 1.3 GKE Modes and Compute Engine Trade-offs

2 Chapter 2: Container Engineering and API Contracts

2.1 Stateless Microservices and Multi-stage Builds 2.2 Container Hardening, Signals, and Layer Caching 2.3 REST, gRPC, and Protobuf Contracts

3 Chapter 3: gRPC Compatibility and Geographic Routing

3.1 Schema Evolution and gRPC Routing 3.2 Geography, Network Tiers, and Load Balancers 3.3 Serverless NEGs, Sessions, and Edge Controls

4 Chapter 4: API Management and Caching

4.1 API Management & Rate Limiting with Apigee and API Gateway 4.2 Memorystore and Cache Access Patterns 4.3 Cache Invalidation, Capacity, and Failover

5 Chapter 5: Messaging, Task Dispatch, and Orchestration

5.1 Event-Driven Messaging with Cloud Pub/Sub 5.2 Task Queues & Rate Throttling with Cloud Tasks 5.3 Event Routing and Service Orchestration: Eventarc & Cloud Workflows

6 Chapter 6: Resilience and Relational Availability

6.1 Designing Resilient Systems: Circuit Breaking, Retries & Failover 6.2 Cloud SQL Availability and Recovery 6.3 Connection Budgets and Spanner Consistency

7 Chapter 7: Distributed Schemas and NoSQL Data Models

7.1 Spanner Keys, Indexes, and Transactions 7.2 Firestore Data, Indexes, and Transactions 7.3 Bigtable Row Keys and Replication

8 Chapter 8: Object Storage and Application Identity

8.1 Cloud Storage Lifecycle and Signed Access 8.2 Workload Identity and Service Authentication 8.3 Secret Delivery, Rotation, and IAP

9 Chapter 9: Security, Data Integration, and Developer Credentials

9.1 Private Communication, Key Rotation, and Vulnerability Response 9.2 AlloyDB Schemas and BigQuery Ingestion 9.3 CLI Configurations, Local ADC, and Cloud Shell

10 Chapter 10: Managed Development and Automated Tests

10.1 Cloud Workstations and the Container Inner Loop 10.2 Emulating Google Cloud Services & Database Auth Proxies 10.3 Automated Testing Strategies: Unit, Integration, and Mocking

11 Chapter 11: AI Development Tools and Build Pipelines

11.1 AI Coding Assistants, Context, MCP, and Test Review 11.2 Cloud Build Workers and Step Dependencies 11.3 Builders, Substitutions, Triggers, and IAM

12 Chapter 12: Artifact Security and Admission Policies

12.1 Artifact Management and Vulnerability Scanning with Artifact Registry 12.2 Build Provenance and Admission Concepts 12.3 Attestors, Policy Enforcement, and Break-glass

13 Chapter 13: Cloud Run and GKE Deployment Configuration

13.1 Cloud Run Deployment and Scaling Configuration 13.2 Cloud Run CPU, Private Egress, and Secrets 13.3 GKE Workload Controllers and Gateway Routing

14 Chapter 14: Kubernetes Resources, Health, and Progressive Releases

14.1 GKE Resources, OOM Diagnosis, and Autoscaling 14.2 Container Health Probes, Lifecycle Hooks & Graceful Shutdown 14.3 Progressive Delivery: Traffic Splitting, Canary, and Blue/Green Rollouts

15 Chapter 15: Source/Event Deployment and Cloud API Integration

15.1 Source Deployment, Event Receivers, and API Versions 15.2 Client Libraries, Service Enablement, and ADC 15.3 API Responses, Pagination, Caches, and Retries

16 Chapter 16: Tracing, Sampling, and Monitoring

16.1 Trace Context and OpenTelemetry Export 16.2 Custom Spans, Trace Analysis, and Sampling 16.3 Application Metrics, Health Checks & Alerting with Cloud Monitoring

17 Chapter 17: Structured Logs, Routing, and Error Management

17.1 Structured Logs, Trace Correlation, and Queries 17.2 Log Routing, Export Destinations, and Exclusions 17.3 Error Reporting Formats and Regression Handling

18 Chapter 18: Profiling, Generative AI, and Assisted Troubleshooting

18.1 Cloud Profiler Types and Flame Graph Analysis 18.2 Generative AI Integration with the Google Gen AI SDK 18.3 Evidence-Based Troubleshooting with AI Assistance

12.2 Build Provenance and Admission Concepts

Key Takeaways Explain This Topic AI

The current SLSA Build track uses levels 1-3; historical Level 4 is not a current Build level.

Cloud Build provenance requires supported outputs and configuration, including images and requestedVerifyOption.

Provenance is evidence of origin/build history, not proof that application logic has no bugs.

Last updated: October 2026

Software Supply Chain Security with SLSA & Binary Authorization

Software supply chains have become a primary attack surface for enterprise infrastructure. Adversaries target the continuous integration and delivery lifecycle by injecting malicious dependencies, compromising build pipelines, altering container tags in registries, or bypassing code review controls. Securing this pipeline requires end-to-end cryptographic provenance and strict deploy-time policy enforcement.

In Google Cloud, supply chain security is implemented through two foundational standards and platforms: the Supply chain Levels for Software Artifacts (SLSA) framework and Binary Authorization . The Google Cloud Professional Cloud Developer exam tests your ability to design end-to-end trusted pipelines combining Cloud Build, Container Analysis, Cloud Key Management Service (KMS), and Binary Authorization.

The SLSA Framework and Non-Falsifiable Provenance

SLSA (pronounced salsa ) is an open-source security framework spearheaded by Google and the OpenSSF that establishes graduated levels of supply chain integrity:

SLSA Level 1: Documented build process with basic provenance indicating what system built the artifact.

SLSA Level 2: Hosted build platform (preventing local developer laptop tampering) with service-generated, tamper-evident provenance.

SLSA Level 3: Isolated and Ephemeral Build Environments. The build platform must guarantee that build steps execute in isolated virtual machines or containers with no cross-build state contamination. Provenance must be non-falsifiable , meaning build steps or malicious scripts inside the build container cannot forge, alter, or inject fraudulent metadata into the build provenance statement.

The current SLSA Build track uses levels 1-3. Level 4 was part of an older specification; do not combine historical and current level definitions. Hermeticity and source-review controls remain useful but are not a current Build Level 4.

Non-Falsifiable Build Provenance in Cloud Build

Cloud Build natively generates SLSA Level 3 compliant provenance for supported Artifact Registry outputs when the build is configured to produce and verify provenance. Because provenance generation occurs within Google's control plane rather than inside the user's container execution space, user code cannot fabricate its own provenance.

The provenance statement is formatted as an in-toto attestation (JSON statement with a signed envelope) containing:

Immutable digest (SHA256) of the resulting container image.

Git repository source URI, branch, and exact commit SHA.

Build configuration file location and step arguments.

Entrypoint builders and environment variables.

Google Cloud signature certifying authenticity. ## Inspecting SLSA build provenance for an image in Artifact Registry

  • gcloud artifacts docker images describe \
  • us-central1-docker.pkg.dev/my-project/apps/order-service@sha256:7a8b9c... \
  • -show-provenance

Configuring and Checking Provenance steps:

  • name: gcr.io/cloud-builders/docker
  • args: [build, -t, 'us-central1-docker.pkg.dev/$PROJECT_ID/apps/order-service:$BUILD_ID', .]

images:

- 'us-central1-docker.pkg.dev/$PROJECT_ID/apps/order-service:$BUILD_ID'

options:

requestedVerifyOption: VERIFIED

Cloud Build's images output plus verified provenance configuration matters: an arbitrary explicit docker push is not equivalent. Inspect provenance and the resulting digest after this build completes. A separate promotion step can then evaluate scan results, create the required attestation, and deploy that exact digest. Provenance proves origin/build history under a trust policy; it does not prove the application is bug-free or that tests covered every requirement.

Binary Authorization: Deploy-Time Gatekeeping

While SLSA and vulnerability scanners operate during the CI phase, Binary Authorization acts as the gatekeeper at the moment of deployment. It is an admission control security service integrated natively into Google Kubernetes Engine (GKE) and Cloud Run .

How Binary Authorization Works

When a developer or CI pipeline attempts to create a GKE Pod or deploy a Cloud Run service:

The deployment request containing the container image URI is submitted to the platform API server.

The platform's internal Admission Controller Webhook intercepts the request before any container is scheduled or instantiated.

The admission webhook forwards the image digest to the Binary Authorization evaluation engine.

Binary Authorization checks the container image against the project's Binary Authorization Policy .

If the image satisfies all required policy rules (e.g., possesses valid cryptographic attestations), the request is admitted. If non-compliant, the deployment is rejected with an HTTP 403 Forbidden error. [ Developer / CI/CD ]

  • |
  • v (1. Deploy Manifest: image@sha256:...)
  • [ GKE / Cloud Run API Server ]
  • |
  • v (2. Intercept via Admission Controller)
  • [ Binary Authorization Engine ] <---> (3. Verify Attestation Signatures against KMS Key)
  • |
  • +-----+-----+
  • | |
  • (Admitted) (Rejected: 403 Forbidden)
  • | |
  • v v
  • [ Pod Runs ] [ Deployment Blocked + Audit Log Written ]
  • Verify the Artifact Subject

Compare the image digest in the deployment with the subject digest in the signed provenance. Then check the trusted builder identity and expected source repository/commit under the verification policy. A valid signature over a different artifact, or a build from an unapproved repository, is not evidence for the image being released. Keep build provenance distinct from a later vulnerability-scan or QA attestation, because each asserts a different fact.

Official references checked October 18, 2026: Google Cloud 1 .