{"id":590,"date":"2026-04-14T15:53:15","date_gmt":"2026-04-14T15:53:15","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-artifact-registry-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-application-development\/"},"modified":"2026-04-14T15:53:15","modified_gmt":"2026-04-14T15:53:15","slug":"google-cloud-artifact-registry-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-application-development","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-artifact-registry-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-application-development\/","title":{"rendered":"Google Cloud Artifact Registry Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Application development"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Application development<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Artifact Registry is Google Cloud\u2019s managed service for storing, managing, and securing software artifacts used throughout the application development lifecycle\u2014especially container images and language packages.<\/p>\n\n\n\n<p>In simple terms: Artifact Registry is a private \u201capp artifact warehouse\u201d for your team. You publish (push) container images or packages to it from your CI\/CD pipeline, and your runtimes (like Cloud Run or GKE) pull them reliably when deploying.<\/p>\n\n\n\n<p>Technically, Artifact Registry is a regional or multi-regional repository service integrated with Google Cloud IAM, audit logging, encryption, and supply-chain tooling (for example, vulnerability scanning and attestations via Artifact Analysis \/ Container Analysis). It supports multiple artifact formats\u2014commonly Docker\/OCI images, and packages such as Maven, npm, Python, APT, YUM, and Go modules\u2014so you can standardize artifact storage across application development teams.<\/p>\n\n\n\n<p>The problem it solves: teams need a secure, governable, scalable place to store build outputs (images\/packages), control access with least privilege, integrate with CI\/CD and runtimes, reduce supply-chain risk, and avoid ad-hoc artifact storage approaches that are hard to audit and operate.<\/p>\n\n\n\n<p><strong>Important product status note:<\/strong> Artifact Registry is an active Google Cloud service. It is the recommended successor to <strong>Container Registry (gcr.io)<\/strong> for container image storage on Google Cloud. If you still use Container Registry, plan migration and verify current timelines and tooling in official docs.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Artifact Registry?<\/h2>\n\n\n\n<p>Artifact Registry\u2019s official purpose is to provide <strong>private, managed repositories<\/strong> to store and distribute build artifacts (container images and language packages) with Google Cloud-native security, access controls, and integrations.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities (what it does)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Hosts <strong>private repositories<\/strong> for multiple artifact formats (commonly Docker\/OCI images and language packages).<\/li>\n<li>Provides <strong>repository-level IAM<\/strong> for fine-grained access control.<\/li>\n<li>Integrates with <strong>Google Cloud CI\/CD and runtimes<\/strong> (Cloud Build, Cloud Deploy, Cloud Run, GKE, etc.).<\/li>\n<li>Supports <strong>artifact governance<\/strong> capabilities such as retention\/cleanup controls (where configured) and integration with scanning\/metadata systems (verify specific features for your artifact format in official docs).<\/li>\n<li>Enables <strong>standard tooling compatibility<\/strong>:<\/li>\n<li>Docker CLI \/ OCI registry workflows for container images<\/li>\n<li>Maven\/Gradle for Java artifacts<\/li>\n<li>npm for Node.js packages<\/li>\n<li>pip\/twine for Python packages<\/li>\n<li>apt\/yum for OS packages<\/li>\n<li>Go module tooling for Go packages (verify workflow details for your environment)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Repository<\/strong>: The top-level container for artifacts. Created in a specific <strong>location<\/strong> (region or multi-region).<\/li>\n<li><strong>Package<\/strong>: A named artifact within a repository (for example, an image name or a package name).<\/li>\n<li><strong>Version<\/strong>: A specific version\/build of a package (for container images, versions map to digests; tags are references).<\/li>\n<li><strong>Tag<\/strong> (container images): Human-friendly pointers to an image digest (for example, <code>:1.2.3<\/code>, <code>:prod<\/code>).<\/li>\n<li><strong>IAM policy<\/strong>: Access control at the repository level (and project level).<\/li>\n<li><strong>Artifact Registry API<\/strong>: The Google Cloud API used to administer repositories and interact with metadata.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type and scope<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Service type<\/strong>: Fully managed artifact repository \/ private registry service.<\/li>\n<li><strong>Scope<\/strong>: <strong>Project-scoped<\/strong> resources (repositories live in a Google Cloud project).<\/li>\n<li><strong>Location model<\/strong>: Repositories are created in a <strong>specific location<\/strong> (often regional; multi-regional options may exist). Choose location based on latency, data residency, and cost. <strong>Verify available locations<\/strong> in official docs for your project and artifact format.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Artifact Registry is a core \u201cbuild-and-release\u201d component in Google Cloud application development:\n&#8211; <strong>Source \u2192 Build \u2192 Store artifacts \u2192 Deploy<\/strong>\n&#8211; Typical integrations:\n  &#8211; <strong>Cloud Build<\/strong> builds images\/packages and pushes to Artifact Registry.\n  &#8211; <strong>Cloud Run \/ GKE \/ GCE<\/strong> pull container images from Artifact Registry.\n  &#8211; <strong>Cloud Deploy<\/strong> promotes releases using images stored in Artifact Registry.\n  &#8211; <strong>Artifact Analysis (Container Analysis)<\/strong> can store vulnerability findings and attestations (commonly for container images).\n  &#8211; <strong>Cloud Logging \/ Audit Logs<\/strong> captures who accessed what and when.<\/p>\n\n\n\n<p>Official docs: https:\/\/cloud.google.com\/artifact-registry\/docs<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Artifact Registry?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Standardization<\/strong>: One managed system for artifacts reduces fragmentation (random registries, unmanaged servers, inconsistent retention).<\/li>\n<li><strong>Faster delivery<\/strong>: CI\/CD pipelines become repeatable and less brittle when artifacts are stored in a highly available managed service.<\/li>\n<li><strong>Risk reduction<\/strong>: Centralized access control and audit logs support governance and compliance.<\/li>\n<li><strong>Scales with teams<\/strong>: Works for a single team or a platform organization serving many teams.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Multiple artifact formats<\/strong> in one service: containers plus popular package ecosystems.<\/li>\n<li><strong>Native Google Cloud identity<\/strong>: Uses IAM and service accounts instead of shared passwords.<\/li>\n<li><strong>Toolchain compatibility<\/strong>: Works with standard clients (Docker, Maven, npm, pip, apt\/yum, Go tooling).<\/li>\n<li><strong>Integrates with deploy targets<\/strong>: Cloud Run, GKE, and Cloud Build support pulling\/pushing naturally.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed service<\/strong>: No patching or operating a self-hosted registry cluster.<\/li>\n<li><strong>Auditability<\/strong>: Admin Activity and Data Access logs (depending on configuration and log type) help trace actions.<\/li>\n<li><strong>Lifecycle management<\/strong>: Cleanup\/retention features can help control repository growth (verify format-specific options in docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Least privilege IAM<\/strong> at repo level (reader\/writer\/admin separation).<\/li>\n<li><strong>Encryption at rest<\/strong> by default; <strong>CMEK<\/strong> may be supported for repositories (verify in docs for your configuration).<\/li>\n<li><strong>Organization controls<\/strong>: Works with org policies and VPC Service Controls (verify your perimeter design).<\/li>\n<li><strong>Supply chain hooks<\/strong>: Vulnerability scanning and attestations via Artifact Analysis \/ Container Analysis for container images (verify coverage).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Regional placement<\/strong> reduces latency and can reduce egress costs when colocated with compute.<\/li>\n<li><strong>Multi-region<\/strong> can improve availability and global access patterns (verify availability and tradeoffs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose Artifact Registry when you:\n&#8211; Deploy containers to <strong>Cloud Run or GKE<\/strong>, and want a private registry with Google Cloud IAM.\n&#8211; Need to host <strong>internal packages<\/strong> (Java, Node, Python, OS packages) for multiple teams.\n&#8211; Want <strong>consistent governance<\/strong>: repo naming, access control, audit trails, retention.\n&#8211; Are migrating from <strong>Container Registry<\/strong> and want the recommended path forward.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Consider alternatives when:\n&#8211; You must run in an <strong>air-gapped<\/strong> environment with no cloud dependency (self-managed registry may be required).\n&#8211; You already standardized on another enterprise artifact platform (JFrog, Nexus) and migration cost outweighs benefits.\n&#8211; You have extreme cross-cloud requirements where a cloud-neutral registry platform is mandated (though Artifact Registry can still be used with federation from other environments\u2014verify viability).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Artifact Registry used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SaaS and software product companies (microservices, frequent releases)<\/li>\n<li>Finance and regulated industries (audit trails, controlled access)<\/li>\n<li>Retail\/e-commerce (seasonal traffic, fast iteration)<\/li>\n<li>Media\/gaming (high-volume builds, multiple environments)<\/li>\n<li>Healthcare and public sector (data residency and compliance-driven controls)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Application development teams publishing images\/packages<\/li>\n<li>Platform engineering teams providing golden paths<\/li>\n<li>DevOps\/SRE teams managing CI\/CD, release, and runtime access<\/li>\n<li>Security teams implementing software supply chain controls<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads and architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Microservices on <strong>GKE<\/strong> pulling images from Artifact Registry<\/li>\n<li>Serverless services on <strong>Cloud Run<\/strong><\/li>\n<li>Batch processing images for <strong>Cloud Run jobs<\/strong> or GKE Jobs<\/li>\n<li>Internal package ecosystems (private npm\/pypi\/maven)<\/li>\n<li>Hybrid CI: GitHub Actions\/Jenkins building and pushing to Google Cloud using Workload Identity Federation (recommended over long-lived keys)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production<\/strong>: strict IAM, separate repos per env\/team, vulnerability scanning, promotion controls<\/li>\n<li><strong>Dev\/Test<\/strong>: fast iteration, shorter retention, relaxed access (still authenticated), smaller quotas<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic use cases that show how Artifact Registry fits into Google Cloud application development.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Private container registry for Cloud Run services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You need a secure place to store container images for Cloud Run deployments.<\/li>\n<li><strong>Why Artifact Registry fits<\/strong>: Native integration with Cloud Run and IAM-controlled image pulls.<\/li>\n<li><strong>Example<\/strong>: A team builds <code>orders-api<\/code> in Cloud Build and deploys to Cloud Run using <code>REGION-docker.pkg.dev\/PROJECT\/prod-repo\/orders-api:1.4.0<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Container image hub for GKE microservices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Multiple services need consistent, fast access to images with controlled permissions.<\/li>\n<li><strong>Why it fits<\/strong>: Regional repositories reduce latency; IAM controls who can push\/pull.<\/li>\n<li><strong>Example<\/strong>: A platform team hosts <code>gke-images<\/code> repo; namespaces use service accounts to pull but only CI can push.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Organization-wide base images (\u201cgolden images\u201d)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Developers start from inconsistent base images and patching is uneven.<\/li>\n<li><strong>Why it fits<\/strong>: Central repo for hardened base images; controlled updates and deprecation.<\/li>\n<li><strong>Example<\/strong>: Security publishes <code>base\/python:3.12-secure<\/code> and teams must inherit from it.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Private Maven repository for internal Java libraries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Internal libraries shouldn\u2019t be published to public Maven repositories.<\/li>\n<li><strong>Why it fits<\/strong>: Maven format support; IAM restricts who can publish.<\/li>\n<li><strong>Example<\/strong>: <code>com.example.platform:auth-sdk<\/code> is versioned and consumed via Gradle from Artifact Registry.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Private npm registry for shared frontend components<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Shared UI components need private distribution across teams.<\/li>\n<li><strong>Why it fits<\/strong>: npm format repo with controlled publishing.<\/li>\n<li><strong>Example<\/strong>: Design system publishes <code>@company\/ui-kit<\/code> and multiple apps consume it.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Private Python package index for ML and backend utilities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Internal Python utilities and ML helpers must be versioned and reused safely.<\/li>\n<li><strong>Why it fits<\/strong>: Python repository format and IAM.<\/li>\n<li><strong>Example<\/strong>: Data team publishes <code>company-feature-store==0.9.3<\/code> for batch pipelines.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Cached\/proxied access to upstream package ecosystems (remote repositories)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Builds are slow\/unreliable because they hit public registries directly; you need caching and control.<\/li>\n<li><strong>Why it fits<\/strong>: Artifact Registry remote repositories can proxy\/cache upstreams (verify supported formats and configuration).<\/li>\n<li><strong>Example<\/strong>: CI pulls npm dependencies via a remote repo that caches commonly used packages.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Central OS package repository for APT\/YUM<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Fleet images and build systems require controlled OS packages.<\/li>\n<li><strong>Why it fits<\/strong>: Supports APT\/YUM repositories (verify exact setup for your distro).<\/li>\n<li><strong>Example<\/strong>: Ops publishes signed packages for internal agents; VM images install via apt from Artifact Registry.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Multi-environment promotion (dev \u2192 staging \u2192 prod)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You need controlled promotion, not \u201clatest tag drift.\u201d<\/li>\n<li><strong>Why it fits<\/strong>: Immutable references via digests, plus integration with Cloud Deploy and policy tooling.<\/li>\n<li><strong>Example<\/strong>: CI pushes to <code>dev-repo<\/code>, then Cloud Deploy promotes digests to <code>prod-repo<\/code> after approvals.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Supply-chain security with scanning and attestations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You must detect vulnerable images and enforce policy before deploy.<\/li>\n<li><strong>Why it fits<\/strong>: Integrates with Artifact Analysis \/ Container Analysis for vulnerability data and attestations (commonly for containers).<\/li>\n<li><strong>Example<\/strong>: Pipeline gates deployments if critical vulns exceed policy; only attested images are allowed (verify your enforcement method such as Binary Authorization).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Cross-project shared repository model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Central platform project produces artifacts; many app projects consume them.<\/li>\n<li><strong>Why it fits<\/strong>: IAM can grant reader access cross-project; centralizes governance.<\/li>\n<li><strong>Example<\/strong>: <code>platform-prod<\/code> hosts <code>base-images<\/code>; app projects get <code>roles\/artifactregistry.reader<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) External CI (GitHub Actions\/Jenkins) publishing to Google Cloud securely<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Avoid long-lived service account keys while enabling pushes from external CI.<\/li>\n<li><strong>Why it fits<\/strong>: Workload Identity Federation + Artifact Registry permissions.<\/li>\n<li><strong>Example<\/strong>: GitHub Actions obtains short-lived tokens via federation and pushes container images.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>Feature availability can vary by artifact format and release stage. Always verify format-specific behavior in official documentation.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Multi-format repositories (containers + packages)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Lets you host multiple artifact ecosystems using one Google Cloud service.<\/li>\n<li><strong>Why it matters<\/strong>: Reduces tool sprawl and standardizes IAM\/auditing.<\/li>\n<li><strong>Practical benefit<\/strong>: A platform team can offer \u201cone place\u201d for containers and internal libraries.<\/li>\n<li><strong>Caveats<\/strong>: Each repository is created for a specific format (for example, Docker vs Maven). You typically don\u2019t mix formats inside one repo.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Regional \/ multi-regional repository locations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Repositories live in a chosen location.<\/li>\n<li><strong>Why it matters<\/strong>: Latency, availability, and data residency requirements.<\/li>\n<li><strong>Practical benefit<\/strong>: Keep artifacts close to build and runtime to reduce pull times and potential egress.<\/li>\n<li><strong>Caveats<\/strong>: Cross-region pulls can add latency and network costs. Plan location strategy early.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) IAM-based access control<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Uses Google Cloud IAM roles to control read\/write\/admin at repository scope.<\/li>\n<li><strong>Why it matters<\/strong>: Enables least privilege and separation of duties.<\/li>\n<li><strong>Practical benefit<\/strong>: CI has write access; runtime has read access; developers can be read-only in prod.<\/li>\n<li><strong>Caveats<\/strong>: Misconfigured IAM is a common cause of push\/pull failures.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Standard registry endpoints and authentication patterns<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Provides domain endpoints like <code>LOCATION-docker.pkg.dev<\/code> for container images and corresponding endpoints for package formats.<\/li>\n<li><strong>Why it matters<\/strong>: Works with familiar tools (Docker, Maven, npm, pip).<\/li>\n<li><strong>Practical benefit<\/strong>: Developers don\u2019t need custom clients.<\/li>\n<li><strong>Caveats<\/strong>: Authentication differs by environment (Cloud Shell, GCE, GKE, external CI). Validate your auth path.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Integration with Cloud Build<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Cloud Build can build and push images to Artifact Registry.<\/li>\n<li><strong>Why it matters<\/strong>: Eliminates the need to run Docker builds on developer machines.<\/li>\n<li><strong>Practical benefit<\/strong>: Reproducible builds, centralized logs, easier auditing.<\/li>\n<li><strong>Caveats<\/strong>: Cloud Build service account needs Artifact Registry write permissions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Integration with Cloud Run \/ GKE<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Cloud Run and GKE can pull images from Artifact Registry.<\/li>\n<li><strong>Why it matters<\/strong>: Artifact storage is part of a secure deploy pipeline.<\/li>\n<li><strong>Practical benefit<\/strong>: Fast, authenticated pulls without manual secrets in many Google-managed runtimes.<\/li>\n<li><strong>Caveats<\/strong>: Cross-project or cross-org pulls require explicit IAM grants.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Vulnerability scanning and metadata (via Artifact Analysis \/ Container Analysis)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Stores vulnerability findings and artifact metadata for container images (and potentially other artifact types depending on your configuration\u2014verify).<\/li>\n<li><strong>Why it matters<\/strong>: Supports software supply chain risk management.<\/li>\n<li><strong>Practical benefit<\/strong>: Gate deployments, track vulnerability posture over time.<\/li>\n<li><strong>Caveats<\/strong>: Scanning scope, frequency, and pricing can vary\u2014verify in official docs and pricing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Cleanup \/ retention controls (where supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Helps manage old versions and reduce storage bloat.<\/li>\n<li><strong>Why it matters<\/strong>: Artifact registries grow quickly without lifecycle rules.<\/li>\n<li><strong>Practical benefit<\/strong>: Keep last N versions or delete artifacts older than X days (verify capabilities per format).<\/li>\n<li><strong>Caveats<\/strong>: Incorrect cleanup policies can delete needed rollback versions. Test in non-prod first.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Customer-managed encryption keys (CMEK) (if enabled\/available)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Allows using Cloud KMS keys to encrypt repository data.<\/li>\n<li><strong>Why it matters<\/strong>: Meets stricter compliance requirements.<\/li>\n<li><strong>Practical benefit<\/strong>: Central key control, rotation, separation of duties.<\/li>\n<li><strong>Caveats<\/strong>: Key access misconfiguration can break access to artifacts; plan key lifecycle and permissions carefully. Verify CMEK support in your region\/format.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Governance integrations (Audit Logs, org policy, VPC-SC)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Works with Cloud Audit Logs, organization policies, and service perimeters (VPC Service Controls).<\/li>\n<li><strong>Why it matters<\/strong>: Production governance and compliance.<\/li>\n<li><strong>Practical benefit<\/strong>: Traceability and perimeter-based exfiltration controls.<\/li>\n<li><strong>Caveats<\/strong>: VPC-SC designs can block expected access if not configured carefully.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level service architecture<\/h3>\n\n\n\n<p>Artifact Registry consists of:\n&#8211; A <strong>control plane<\/strong> (Google Cloud APIs) used to create repositories, manage IAM, configure settings.\n&#8211; A <strong>data plane<\/strong> (artifact endpoints like <code>*.pkg.dev<\/code>) used by clients to push and pull artifacts.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow (common container workflow)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>An engineer or CI system authenticates with Google Cloud (user credentials, service account, or federated identity).<\/li>\n<li>CI builds an image (locally or using Cloud Build).<\/li>\n<li>CI pushes the image layers and manifest to an Artifact Registry repository endpoint.<\/li>\n<li>Artifact Registry stores the image and records metadata.<\/li>\n<li>A runtime (Cloud Run, GKE, etc.) pulls the image when deploying or starting.<\/li>\n<li>Optional: Artifact Analysis scans the image and stores vulnerability metadata; policy tools gate deployments (verify enforcement approach).<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Build<\/strong>: build + push; can also run tests and sign\/attest (verify your supply-chain setup).<\/li>\n<li><strong>Cloud Deploy<\/strong>: progressive delivery and promotion workflows referencing Artifact Registry images.<\/li>\n<li><strong>Cloud Run<\/strong>: deploys containers pulled from Artifact Registry.<\/li>\n<li><strong>GKE<\/strong>: Kubernetes image pulls; node and workload identities must have access.<\/li>\n<li><strong>Artifact Analysis \/ Container Analysis<\/strong>: vulnerability findings and attestations.<\/li>\n<li><strong>Binary Authorization<\/strong> (commonly with GKE): enforce only trusted\/attested images (verify current integration patterns).<\/li>\n<li><strong>Cloud Logging \/ Monitoring<\/strong>: audit and operational insights.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM<\/strong> (identity and access management)<\/li>\n<li><strong>Cloud Storage-like managed storage<\/strong> under the hood (you don\u2019t manage buckets directly)<\/li>\n<li><strong>Cloud KMS<\/strong> (for CMEK use cases)<\/li>\n<li><strong>Cloud Audit Logs<\/strong><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Primary auth<\/strong>: IAM principals (users, groups, service accounts) with roles such as:<\/li>\n<li><code>roles\/artifactregistry.reader<\/code><\/li>\n<li><code>roles\/artifactregistry.writer<\/code><\/li>\n<li><code>roles\/artifactregistry.repoAdmin<\/code><\/li>\n<li><code>roles\/artifactregistry.admin<\/code><\/li>\n<li><strong>Docker auth<\/strong>: commonly uses <code>gcloud auth configure-docker<\/code> to configure credential helpers for <code>*.pkg.dev<\/code>.<\/li>\n<li><strong>External CI<\/strong>: prefer <strong>Workload Identity Federation<\/strong> to avoid service account keys.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Artifact endpoints are accessed via HTTPS.<\/li>\n<li>For private connectivity patterns, teams often use:<\/li>\n<li><strong>Private Google Access<\/strong> (from GCE\/GKE) where applicable<\/li>\n<li><strong>Private Service Connect for Google APIs<\/strong> (for private API access patterns)<\/li>\n<li><strong>VPC Service Controls<\/strong> perimeters (to reduce data exfiltration risk)<\/li>\n<\/ul>\n\n\n\n<p>Verify your networking approach in official docs because implementations differ by environment and org policies.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Audit Logs<\/strong>: track repository and artifact access and admin actions.<\/li>\n<li><strong>Cloud Logging<\/strong>: centralize logs, set alerts for unusual access.<\/li>\n<li><strong>Quotas<\/strong>: enforce guardrails and monitor request rates.<\/li>\n<li><strong>Tagging\/labels<\/strong>: apply labels to repositories for cost allocation and ownership.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  Dev[Developer laptop \/ Cloud Shell] --&gt;|docker push \/ package publish| AR[Artifact Registry Repository]\n  CI[CI\/CD: Cloud Build] --&gt;|build + push| AR\n  AR --&gt;|docker pull| Run[Cloud Run \/ GKE \/ Compute Engine]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph \"Source &amp; CI\"\n    Git[Source Repo (GitHub\/CSR)] --&gt; CB[Cloud Build]\n    CB --&gt;|push image by digest| AR[(Artifact Registry&lt;br\/&gt;Regional Repo)]\n  end\n\n  subgraph \"Security &amp; Governance\"\n    IAM[IAM: least privilege] --- AR\n    AA[Artifact Analysis \/ Container Analysis&lt;br\/&gt;vulns + metadata] --- AR\n    KMS[Cloud KMS (CMEK optional)] --- AR\n    LOG[Cloud Audit Logs] --- AR\n    VPCSC[VPC Service Controls (optional)] --- AR\n  end\n\n  subgraph \"Release\"\n    CD[Cloud Deploy (optional)] --&gt;|promote| AR\n  end\n\n  subgraph \"Runtime\"\n    CR[Cloud Run] --&gt;|pull by digest| AR\n    GKE[GKE] --&gt;|pull by digest| AR\n  end\n\n  CB --&gt; LOG\n  CR --&gt; LOG\n  GKE --&gt; LOG\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<p>Before you start using Artifact Registry in Google Cloud, ensure the following.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/project requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A <strong>Google Cloud project<\/strong> with <strong>billing enabled<\/strong>.<\/li>\n<li>Organization policies (if any) reviewed (some orgs restrict which services\/locations can be used).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>You need permissions to:\n&#8211; Enable APIs: typically <code>roles\/serviceusage.serviceUsageAdmin<\/code> (or project Owner).\n&#8211; Create and manage repositories: <code>roles\/artifactregistry.admin<\/code> or <code>roles\/artifactregistry.repoAdmin<\/code>.\n&#8211; Push\/pull artifacts: <code>roles\/artifactregistry.writer<\/code> and\/or <code>roles\/artifactregistry.reader<\/code>.<\/p>\n\n\n\n<p>For CI\/CD:\n&#8211; Identify the service account used by Cloud Build (commonly the project\u2019s Cloud Build service account) and ensure it has writer access to the target repository.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Artifact storage and usage are billable. Network egress and scanning features may also be billable depending on usage and configuration. Review pricing first.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>gcloud CLI<\/strong> (Cloud Shell includes it): https:\/\/cloud.google.com\/sdk\/docs\/install<\/li>\n<li>For container tutorial:<\/li>\n<li><strong>Docker CLI<\/strong> (Cloud Shell includes Docker in many environments; if unavailable, use Cloud Build).<\/li>\n<li>Optional:<\/li>\n<li><code>curl<\/code> for verification<\/li>\n<li><code>jq<\/code> for parsing output (optional)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Choose a repository location supported by Artifact Registry for your artifact format.<\/li>\n<li>Keep repo in the same region as build and runtime when possible.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Artifact Registry has quotas (API requests, repository counts, etc.). Do not assume defaults\u2014check:<\/li>\n<li>https:\/\/cloud.google.com\/artifact-registry\/quotas (verify official URL and current quota page)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<p>Commonly enabled APIs:\n&#8211; Artifact Registry API\n&#8211; Cloud Build API (if using Cloud Build)\n&#8211; Cloud Run API (if deploying to Cloud Run)\n&#8211; IAM APIs (typically already enabled)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Artifact Registry pricing is <strong>usage-based<\/strong> and varies by <strong>location<\/strong> and usage pattern. Do not rely on static numbers in blog posts; always check the official pricing page and the Google Cloud Pricing Calculator.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Official pricing: https:\/\/cloud.google.com\/artifact-registry\/pricing  <\/li>\n<li>Pricing calculator: https:\/\/cloud.google.com\/products\/calculator<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (typical)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Storage (GB-month)<\/strong>\n   &#8211; You pay for artifact storage consumed by images\/packages and their versions.\n   &#8211; Storage cost commonly varies by region\/multi-region.<\/p>\n<\/li>\n<li>\n<p><strong>Network\/data transfer<\/strong>\n   &#8211; Pulling artifacts to runtimes in different regions, to on-prem, or to the internet may incur egress charges.\n   &#8211; Intra-region traffic can be cheaper than cross-region\/internet traffic (verify networking SKUs for your scenario).<\/p>\n<\/li>\n<li>\n<p><strong>Requests\/operations (if applicable)<\/strong>\n   &#8211; Some artifact services charge per number of requests (uploads\/downloads\/list operations). Verify whether Artifact Registry charges request fees for your artifact format and repo type on the current pricing page.<\/p>\n<\/li>\n<li>\n<p><strong>Vulnerability scanning \/ metadata features (if enabled)<\/strong>\n   &#8211; Scanning (via Artifact Analysis \/ Container Analysis) may have its own pricing model.\n   &#8211; Verify scanning coverage and pricing for your artifact type.<\/p>\n<\/li>\n<li>\n<p><strong>CI build costs<\/strong>\n   &#8211; Cloud Build minutes and machine types are billed separately.\n   &#8211; If you use Cloud Run\/GKE, runtime costs are separate from Artifact Registry.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier (if applicable)<\/h3>\n\n\n\n<p>Google Cloud sometimes offers free usage tiers for certain products, often limited and subject to change. <strong>Verify the current free tier<\/strong> for Artifact Registry on the official pricing page.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Large container images (big base layers, many dependencies)<\/li>\n<li>High deployment frequency (lots of versions)<\/li>\n<li>\u201cForever retention\u201d of old versions and tags<\/li>\n<li>Cross-region pulls (multi-region teams pulling from one region)<\/li>\n<li>Heavy CI traffic pulling dependencies repeatedly (remote repos can reduce upstream traffic but still serve bytes internally\u2014verify pricing)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Egress<\/strong>: The most common surprise. Pulls across regions or to external environments can dominate cost.<\/li>\n<li><strong>Duplicate storage<\/strong>: Many similar images with slightly different layers can still consume storage.<\/li>\n<li><strong>Artifact sprawl<\/strong>: Thousands of versions without cleanup policies.<\/li>\n<li><strong>Security tooling<\/strong>: scanning\/attestations may add costs depending on configuration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep repositories <strong>close to builds and runtimes<\/strong> (same region) when possible.<\/li>\n<li>Use <strong>smaller base images<\/strong> and reduce build context size.<\/li>\n<li>Use <strong>multi-stage Docker builds<\/strong> to avoid shipping build tools.<\/li>\n<li>Implement <strong>cleanup\/retention policies<\/strong> (test carefully).<\/li>\n<li>Use <strong>image digests<\/strong> for promotion instead of duplicating images across repos when appropriate (or use a controlled promotion approach\u2014tradeoffs depend on governance needs).<\/li>\n<li>Avoid repeatedly pulling large images in CI; use caching mechanisms and remote repositories where it makes sense (verify pricing).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (no fabricated numbers)<\/h3>\n\n\n\n<p>A typical starter setup:\n&#8211; 1 Docker repository in one region\n&#8211; A few small images (for example, a hello-world service) with a handful of versions\n&#8211; Occasional pulls from Cloud Run in the same region<br\/>\nCosts are usually dominated by <strong>storage<\/strong> (small) plus whatever <strong>Cloud Run<\/strong> and <strong>Cloud Build<\/strong> usage you incur. For exact amounts, model:\n&#8211; Estimated GB stored\n&#8211; Expected monthly pulls and egress pattern<br\/>\nThen validate in the Pricing Calculator.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, cost planning should include:\n&#8211; Storage growth from frequent releases across many services\n&#8211; Retention window for rollback (for example, keep last 30\u201390 days)\n&#8211; Multi-region runtime pulls and disaster recovery requirements\n&#8211; CI traffic volume (build frequency, parallel builds)\n&#8211; Security scanning overhead and policy enforcement workflow<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab creates a Docker repository in Artifact Registry, builds and pushes a container image using Cloud Build, and deploys it to Cloud Run.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create an <strong>Artifact Registry Docker repository<\/strong><\/li>\n<li>Build and push a container image to Artifact Registry<\/li>\n<li>Deploy the image to <strong>Cloud Run<\/strong><\/li>\n<li>Verify the deployment and the artifact<\/li>\n<li>Clean up resources to avoid ongoing costs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Set project variables and enable required APIs\n2. Create a Docker repository in Artifact Registry\n3. Configure authentication to push\/pull\n4. Build and push a sample container image with Cloud Build\n5. Deploy to Cloud Run\n6. Validate and troubleshoot\n7. Clean up<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set project and location variables<\/h3>\n\n\n\n<p>Use Cloud Shell (recommended) so you don\u2019t have to install tools locally.<\/p>\n\n\n\n<p>In Cloud Shell, set environment variables:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export PROJECT_ID=\"$(gcloud config get-value project)\"\nexport REGION=\"us-central1\"          # choose a region you are allowed to use\nexport REPO=\"app-images\"\nexport IMAGE=\"hello-ar\"\n<\/code><\/pre>\n\n\n\n<p>Set the default region for Cloud Run:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud config set run\/region \"$REGION\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Variables are set; Cloud Run default region is configured.<\/p>\n\n\n\n<p><strong>Verification:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">echo \"$PROJECT_ID $REGION $REPO $IMAGE\"\ngcloud config get-value run\/region\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Enable required APIs<\/h3>\n\n\n\n<p>Enable Artifact Registry, Cloud Build, and Cloud Run APIs:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable \\\n  artifactregistry.googleapis.com \\\n  cloudbuild.googleapis.com \\\n  run.googleapis.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> APIs enabled successfully.<\/p>\n\n\n\n<p><strong>Verification:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services list --enabled --filter=\"name:artifactregistry.googleapis.com OR name:cloudbuild.googleapis.com OR name:run.googleapis.com\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create an Artifact Registry Docker repository<\/h3>\n\n\n\n<p>Create a <strong>Docker<\/strong> format repository:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts repositories create \"$REPO\" \\\n  --repository-format=docker \\\n  --location=\"$REGION\" \\\n  --description=\"Docker repo for Cloud Run tutorial\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Repository created in the chosen region.<\/p>\n\n\n\n<p><strong>Verification:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts repositories list --location=\"$REGION\"\ngcloud artifacts repositories describe \"$REPO\" --location=\"$REGION\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Configure Docker authentication for Artifact Registry<\/h3>\n\n\n\n<p>Configure Docker to authenticate to the Artifact Registry domain for your region:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud auth configure-docker \"${REGION}-docker.pkg.dev\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Docker credential helper configuration updated.<\/p>\n\n\n\n<p><strong>Verification:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">cat ~\/.docker\/config.json | sed -n '1,200p'\n<\/code><\/pre>\n\n\n\n<p>Look for an entry referencing <code>docker-credential-gcloud<\/code> and your <code>*.pkg.dev<\/code> domain.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Create a small sample app and Dockerfile<\/h3>\n\n\n\n<p>Create a minimal HTTP server (Python + Flask) to run on Cloud Run.<\/p>\n\n\n\n<pre><code class=\"language-bash\">mkdir -p ~\/ar-lab &amp;&amp; cd ~\/ar-lab\n<\/code><\/pre>\n\n\n\n<p>Create <code>app.py<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; app.py &lt;&lt;'EOF'\nimport os\nfrom flask import Flask\n\napp = Flask(__name__)\n\n@app.get(\"\/\")\ndef hello():\n    return \"Hello from Artifact Registry on Cloud Run!\\n\"\n\nif __name__ == \"__main__\":\n    port = int(os.environ.get(\"PORT\", \"8080\"))\n    app.run(host=\"0.0.0.0\", port=port)\nEOF\n<\/code><\/pre>\n\n\n\n<p>Create <code>requirements.txt<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; requirements.txt &lt;&lt;'EOF'\nflask==3.0.3\ngunicorn==22.0.0\nEOF\n<\/code><\/pre>\n\n\n\n<p>Create <code>Dockerfile<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; Dockerfile &lt;&lt;'EOF'\nFROM python:3.12-slim\n\nENV PYTHONDONTWRITEBYTECODE=1\nENV PYTHONUNBUFFERED=1\n\nWORKDIR \/app\nCOPY requirements.txt .\nRUN pip install --no-cache-dir -r requirements.txt\n\nCOPY app.py .\n\n# Cloud Run listens on $PORT\nCMD exec gunicorn --bind :${PORT:-8080} --workers 1 --threads 8 app:app\nEOF\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> App source and Dockerfile exist.<\/p>\n\n\n\n<p><strong>Verification:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">ls -la\nsed -n '1,120p' Dockerfile\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Build and push the container image with Cloud Build<\/h3>\n\n\n\n<p>Define the full image path (Artifact Registry repository URL):<\/p>\n\n\n\n<pre><code class=\"language-bash\">export IMAGE_URI=\"${REGION}-docker.pkg.dev\/${PROJECT_ID}\/${REPO}\/${IMAGE}:v1\"\necho \"$IMAGE_URI\"\n<\/code><\/pre>\n\n\n\n<p>Submit the build to Cloud Build and push to Artifact Registry:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud builds submit --tag \"$IMAGE_URI\" .\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Cloud Build completes and the image is pushed to Artifact Registry.<\/p>\n\n\n\n<p><strong>Verification (list images):<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts docker images list \"${REGION}-docker.pkg.dev\/${PROJECT_ID}\/${REPO}\"\n<\/code><\/pre>\n\n\n\n<p>You should see the <code>hello-ar<\/code> image.<\/p>\n\n\n\n<p><strong>Verification (list tags):<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts docker tags list \"${REGION}-docker.pkg.dev\/${PROJECT_ID}\/${REPO}\/${IMAGE}\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Deploy the image to Cloud Run<\/h3>\n\n\n\n<p>Deploy to Cloud Run using the image from Artifact Registry:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud run deploy \"${IMAGE}\" \\\n  --image \"$IMAGE_URI\" \\\n  --allow-unauthenticated\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Cloud Run creates a service and provides a service URL.<\/p>\n\n\n\n<p><strong>Verification:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">SERVICE_URL=\"$(gcloud run services describe ${IMAGE} --format='value(status.url)')\"\necho \"$SERVICE_URL\"\ncurl -sS \"$SERVICE_URL\"\n<\/code><\/pre>\n\n\n\n<p>You should get:\n&#8211; <code>Hello from Artifact Registry on Cloud Run!<\/code><\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8 (Optional): View artifact details in the console<\/h3>\n\n\n\n<p>In Google Cloud Console:\n&#8211; Go to <strong>Artifact Registry<\/strong> \u2192 <strong>Repositories<\/strong> \u2192 your repo \u2192 your image\n&#8211; Check versions and tags<\/p>\n\n\n\n<p>Console entry point: https:\/\/console.cloud.google.com\/artifacts<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> You can see the stored image and its metadata.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>You have successfully validated:\n&#8211; Repository exists:\n  <code>bash\n  gcloud artifacts repositories describe \"$REPO\" --location=\"$REGION\"<\/code>\n&#8211; Image exists in Artifact Registry:\n  <code>bash\n  gcloud artifacts docker images list \"${REGION}-docker.pkg.dev\/${PROJECT_ID}\/${REPO}\"<\/code>\n&#8211; Cloud Run service pulls and runs the image:\n  <code>bash\n  curl -sS \"$SERVICE_URL\"<\/code><\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and fixes:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong><code>PERMISSION_DENIED<\/code> when pushing to Artifact Registry<\/strong>\n   &#8211; Cause: Your identity or Cloud Build service account lacks permissions.\n   &#8211; Fix:<\/p>\n<ul>\n<li>Ensure you have <code>roles\/artifactregistry.writer<\/code> on the repository or project.<\/li>\n<li>If using Cloud Build, grant the Cloud Build service account permissions.<br\/>\n   Cloud Build service account is often:<br\/>\n<code>PROJECT_NUMBER@cloudbuild.gserviceaccount.com<\/code><br\/>\n   (Verify in your project.)<\/li>\n<\/ul>\n<\/li>\n<li>\n<p><strong>Docker auth not configured<\/strong>\n   &#8211; Symptom: <code>denied: Permission \"artifactregistry.repositories.downloadArtifacts\" denied<\/code>\n   &#8211; Fix:\n     <code>bash\n     gcloud auth configure-docker \"${REGION}-docker.pkg.dev\"<\/code><\/p>\n<\/li>\n<li>\n<p><strong>Deploy fails because image not found<\/strong>\n   &#8211; Cause: Wrong image URI (region\/repo\/project mismatch).\n   &#8211; Fix:<\/p>\n<ul>\n<li>Recompute:\n   <code>bash\n   echo \"${REGION}-docker.pkg.dev\/${PROJECT_ID}\/${REPO}\/${IMAGE}:v1\"<\/code><\/li>\n<li>List images in the repo to confirm the exact path.<\/li>\n<\/ul>\n<\/li>\n<li>\n<p><strong>Cloud Run returns 500<\/strong>\n   &#8211; Cause: Container not listening on <code>$PORT<\/code>.\n   &#8211; Fix:<\/p>\n<ul>\n<li>Ensure your app listens on <code>${PORT:-8080}<\/code> and binds <code>0.0.0.0<\/code>.<\/li>\n<li>Check logs:\n   <code>bash\n   gcloud logs read --limit=50 --project \"$PROJECT_ID\" \\\n     --format=\"value(textPayload)\" \\\n     --filter=\"resource.type=cloud_run_revision AND resource.labels.service_name=${IMAGE}\"<\/code><\/li>\n<\/ul>\n<\/li>\n<li>\n<p><strong>Build fails due to dependency download issues<\/strong>\n   &#8211; Cause: transient network or upstream dependency issues.\n   &#8211; Fix: rerun <code>gcloud builds submit ...<\/code> and consider dependency pinning and caching strategies.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing costs, delete the Cloud Run service and the Artifact Registry repository (which deletes stored images).<\/p>\n\n\n\n<p>Delete Cloud Run service:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud run services delete \"${IMAGE}\" --quiet\n<\/code><\/pre>\n\n\n\n<p>Delete the repository:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts repositories delete \"$REPO\" \\\n  --location=\"$REGION\" --quiet\n<\/code><\/pre>\n\n\n\n<p><strong>Verification:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud run services list\ngcloud artifacts repositories list --location=\"$REGION\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Choose repository locations intentionally<\/strong>:<\/li>\n<li>Same region as Cloud Build and Cloud Run\/GKE when possible.<\/li>\n<li>Use multi-region only when you truly need it (tradeoffs: cost, residency, control).<\/li>\n<li><strong>Separate repositories by boundary<\/strong>:<\/li>\n<li>By environment (dev\/staging\/prod) and\/or by sensitivity (public base vs internal).<\/li>\n<li><strong>Use digests for production deployments<\/strong>:<\/li>\n<li>Tags can be moved; digests are immutable references. Promote by digest for stronger release integrity.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Least privilege<\/strong>:<\/li>\n<li>Runtime (Cloud Run\/GKE nodes) usually needs <strong>reader<\/strong>.<\/li>\n<li>CI needs <strong>writer<\/strong>.<\/li>\n<li>Only platform admins should have repo admin.<\/li>\n<li><strong>Avoid long-lived service account keys<\/strong>:<\/li>\n<li>Use Workload Identity Federation for external CI.<\/li>\n<li><strong>Use separate service accounts<\/strong> for build vs deploy vs runtime to reduce blast radius.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Implement retention\/cleanup policies appropriate to your rollback window.<\/li>\n<li>Keep images small; reduce unnecessary layers.<\/li>\n<li>Avoid cross-region pulls unless required.<\/li>\n<li>Monitor storage growth by repo\/team (use labels and billing reports).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use smaller base images and multi-stage builds.<\/li>\n<li>Keep dependencies pinned to reduce rebuild churn.<\/li>\n<li>Place repos near consumers; reduce latency.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid relying on <code>:latest<\/code> in production.<\/li>\n<li>Document rollback procedures using known-good digests\/tags.<\/li>\n<li>Establish artifact promotion workflows and approvals for prod.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Standardize naming:<\/li>\n<li>Repository: <code>team-env-format<\/code> or <code>env-team<\/code> (consistent across org)<\/li>\n<li>Image: <code>service-name<\/code><\/li>\n<li>Tags: <code>semver<\/code>, <code>git-sha<\/code>, <code>build-id<\/code><\/li>\n<li>Enable and review audit logs.<\/li>\n<li>Set alerts for unusual artifact download spikes (potential compromise or runaway deploy loops).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Apply <strong>labels<\/strong> on repositories (owner, cost-center, env, data-classification).<\/li>\n<li>Use consistent IAM groups rather than individual users.<\/li>\n<li>Define policies for:<\/li>\n<li>who can publish to prod repos<\/li>\n<li>retention windows<\/li>\n<li>vulnerability thresholds (where scanning is used)<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<p>Artifact Registry relies on <strong>IAM<\/strong>:\n&#8211; Use repository-level IAM for granular control.\n&#8211; Prefer group-based access (Cloud Identity \/ Google Workspace groups) for humans.\n&#8211; Use service accounts for automation.<\/p>\n\n\n\n<p>Recommended role patterns:\n&#8211; Developers: reader on prod, writer on dev\n&#8211; CI service account: writer on dev\/staging, controlled writer on prod (or only via promotion job)\n&#8211; Runtime identities: reader only<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Encryption at rest is provided by Google Cloud by default.<\/li>\n<li><strong>CMEK<\/strong> may be used for stricter requirements (Cloud KMS). Verify:<\/li>\n<li>supported locations<\/li>\n<li>operational impact if key is disabled\/rotated<\/li>\n<li>required IAM on KMS keys<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Artifact endpoints are HTTPS-accessible.<\/li>\n<li>For tighter controls:<\/li>\n<li>Use <strong>VPC Service Controls<\/strong> to reduce exfiltration paths (careful: it can break external CI unless designed correctly).<\/li>\n<li>Use private access patterns (Private Google Access \/ Private Service Connect for Google APIs) depending on environment.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do not store registry passwords in CI logs.<\/li>\n<li>Prefer:<\/li>\n<li>short-lived tokens via federation<\/li>\n<li>service account identity attached to the workload (Cloud Run\/GKE)<\/li>\n<li>Avoid copying Docker config files (<code>config.json<\/code>) between machines.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>Cloud Audit Logs<\/strong> to track:<\/li>\n<li>repository creation\/deletion<\/li>\n<li>IAM changes<\/li>\n<li>artifact reads\/writes (depending on log types enabled and configured)<\/li>\n<li>Route logs to a centralized logging project if required by compliance.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<p>Common compliance requirements addressed by proper configuration:\n&#8211; Access control and separation of duties (IAM + approvals)\n&#8211; Data residency (repo location choice)\n&#8211; Encryption controls (CMEK)\n&#8211; Audit trails (Audit Logs retention + export)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Granting <code>artifactregistry.admin<\/code> too broadly<\/li>\n<li>Allowing developers to overwrite production tags without controls<\/li>\n<li>Using long-lived service account keys in GitHub Actions<\/li>\n<li>Not scanning or not gating deploys where required<\/li>\n<li>Keeping old vulnerable images indefinitely<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Deploy by digest; treat tags as pointers, not guarantees.<\/li>\n<li>Integrate scanning and policy gates appropriate to your risk profile.<\/li>\n<li>Use Binary Authorization for GKE when you need enforceable attestation-based controls (verify current recommended integration).<\/li>\n<li>Separate repos\/projects for production artifacts when necessary.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Always verify current limits in official documentation; the items below are common real-world gotchas.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations \/ constraints (typical)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Location matters<\/strong>: a repository is tied to a location; changing location later usually means migration.<\/li>\n<li><strong>Cross-project access<\/strong> requires explicit IAM grants and can be confusing in larger orgs.<\/li>\n<li><strong>Tag mutability<\/strong>: tags can be moved to different digests. If your process assumes tags are immutable, enforce controls and deploy by digest.<\/li>\n<li><strong>Tooling differences per format<\/strong>: workflows for Maven\/npm\/pip\/apt\/yum\/go are different; don\u2019t assume a Docker-like experience for all.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>API request quotas and repository limits exist.<\/li>\n<li>Burst pulls during large rollouts can hit rate limits if not designed well.<\/li>\n<li>Verify current quotas here (confirm in docs): https:\/\/cloud.google.com\/artifact-registry\/quotas<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Not all regions may support all features equally (CMEK, remote repos, etc.). Verify region support before standardizing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cross-region and internet egress from frequent pulls.<\/li>\n<li>Storing multiple large image variants and keeping them forever.<\/li>\n<li>Scanning and metadata features may add cost depending on configuration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>External CI auth mistakes (mixing key-based auth and federated auth).<\/li>\n<li>Docker credential helper not set for the correct <code>*.pkg.dev<\/code> hostname.<\/li>\n<li>Older tooling that assumes <code>gcr.io<\/code> workflows (Container Registry) may require updates.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Deleting a repository deletes artifacts (and can break deploys quickly).<\/li>\n<li>Cleanup policies can delete rollback versions if not carefully scoped.<\/li>\n<li>Promotion patterns: copying artifacts across repos vs referencing digests has governance and cost tradeoffs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges (Container Registry \u2192 Artifact Registry)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Image path changes (<code>gcr.io\/...<\/code> to <code>LOCATION-docker.pkg.dev\/...<\/code>).<\/li>\n<li>CI and deployment manifests must be updated.<\/li>\n<li>Access control must be revalidated.<\/li>\n<li>Verify the latest migration guide in official docs.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Artifact Registry is Google Cloud\u2019s native artifact repository service, but you should still compare it to other options depending on your needs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Alternatives in Google Cloud<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Container Registry (gcr.io)<\/strong> (legacy): older container image registry.<\/li>\n<li><strong>Cloud Storage<\/strong>: can store artifacts as objects but lacks registry semantics and tooling compatibility.<\/li>\n<li><strong>Self-managed registry on GKE\/Compute Engine<\/strong>: Harbor, Nexus, Artifactory, etc.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Alternatives in other clouds<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS Elastic Container Registry (ECR)<\/strong><\/li>\n<li><strong>Azure Container Registry (ACR)<\/strong><\/li>\n<li>Cross-cloud registries: GitHub Container Registry (GHCR), GitLab Container Registry<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Open-source \/ self-managed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Harbor<\/strong><\/li>\n<li><strong>Sonatype Nexus Repository<\/strong><\/li>\n<li><strong>JFrog Artifactory<\/strong> (commercial, self-managed or SaaS)<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Comparison table<\/h4>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Google Cloud Artifact Registry<\/strong><\/td>\n<td>Google Cloud-native app development, multi-format repos<\/td>\n<td>IAM integration, regional placement, managed ops, Cloud Build\/Run\/GKE integration<\/td>\n<td>Location planning required; cloud-specific endpoints<\/td>\n<td>You run workloads on Google Cloud and want native governance + low ops overhead<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Cloud Container Registry (legacy)<\/strong><\/td>\n<td>Existing legacy workloads<\/td>\n<td>Familiar <code>gcr.io<\/code> paths; older integrations<\/td>\n<td>Being superseded by Artifact Registry; fewer modern features<\/td>\n<td>Only as a temporary state while migrating (verify current guidance)<\/td>\n<\/tr>\n<tr>\n<td><strong>Cloud Storage (DIY artifacts)<\/strong><\/td>\n<td>Simple file distribution<\/td>\n<td>Cheap object storage; simple<\/td>\n<td>Not a real registry; no package semantics; weak tooling integration<\/td>\n<td>You only need file storage, not package\/OCI registry workflows<\/td>\n<\/tr>\n<tr>\n<td><strong>Harbor (self-managed)<\/strong><\/td>\n<td>On-prem\/hybrid, air-gapped<\/td>\n<td>Full control; policy features<\/td>\n<td>You operate it; scaling, HA, patching<\/td>\n<td>Regulated\/air-gapped environments or strict platform mandates<\/td>\n<\/tr>\n<tr>\n<td><strong>JFrog Artifactory \/ Nexus<\/strong><\/td>\n<td>Enterprise multi-cloud artifact standardization<\/td>\n<td>Rich enterprise features; many formats; mature governance<\/td>\n<td>Licensing cost; operational complexity<\/td>\n<td>Large enterprises standardizing artifact governance across clouds<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS ECR \/ Azure ACR<\/strong><\/td>\n<td>Workloads primarily on AWS\/Azure<\/td>\n<td>Tight integration in those clouds<\/td>\n<td>Not Google Cloud-native<\/td>\n<td>Choose if your main runtime is AWS\/Azure<\/td>\n<\/tr>\n<tr>\n<td><strong>GHCR\/GitLab registry<\/strong><\/td>\n<td>Git-centric workflows<\/td>\n<td>Integrated with SCM; easy developer UX<\/td>\n<td>IAM differs; may not meet org controls; egress\/perf varies<\/td>\n<td>Small teams centered on GitHub\/GitLab with simpler governance needs<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: regulated financial services CI\/CD platform<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong><\/li>\n<li>Hundreds of microservices on GKE and Cloud Run.<\/li>\n<li>Strict audit, least privilege, and supply-chain requirements.<\/li>\n<li>Need consistent artifact promotion and rollback.<\/li>\n<li><strong>Proposed architecture<\/strong><\/li>\n<li>Artifact Registry repositories per environment (<code>dev<\/code>, <code>staging<\/code>, <code>prod<\/code>) and per domain (payments, customer).<\/li>\n<li>Cloud Build builds and pushes to <code>dev<\/code> repo; Cloud Deploy promotes digests to <code>prod<\/code>.<\/li>\n<li>Artifact Analysis scanning + policy gates (enforcement design verified and approved by security).<\/li>\n<li>CMEK enabled for sensitive repos (where supported).<\/li>\n<li>VPC Service Controls for projects in scope of regulated boundary.<\/li>\n<li><strong>Why Artifact Registry was chosen<\/strong><\/li>\n<li>Native IAM and audit logs.<\/li>\n<li>Regional placement aligned with data residency requirements.<\/li>\n<li>Integrates with Google Cloud CI\/CD and runtime services.<\/li>\n<li><strong>Expected outcomes<\/strong><\/li>\n<li>Reduced operational burden compared to self-hosted registries.<\/li>\n<li>Faster audits with centralized logs and consistent access patterns.<\/li>\n<li>Lower risk of deploying unapproved artifacts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: single Cloud Run service with fast iteration<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong><\/li>\n<li>Small team shipping weekly; needs private images and simple deployments.<\/li>\n<li>Doesn\u2019t want to run registry infrastructure.<\/li>\n<li><strong>Proposed architecture<\/strong><\/li>\n<li>One Artifact Registry Docker repo in the same region as Cloud Run.<\/li>\n<li>Cloud Build triggers on Git push, builds, tags with Git SHA, pushes.<\/li>\n<li>Cloud Run deploys from Artifact Registry image.<\/li>\n<li>Basic cleanup policy to keep recent builds (verify cleanup feature availability).<\/li>\n<li><strong>Why Artifact Registry was chosen<\/strong><\/li>\n<li>Minimal setup, integrates naturally with Cloud Build and Cloud Run.<\/li>\n<li>IAM is straightforward; no secrets management for registry credentials in Cloud Run.<\/li>\n<li><strong>Expected outcomes<\/strong><\/li>\n<li>Repeatable deployments, easy rollbacks (by tag or digest).<\/li>\n<li>Predictable costs, low ops overhead.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Artifact Registry the same as Container Registry?<\/strong><br\/>\nNo. Artifact Registry is the newer, recommended service for container images and other artifact formats. Container Registry (<code>gcr.io<\/code>) is legacy and is being superseded. Verify current migration guidance in official docs.<\/p>\n\n\n\n<p>2) <strong>What artifact formats does Artifact Registry support?<\/strong><br\/>\nCommon formats include Docker\/OCI images, Maven, npm, Python, APT, YUM, and Go modules. Confirm the current supported formats and any preview limitations here: https:\/\/cloud.google.com\/artifact-registry\/docs<\/p>\n\n\n\n<p>3) <strong>Is Artifact Registry global?<\/strong><br\/>\nRepositories are created in a specific location (regional or multi-regional). Your repository endpoint includes the location (for example, <code>us-central1-docker.pkg.dev<\/code>). Choose locations intentionally for latency and residency.<\/p>\n\n\n\n<p>4) <strong>How do I authenticate Docker to Artifact Registry?<\/strong><br\/>\nA common approach is:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud auth configure-docker REGION-docker.pkg.dev\n<\/code><\/pre>\n\n\n\n<p>This configures Docker to use <code>gcloud<\/code> as a credential helper.<\/p>\n\n\n\n<p>5) <strong>How does Cloud Run pull images from Artifact Registry? Do I need imagePullSecrets?<\/strong><br\/>\nOften, Cloud Run can pull using the service identity and IAM permissions without manually managing Docker secrets. For cross-project or restricted setups, you may need explicit IAM grants. Verify your exact configuration.<\/p>\n\n\n\n<p>6) <strong>What IAM role is needed to push images?<\/strong><br\/>\nTypically <code>roles\/artifactregistry.writer<\/code> on the repository (or broader scope). Admin roles exist for management tasks.<\/p>\n\n\n\n<p>7) <strong>Should I deploy using tags or digests?<\/strong><br\/>\nFor production, prefer <strong>digests<\/strong> for immutability and auditability. Tags are convenient but mutable unless you enforce controls.<\/p>\n\n\n\n<p>8) <strong>Can I use Artifact Registry from GitHub Actions without a service account key?<\/strong><br\/>\nYes\u2014use <strong>Workload Identity Federation<\/strong> to obtain short-lived credentials. This is the recommended approach. Verify the current setup guides in official docs.<\/p>\n\n\n\n<p>9) <strong>Does Artifact Registry support vulnerability scanning?<\/strong><br\/>\nArtifact Registry integrates with Artifact Analysis \/ Container Analysis for container image vulnerability data and metadata. Verify scanning availability, configuration steps, and pricing for your artifact type.<\/p>\n\n\n\n<p>10) <strong>Can I mirror\/cache public dependencies (npm\/pypi\/maven)?<\/strong><br\/>\nArtifact Registry supports remote repositories for some package ecosystems (proxy\/cache behavior). Verify which formats support remote repositories and the pricing model.<\/p>\n\n\n\n<p>11) <strong>How do I control storage growth?<\/strong><br\/>\nUse cleanup\/retention policies where supported, delete unused versions, and standardize retention windows (for example, keep last N builds). Test cleanup in non-prod to avoid deleting rollback artifacts.<\/p>\n\n\n\n<p>12) <strong>What\u2019s the best repository strategy: one repo or many?<\/strong><br\/>\nDepends on governance:\n&#8211; One repo is simpler but can be noisy and harder to secure by team\/env.\n&#8211; Multiple repos allow clearer IAM boundaries and environment separation.<br\/>\nMany orgs choose \u201crepo per env\u201d or \u201crepo per team + env\u201d.<\/p>\n\n\n\n<p>13) <strong>Can I use Artifact Registry for Helm charts?<\/strong><br\/>\nHelm can store charts as OCI artifacts in OCI-compatible registries. Artifact Registry Docker\/OCI repositories may work with Helm OCI workflows, but verify current official guidance and tool compatibility for your Helm version.<\/p>\n\n\n\n<p>14) <strong>What happens if I delete a repository?<\/strong><br\/>\nArtifacts in that repository are deleted, which can break deployments that reference those images\/packages. Use caution and implement safeguards (approvals, backups, policy).<\/p>\n\n\n\n<p>15) <strong>How do I migrate from Container Registry to Artifact Registry?<\/strong><br\/>\nUse Google\u2019s official migration guidance to copy images and update references in CI\/CD and manifests. Validate IAM and runtime pull permissions carefully. Start here: https:\/\/cloud.google.com\/artifact-registry\/docs<\/p>\n\n\n\n<p>16) <strong>Does Artifact Registry support CMEK?<\/strong><br\/>\nCMEK support exists for many Google Cloud storage-backed services, and Artifact Registry can support CMEK in some configurations. Verify current support, regions, and setup steps in official docs before committing to CMEK.<\/p>\n\n\n\n<p>17) <strong>Can I share a repository across projects?<\/strong><br\/>\nYes, by granting IAM permissions to principals (service accounts) from other projects at the repository level. Be explicit about who can pull\/push, and consider organization-level governance.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Artifact Registry<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Artifact Registry docs \u2013 https:\/\/cloud.google.com\/artifact-registry\/docs<\/td>\n<td>Canonical reference for formats, repository types, IAM, and workflows<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Artifact Registry pricing \u2013 https:\/\/cloud.google.com\/artifact-registry\/pricing<\/td>\n<td>Current, location-dependent pricing model and billable dimensions<\/td>\n<\/tr>\n<tr>\n<td>Pricing tool<\/td>\n<td>Google Cloud Pricing Calculator \u2013 https:\/\/cloud.google.com\/products\/calculator<\/td>\n<td>Build realistic estimates based on storage and egress assumptions<\/td>\n<\/tr>\n<tr>\n<td>Quickstarts<\/td>\n<td>Artifact Registry quickstarts (format-specific) \u2013 https:\/\/cloud.google.com\/artifact-registry\/docs<\/td>\n<td>Step-by-step guides for Docker, Maven, npm, Python, etc.<\/td>\n<\/tr>\n<tr>\n<td>Migration guidance<\/td>\n<td>Container Registry \u2192 Artifact Registry migration (verify guide link within docs) \u2013 https:\/\/cloud.google.com\/artifact-registry\/docs<\/td>\n<td>Helps update endpoints, copy images, and avoid downtime<\/td>\n<\/tr>\n<tr>\n<td>Cloud Build integration<\/td>\n<td>Cloud Build docs \u2013 https:\/\/cloud.google.com\/build\/docs<\/td>\n<td>CI pipelines that build and push to Artifact Registry<\/td>\n<\/tr>\n<tr>\n<td>Cloud Run integration<\/td>\n<td>Cloud Run docs \u2013 https:\/\/cloud.google.com\/run\/docs<\/td>\n<td>Deploying Artifact Registry images to serverless runtime<\/td>\n<\/tr>\n<tr>\n<td>Architecture patterns<\/td>\n<td>Google Cloud Architecture Center \u2013 https:\/\/cloud.google.com\/architecture<\/td>\n<td>Reference architectures for CI\/CD, security, and platform engineering<\/td>\n<\/tr>\n<tr>\n<td>Hands-on labs<\/td>\n<td>Google Cloud Skills Boost \u2013 https:\/\/www.cloudskillsboost.google\/<\/td>\n<td>Guided labs often include Artifact Registry + Cloud Build\/Run<\/td>\n<\/tr>\n<tr>\n<td>Official videos<\/td>\n<td>Google Cloud Tech (YouTube) \u2013 https:\/\/www.youtube.com\/@googlecloudtech<\/td>\n<td>Product walkthroughs and best practices (search within channel for Artifact Registry)<\/td>\n<\/tr>\n<tr>\n<td>Official samples<\/td>\n<td>GoogleCloudPlatform Cloud Build samples \u2013 https:\/\/github.com\/GoogleCloudPlatform\/cloud-build-samples<\/td>\n<td>Practical build configs that often publish images to registries<\/td>\n<\/tr>\n<tr>\n<td>Community learning<\/td>\n<td>Stack Overflow (tag: google-artifact-registry) \u2013 https:\/\/stackoverflow.com\/questions\/tagged\/google-artifact-registry<\/td>\n<td>Real troubleshooting patterns; validate answers against official docs<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<p>The following institutes are listed as training resources. Verify course outlines, delivery modes, and recency directly on their websites.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>DevOpsSchool.com<\/strong><br\/>\n   &#8211; <strong>Suitable audience:<\/strong> DevOps engineers, SREs, platform teams, developers<br\/>\n   &#8211; <strong>Likely learning focus:<\/strong> CI\/CD, containers, Google Cloud DevOps toolchains, artifact management basics<br\/>\n   &#8211; <strong>Mode:<\/strong> Check website<br\/>\n   &#8211; <strong>Website URL:<\/strong> https:\/\/www.devopsschool.com\/<\/p>\n<\/li>\n<li>\n<p><strong>ScmGalaxy.com<\/strong><br\/>\n   &#8211; <strong>Suitable audience:<\/strong> SCM\/DevOps practitioners, build\/release engineers<br\/>\n   &#8211; <strong>Likely learning focus:<\/strong> Source control, CI\/CD practices, release pipelines, DevOps foundations<br\/>\n   &#8211; <strong>Mode:<\/strong> Check website<br\/>\n   &#8211; <strong>Website URL:<\/strong> https:\/\/www.scmgalaxy.com\/<\/p>\n<\/li>\n<li>\n<p><strong>CLoudOpsNow.in<\/strong><br\/>\n   &#8211; <strong>Suitable audience:<\/strong> Cloud operations and DevOps teams<br\/>\n   &#8211; <strong>Likely learning focus:<\/strong> Cloud operations, automation, CI\/CD, container workflows<br\/>\n   &#8211; <strong>Mode:<\/strong> Check website<br\/>\n   &#8211; <strong>Website URL:<\/strong> https:\/\/cloudopsnow.in\/<\/p>\n<\/li>\n<li>\n<p><strong>SreSchool.com<\/strong><br\/>\n   &#8211; <strong>Suitable audience:<\/strong> SREs, operations engineers, reliability-focused platform teams<br\/>\n   &#8211; <strong>Likely learning focus:<\/strong> SRE practices, observability, incident response, reliability patterns<br\/>\n   &#8211; <strong>Mode:<\/strong> Check website<br\/>\n   &#8211; <strong>Website URL:<\/strong> https:\/\/www.sreschool.com\/<\/p>\n<\/li>\n<li>\n<p><strong>AiOpsSchool.com<\/strong><br\/>\n   &#8211; <strong>Suitable audience:<\/strong> Operations teams adopting AIOps tooling and automation<br\/>\n   &#8211; <strong>Likely learning focus:<\/strong> Monitoring automation, AIOps concepts, operational analytics<br\/>\n   &#8211; <strong>Mode:<\/strong> Check website<br\/>\n   &#8211; <strong>Website URL:<\/strong> https:\/\/www.aiopsschool.com\/<\/p>\n<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<p>These are listed as training resources\/platforms. Verify instructor profiles and offerings directly on the sites.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>RajeshKumar.xyz<\/strong><br\/>\n   &#8211; <strong>Likely specialization:<\/strong> DevOps\/Cloud guidance and training content (verify current offerings)<br\/>\n   &#8211; <strong>Suitable audience:<\/strong> Engineers seeking hands-on DevOps\/cloud coaching<br\/>\n   &#8211; <strong>Website URL:<\/strong> https:\/\/rajeshkumar.xyz\/<\/p>\n<\/li>\n<li>\n<p><strong>devopstrainer.in<\/strong><br\/>\n   &#8211; <strong>Likely specialization:<\/strong> DevOps tools, CI\/CD, containers, cloud fundamentals<br\/>\n   &#8211; <strong>Suitable audience:<\/strong> Beginners to intermediate DevOps practitioners<br\/>\n   &#8211; <strong>Website URL:<\/strong> https:\/\/www.devopstrainer.in\/<\/p>\n<\/li>\n<li>\n<p><strong>devopsfreelancer.com<\/strong><br\/>\n   &#8211; <strong>Likely specialization:<\/strong> Freelance DevOps services and enablement (verify scope)<br\/>\n   &#8211; <strong>Suitable audience:<\/strong> Teams seeking short-term training\/support engagements<br\/>\n   &#8211; <strong>Website URL:<\/strong> https:\/\/www.devopsfreelancer.com\/<\/p>\n<\/li>\n<li>\n<p><strong>devopssupport.in<\/strong><br\/>\n   &#8211; <strong>Likely specialization:<\/strong> DevOps support\/training services (verify current scope)<br\/>\n   &#8211; <strong>Suitable audience:<\/strong> Teams needing operational support and practical troubleshooting help<br\/>\n   &#8211; <strong>Website URL:<\/strong> https:\/\/www.devopssupport.in\/<\/p>\n<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<p>The following companies are listed as consulting resources. Descriptions are general; verify service offerings, references, and scope directly with each provider.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>cotocus.com<\/strong><br\/>\n   &#8211; <strong>Likely service area:<\/strong> DevOps\/Cloud consulting, implementation support (verify exact services)<br\/>\n   &#8211; <strong>Where they may help:<\/strong> Setting up CI\/CD pipelines, container workflows, artifact governance<br\/>\n   &#8211; <strong>Consulting use case examples:<\/strong> <\/p>\n<ul>\n<li>Implement Artifact Registry + Cloud Build pipeline patterns  <\/li>\n<li>Define repository and IAM strategy for multiple teams  <\/li>\n<li>Migrate from Container Registry to Artifact Registry  <\/li>\n<li><strong>Website URL:<\/strong> https:\/\/cotocus.com\/<\/li>\n<\/ul>\n<\/li>\n<li>\n<p><strong>DevOpsSchool.com<\/strong><br\/>\n   &#8211; <strong>Likely service area:<\/strong> DevOps consulting and enablement (verify current offerings)<br\/>\n   &#8211; <strong>Where they may help:<\/strong> CI\/CD modernization, container platform setup, developer enablement<br\/>\n   &#8211; <strong>Consulting use case examples:<\/strong> <\/p>\n<ul>\n<li>Artifact Registry onboarding for platform teams  <\/li>\n<li>Security\/IAM hardening for registries and pipelines  <\/li>\n<li>Cost optimization and retention policy rollout  <\/li>\n<li><strong>Website URL:<\/strong> https:\/\/www.devopsschool.com\/<\/li>\n<\/ul>\n<\/li>\n<li>\n<p><strong>DEVOPSCONSULTING.IN<\/strong><br\/>\n   &#8211; <strong>Likely service area:<\/strong> DevOps consulting services (verify current offerings)<br\/>\n   &#8211; <strong>Where they may help:<\/strong> Release engineering, pipeline automation, operational readiness<br\/>\n   &#8211; <strong>Consulting use case examples:<\/strong> <\/p>\n<ul>\n<li>Standardize artifact naming\/versioning and promotion practices  <\/li>\n<li>Integrate external CI with Google Cloud via federation  <\/li>\n<li>Establish governance and audit logging patterns  <\/li>\n<li><strong>Website URL:<\/strong> https:\/\/devopsconsulting.in\/<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Artifact Registry<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Containers fundamentals<\/strong>: Dockerfiles, images vs containers, registries, tags vs digests<\/li>\n<li><strong>Google Cloud basics<\/strong>: projects, IAM, service accounts, regions<\/li>\n<li><strong>CI\/CD basics<\/strong>: pipelines, build artifacts, release promotion<\/li>\n<li><strong>Networking basics<\/strong>: egress\/ingress concepts, regional traffic, private access patterns<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Artifact Registry<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Build<\/strong> deep dive: build triggers, substitutions, build caching strategies<\/li>\n<li><strong>Cloud Deploy<\/strong>: progressive delivery, approvals, environment promotion<\/li>\n<li><strong>GKE<\/strong> operations: image pull permissions, Workload Identity, node security<\/li>\n<li><strong>Supply chain security<\/strong>:<\/li>\n<li>Vulnerability management workflows<\/li>\n<li>Attestations and policy enforcement (for example, Binary Authorization on GKE\u2014verify your target enforcement pattern)<\/li>\n<li>SBOM and provenance concepts (tooling varies; validate best practice for your stack)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use Artifact Registry<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>DevOps Engineer \/ Platform Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Cloud Engineer \/ Cloud Architect<\/li>\n<li>Build &amp; Release Engineer<\/li>\n<li>Application Developer (especially container-based development)<\/li>\n<li>Security Engineer focused on software supply chain<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (Google Cloud)<\/h3>\n\n\n\n<p>Google Cloud certifications change over time; verify the current catalog. Artifact Registry knowledge is commonly relevant to:\n&#8211; Professional Cloud DevOps Engineer\n&#8211; Professional Cloud Architect\n&#8211; Associate Cloud Engineer<\/p>\n\n\n\n<p>Certification overview: https:\/\/cloud.google.com\/learn\/certification<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a multi-service app and push images to Artifact Registry with Cloud Build; deploy to Cloud Run.<\/li>\n<li>Create dev\/staging\/prod repos with least privilege IAM; implement promotion by digest.<\/li>\n<li>Set up external CI (GitHub Actions) using Workload Identity Federation to push images securely.<\/li>\n<li>Implement retention policies; measure storage growth and optimize image sizes.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Artifact<\/strong>: A build output stored for distribution (container image, package, OS package).<\/li>\n<li><strong>Repository (Artifact Registry)<\/strong>: A named storage location in a specific Google Cloud location for a specific artifact format.<\/li>\n<li><strong>Package<\/strong>: A logical artifact name inside a repository (for example, an image name).<\/li>\n<li><strong>Version<\/strong>: A specific build\/release of a package.<\/li>\n<li><strong>Docker image<\/strong>: A packaged filesystem and metadata used to run containers.<\/li>\n<li><strong>OCI<\/strong>: Open Container Initiative specifications for images and registries; many \u201cDocker registry\u201d workflows are OCI-compatible.<\/li>\n<li><strong>Tag<\/strong>: A human-friendly label pointing to an image digest (mutable unless controlled).<\/li>\n<li><strong>Digest<\/strong>: A content-addressed immutable identifier for an image (for example, <code>sha256:...<\/code>).<\/li>\n<li><strong>IAM<\/strong>: Identity and Access Management; Google Cloud\u2019s authorization system.<\/li>\n<li><strong>Service account<\/strong>: A non-human identity used by workloads and automation.<\/li>\n<li><strong>Workload Identity Federation<\/strong>: A way to exchange external identity (GitHub\/OIDC, etc.) for short-lived Google credentials without service account keys.<\/li>\n<li><strong>CMEK<\/strong>: Customer-Managed Encryption Keys using Cloud KMS.<\/li>\n<li><strong>VPC Service Controls (VPC-SC)<\/strong>: Service perimeters to reduce data exfiltration risk from Google-managed services.<\/li>\n<li><strong>Cloud Build<\/strong>: Google Cloud CI service for builds and pipeline steps.<\/li>\n<li><strong>Cloud Run<\/strong>: Serverless container runtime that pulls images from registries like Artifact Registry.<\/li>\n<li><strong>Artifact Analysis \/ Container Analysis<\/strong>: Google Cloud services\/APIs for vulnerability and metadata analysis of container images (and related supply-chain metadata).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Artifact Registry is Google Cloud\u2019s managed service for storing and distributing application artifacts\u2014especially container images and common language packages\u2014making it a foundational building block for modern <strong>Application development<\/strong> on Google Cloud.<\/p>\n\n\n\n<p>It matters because it gives teams a secure, IAM-governed, auditable, location-aware artifact store that integrates directly with Cloud Build and deployment targets like Cloud Run and GKE. Cost is primarily driven by storage, network egress, and (where used) scanning\/metadata features\u2014so location strategy, cleanup policies, and image size discipline are key. Security is largely about least-privilege IAM, avoiding long-lived credentials, and using digests plus policy controls for production integrity.<\/p>\n\n\n\n<p>Use Artifact Registry when you want a Google Cloud-native artifact hub with minimal operational overhead and strong integration with CI\/CD and runtime services. Next steps: deepen your skills with Cloud Build pipelines, adopt digest-based promotions, and explore supply-chain controls (scanning, attestations, and enforcement) appropriate to your organization\u2019s risk posture.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Application development<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[54,51],"tags":[],"class_list":["post-590","post","type-post","status-publish","format-standard","hentry","category-application-development","category-google-cloud"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/590","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=590"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/590\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=590"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=590"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=590"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}