Study guide
12.1 Artifact Management and Vulnerability Scanning with Artifact Registry
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.1 Artifact Management and Vulnerability Scanning with Artifact Registry
Key Takeaways Explain This Topic AI
Artifact Registry is Google Cloud's fully managed, universal artifact repository platform, succeeding Container Registry (gcr.io) with multi-language package support and repository-level IAM control.
Repositories can be deployed in regional locations to eliminate cross-region egress costs and minimize container pull latency, or in multi-regional locations for geographic redundancy.
Container Analysis provides automated and on-demand vulnerability scanning for container images, categorizing Common Vulnerabilities and Exposures (CVEs) by CVSS severity levels.
Artifact Registry Cleanup Policies automate repository lifecycle management by conditionally deleting untagged or aged images while retaining tagged production releases.
Remote repositories cache supported upstream formats; virtual repositories group compatible repositories of one format. They help reduce dependence on external registries (Docker Hub, npmjs, PyPI) to protect against upstream outages and rate limits.
Last updated: October 2026
Artifact Management and Vulnerability Scanning with Artifact Registry
In modern cloud architectures, compiled software artifacts, container images, and language-specific package dependencies represent the bridge between source code and production compute environments. Artifact Registry is Google Cloud's fully managed, universal package manager and container image registry.
Artifact Registry replaces the legacy Container Registry ( gcr.io ), providing enterprise-grade security boundaries, fine-grained Identity and Access Management (IAM), multi-format package hosting, upstream registry caching, automated vulnerability discovery, and declarative artifact lifecycle management.
Artifact Registry vs. Container Registry ( gcr.io )
Google Cloud formally deprecated Container Registry in favor of Artifact Registry. Understanding the structural differences between these two services is essential for migration scenarios and certification questions:
Capability Legacy Container Registry ( gcr.io ) Modern Artifact Registry ( pkg.dev )
Storage Architecture Backed by Cloud Storage buckets ( artifacts.[PROJECT_ID].appspot.com ) Native package management engine with direct metadata indexing
IAM Granularity Project-wide or Cloud Storage bucket-level ACLs only Fine-grained IAM per individual repository within a project
Supported Package Formats Docker and OCI images only Docker/OCI, Maven, npm, Python (PyPI), Go, Helm, Debian (apt), RPM (yum)
Repository Locality Multi-regional only ( us.gcr.io , eu.gcr.io , asia.gcr.io ) Regional ( us-central1 , europe-west1 ) and Multi-regional ( us , europe )
Network Egress Optimization Cross-region network egress charged when pulling from different zones Zero egress charges when regional repository matches compute platform region
Caching & Proxies No native remote caching Remote Repositories (Docker Hub, PyPI, Maven) and Virtual Repositories
Lifecycle Automation Manual Cloud Storage lifecycle rules (prone to breaking manifest links) Native declarative Cleanup Policies with tag awareness and dry-run safety
- Resource URI Format gcr.io/[PROJECT_ID]/[IMAGE] [LOCATION]-docker.pkg.dev/[PROJECT_ID]/[REPO_NAME]/[IMAGE]
- Regional vs. Multi-Regional Repository Architecture
When provisioning an Artifact Registry repository, developers must choose between Regional and Multi-Regional locations:
Regional Repositories (Recommended for Production Workloads)
Performance and Latency: By placing an Artifact Registry repository in the exact same region as your compute clusters (e.g., repository in us-central1 and GKE/Cloud Run workloads in us-central1 ), container pull times are minimized.
Network Egress Cost Elimination: Pulling a container image across regional boundaries incurs standard Google Cloud inter-region network egress charges. In high-velocity environments with frequent horizontal pod autoscaling or node spin-ups, these costs compound rapidly. Colocating repositories in the workload's region reduces inter-region data transfer charges to zero .
Data Sovereignty: Satisfies strict regulatory and legal compliance frameworks that mandate data residency within specific geographic borders.
Multi-Regional Repositories
Geographic Redundancy: Replicates container images across multiple Google Cloud data center zones within a broad geographical area ( us , europe , or asia ).
Global Footprint: Best suited for globally distributed fleets where nodes across various continents pull from a unified multi-regional endpoint.
Remote and Virtual Repositories
Enterprise software supply chains frequently face upstream failures, such as public Docker Hub rate-limiting (HTTP 429 Too Many Requests), upstream outage downtime, or malicious package tampering:
Remote Repositories: Act as caching pull-through proxies for public registries (Docker Hub, npmjs, Maven Central, PyPI). When a developer or CI/CD runner requests an external base image (e.g., alpine:latest ), Artifact Registry checks its cache. If absent, it pulls the image from Docker Hub, stores a copy in your private Google Cloud perimeter, and serves subsequent requests directly from internal Google cache.
Virtual Repositories: Within one package format, consolidate compatible underlying repositories (such as an internal private production repository, an internal staging repository, and an external remote proxy) behind a single unified URL endpoint. Upstream repositories are evaluated according to a priority order, preventing dependency confusion attacks.
Authentication and IAM Permissions
Interacting with Artifact Registry requires configuring native authentication and assigning least-privilege IAM roles.
IAM Access Controls
Unlike Container Registry, Artifact Registry supports IAM bindings at both the project level and the individual repository level :
roles/artifactregistry.reader : Read-only access to view and pull artifacts. Must be granted to runtime service accounts (e.g., GKE Node Service Account or Cloud Run Service Agent) so nodes can pull container images.
roles/artifactregistry.writer : Read and write access to push artifacts. Assigned to Cloud Build service accounts, GitHub Actions runners, or release automation agents.
roles/artifactregistry.repoAdmin : Repository artifact administration. Repository configuration and IAM policy changes require appropriate administrator permissions, such as Artifact Registry Administrator; do not infer them from the name repoAdmin.
Configuring the Docker Credential Helper
Developers and local workstations must authenticate Docker with Google Cloud before running docker push or docker pull . Instead of storing long-lived, static access keys on developer machines, Google Cloud uses the Docker Credential Helper : ## Configure Docker to authenticate against regional Artifact Registry hosts
gcloud auth configure-docker us-central1-docker.pkg.dev,europe-west1-docker.pkg.dev
This command updates ~/.docker/config.json . When Docker interacts with us-central1-docker.pkg.dev , it calls gcloud behind the scenes to fetch short-lived OAuth 2.0 access tokens, completely eliminating persistent static passwords.
Vulnerability Scanning with Container Analysis
Container security requires continuous inspection of operating system packages, system binaries, and language runtimes. In Google Cloud, vulnerability scanning is powered by the Container Analysis API .
Automatic Scanning vs. On-Demand Scanning
Google Cloud provides two distinct vulnerability scanning mechanisms: +-----------------------------------------------------------------------------+
- | Automatic Continuous Scanning |
- | - Triggered automatically whenever an image is pushed to Artifact Registry |
- | - Continuous Rescanning: When a new zero-day CVE is discovered, Container |
- | Analysis re-indexes existing stored images without requiring a rebuild |
- | - Scope: OS packages (Debian, Ubuntu, Alpine, RHEL) & Language runtimes |
- +-----------------------------------------------------------------------------+
- vs
- +-----------------------------------------------------------------------------+
- | On-Demand Scanning |
- | - Shift-Left: Executed locally on developer machines or early in CI steps |
- | - Scans local container images before pushing to Artifact Registry |
- | - Command: gcloud artifacts docker images scan [LOCAL_IMAGE_TAG] |
- | - Blocks vulnerable images before they ever reach central registries |
- +-----------------------------------------------------------------------------+
- Container Analysis Data Model: Notes and Occurrences
Container Analysis organizes metadata using an abstract metadata framework:
Note: A high-level description of a known security concept. For vulnerabilities, a Note represents a distinct CVE (e.g., CVE-2024-6387 ), including its CVSS severity score, affected software packages, and remediation instructions. Notes are maintained globally by Google Cloud's security research teams.
Occurrence: A specific, concrete instance of a Note linked to a particular container image manifest (identified by SHA256 digest). If your container image contains an affected OpenSSH package version associated with CVE-2024-6387 , Container Analysis creates an Occurrence pointing to your image digest.
Vulnerability Discovery and Severity Classification
Vulnerabilities are categorized according to Common Vulnerability Scoring System (CVSS) baselines:
CRITICAL : Highest CVSS severity band; the precise exploit conditions come from the advisory.
HIGH : A high CVSS severity band, not a guarantee of one particular exploit type.
MEDIUM : Moderate security exposure requiring specific conditions.
LOW : Minor security discrepancies.
Querying Vulnerabilities via CLI
Developers and CI pipelines can query vulnerability Occurrences using gcloud : ## List all vulnerabilities discovered for a specific container image digest
- gcloud artifacts docker images list-vulnerabilities \
- us-central1-docker.pkg.dev/my-project/apps/order-service@sha256:4a8b1... \
- -format="table(occurrence.vulnerability.effectiveSeverity, occurrence.vulnerability.shortDescription)"
- ## Query and filter for blocking CRITICAL or HIGH vulnerabilities in CI
- gcloud artifacts docker images list-vulnerabilities \
- us-central1-docker.pkg.dev/my-project/apps/order-service@sha256:4a8b1... \
- -filter="occurrence.vulnerability.effectiveSeverity >= HIGH"
- Artifact Lifecycle Management: Cleanup Policies
Continuous Integration pipelines push dozens of container image revisions daily. Over time, unused intermediate layers, untagged images, and obsolete release candidate builds accumulate, inflating storage costs.
Artifact Registry features native Cleanup Policies that evaluate stored images against declarative lifecycle conditions.
Cleanup Policy Concepts & Evaluation Logic
Policies consist of Conditions and Actions :
Action: Either DELETE (purges matching versions) or KEEP (preserves matching versions, overriding any conflicting delete conditions).
Tag State: Filter by TAGGED , UNTAGGED , or ANY .
Age Conditions: olderThan (e.g., 30d ) or newerThan .
Prefix Filters: Match specific tag conventions (e.g., tagPrefixes: ["v", "release"] ).
Most Recent Versions: Keep the N most recently uploaded versions via keepCount: 10 .
- Concrete Example: Enterprise Cleanup Policy Specification [
- {
- "name": "delete-untagged",
- "action": {
- "type": "Delete"
- },
- "condition": {
- "tagState": "untagged",
- "olderThan": "14d"
- }
- },
- {
- "name": "keep-production",
- "action": {
- "type": "Keep"
- },
- "condition": {
- "tagState": "tagged",
- "tagPrefixes": [
- "v",
- "prod-"
- ]
- }
- },
- {
- "name": "keep-recent",
- "action": {
- "type": "Keep"
- },
- "mostRecentVersions": {
- "keepCount": 5
- }
- }
- ] ## Applying the cleanup policy to an Artifact Registry repository
- gcloud artifacts repositories set-cleanup-policies my-repo \
- -project=my-project \
- -location=us-central1 \
- -policy=cleanup-policy.json \
- -dry-run
Exam Trap: KEEP policies always take precedence over DELETE policies. If an image matches both a delete rule (e.g., olderThan: 30d ) and a keep rule (e.g., keepCount: 5 ), the image is retained . Furthermore, developers can run cleanup policies with --dry-run to preview image deletion candidates in Cloud Logging before permanent deletion occurs.
Official references checked October 18, 2026: Google Cloud 1 .