Your enterprise is establishing an artifact management architecture across Google Cloud CI/CD pipelines for Maven and npm workloads. The architecture must satisfy several key requirements: Internal Artifact Storage: Proprietary libraries built by internal teams must be securely published and stored. Public Dependency Caching: Builds must pull open-source dependencies (such as Maven Central and npmjs) through a local cache to reduce latency, decrease external data transfer costs, and maintain build availability during upstream outages. Supply Chain Security: The architecture must protect developers and CI/CD pipelines from dependency confusion attacks where malicious public packages mimic internal package names. Simplified Client Configuration: Client build tools (pom.xml / settings.xml and .npmrc) must query a single endpoint per format rather than managing multiple repository endpoints. Which Artifact Registry repository architecture should you establish?

Establish standard repositories for proprietary packages, remote repositories configured as pull-through proxies for public upstreams, and virtual repositories that group the standard and remote repositories behind a single endpoint with higher priority assigned to the standard repositories.: ### What the Solution Is This architecture establishes a multi-tiered repository design using three native **Artifact Registry** repository modes: * **Standard repositories**: Store and manage proprietary, internally built packages (such as internal Maven libraries and private npm modules). * **Remote repositories**: Act as regional pull-through caching proxies for public upstream sources like Maven Central and npmjs. * **Virtual repositories**: Consolidate multiple upstream repositories (both standard and remote) behind a single, unified repository URL while enforcing search priority order. ### How It Meets the Requirements * **Internal Artifact Storage**: Proprietary artifacts are published directly to private **standard repositories**, retaining full IAM access control and vulnerability scanning. * **Public Dependency Caching**: Upstream public dependencies are retrieved and cached in regional **remote repositories** upon initial request. Subsequent build requests serve the cached copy locally within Google Cloud, drastically reducing latency, cutting external egress costs, and insulating pipelines against external registry downtime. * **Supply Chain Security**: By aggregating standard and remote repositories inside a **virtual repository** and assigning higher search priority to the internal standard repositories, Artifact Registry guarantees that private packages take precedence over public packages with matching names, mitigating **dependency confusion attacks**. * **Simplified Client Configuration**: Developers and CI/CD tools point their package managers (`npm`, `mvn`, `gradle`) to the single **virtual repository** endpoint, eliminating the need to configure multiple mirrors or dual registry paths in local client configurations. ### Key Advantages * **Deterministic Dependency Resolution**: Enforces centralized, server-side prioritization of private libraries over public mirrors. * **Network & Cost Efficiency**: Reduces cross-WAN data transfer by keeping dependencies in the same region as **Cloud Build** or **GKE** clusters. * **Operational Resilience**: Caches public artifacts so builds do not break during third-party repository disruptions. * **Centralized Governance**: Allows security administrators to audit and apply IAM policies from a single point of entry. ### Why This Is Optimal Using native **virtual** and **remote** repository modes in Artifact Registry removes the operational burden of managing external repository managers or writing custom synchronization scripts. It directly satisfies dependency resolution priority, caching, and single-endpoint access natively within Google Cloud.

Artifact Registry Virtual Remote Repositories Dependency | Professional Cloud DevOps Engineer

Artifact Registry Virtual Remote Repositories Dependency

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

Your enterprise is establishing an artifact management architecture across Google Cloud CI/CD pipelines for Maven and npm workloads. The architecture must satisfy several key requirements:

Internal Artifact Storage: Proprietary libraries built by internal teams must be securely published and stored.
Public Dependency Caching: Builds must pull open-source dependencies (such as Maven Central and npmjs) through a local cache to reduce latency, decrease external data transfer costs, and maintain build availability during upstream outages.
Supply Chain Security: The architecture must protect developers and CI/CD pipelines from dependency confusion attacks where malicious public packages mimic internal package names.
Simplified Client Configuration: Client build tools (pom.xml / settings.xml and .npmrc) must query a single endpoint per format rather than managing multiple repository endpoints.

Which Artifact Registry repository architecture should you establish?

Establish remote repositories for internal packages and standard repositories for public dependencies, using Cloud Build triggers to mirror external packages into the standard repositories on a scheduled cron schedule.

Establish standard repositories for proprietary packages, remote repositories configured as pull-through proxies for public upstreams, and virtual repositories that group the standard and remote repositories behind a single endpoint with higher priority assigned to the standard repositories.

Establish standard repositories for internal packages and configure developer clients and CI/CD build configs to query both the standard repository and public registries directly by declaring multiple registries in client configuration files.

Establish standard repositories with gcr.io domain support for both container and package formats, relying on Binary Authorization policies to validate package hashes during CI/CD build execution.

Professional Cloud DevOps Engineer

Artifact Registry Virtual Remote Repositories Dependency

Related questions