Prepare and test your skills
Prepare and test your skills
A model version alias in Model Registry (opens in a new tab) is a mutable, named reference that points to one specific version inside a single model resource. The name stays stable, such as staging or production, while the version it points to can change over time. Applications fetch or deploy the model by alias name instead of by version ID, so promotion does not require changing application code.
A model version alias is a unique reference that resolves to the current version ID when a user fetches or deploys the model. Model Registry looks up the alias name and returns the version it currently points to, so the caller never needs to know the exact version number. Aliases work like Docker tags or Git branch references, where the name remains the same while the underlying version moves forward.
The default alias is the alias that Model Registry uses when a request does not specify a model version. Model Registry automatically assigns the default alias to the first version when a new model is created, and exactly one version of each model must carry the default alias at all times. In the Google Cloud console, the Alias column shows which version holds the default tag, which helps stakeholders see which version is the stable version ready for deployment.
A version can be made the default through an ordered console workflow:
Custom aliases are user-created aliases in Model Registry that label a version for its place in the release lifecycle. A team can create names such as staging and production and assign each name to the version currently in that stage. Because deployment tools and application code refer to the alias name, the same reference continues to work even after the underlying version changes.
Custom aliases are added from the model details page by selecting a version, choosing Edit alias, adding a new alias name, and saving the change. Once assigned, the alias marker is visible in the console, so reviewers can track which version is in testing and which version is serving live traffic without opening each version.
Moving an alias in Model Registry is how a team promotes a model from one lifecycle stage to the next. The promotion flow moves forward from the alias to the version to the deployment: first the team validates a newer version, then the team reassigns the alias such as production to that newer version, and only after that do alias-based fetch and deploy calls resolve to the new version. Applying an existing alias to a new version automatically removes that alias from the old version, so only one version carries the name at a time.
Exam tip: An alias can point to only one version of a model at a time, so reusing an alias moves it and removes it from the previous version.
Alias names in Model Registry follow strict format and uniqueness rules that keep them distinct from version IDs. Version aliases must be unique by model, must be non-numerical, and must match the pattern [a-z][a-z0-9-]{0,126}[a-z0-9]. If production calls do not specify a version, Model Registry uses the version with the default alias.
Some considerations for using aliases in Model Registry include:
Model metadata management is the practice of storing organized information about machine learning models so teams can find, compare, reproduce, and govern them. In Google Cloud, the Gemini Enterprise Agent Platform Model Registry (Model Registry) acts as the central place for this metadata. The Model Registry (opens in a new tab) keeps an overview of models and their versions alongside details, evaluation results, and deployment history, so BigQuery ML (opens in a new tab) models and other ML models can be managed together.
The Model Registry provides an overview of models so teams can better organize, track, and train new versions. Each registered model keeps metadata about its specific versions, including details that describe what the version is and how it was created. From the Model Registry, that metadata supports lifecycle actions that move a model from development to use.
The Model Registry connects stored metadata to downstream actions:
Complete metadata makes this lifecycle reliable because the same version details, evaluation results, and deployment record can be reviewed later. That record supports reproducibility by showing which version produced which result, and it supports compliance by providing a clear history of what was evaluated and deployed.
BigQuery ML is a Google Cloud service that lets teams create and execute machine learning models in BigQuery by using standard SQL queries. Registration is the flow that copies the model's reference and metadata from BigQuery into the Model Registry, where the model can then be versioned, evaluated, and deployed alongside other models. Data flows from the BigQuery ML model to the Model Registry entry, and the Model Registry then manages the downstream actions.
Registration follows an ordered flow from creation to management:
Registration limits in the Model Registry control which BigQuery ML models can be stored as metadata and which stored models can move to deployment. Remote models sit outside this flow because they cannot be registered at all. Imported XGBoost models, ARIMA_PLUS models, and ARIMA_PLUS_XREG models can be registered for tracking, but they cannot be deployed in Agent Platform.
| Model type | Can register in Model Registry | Can deploy in Agent Platform |
|---|---|---|
| Standard BigQuery ML models | Yes | Yes, after registration to an endpoint for online inference |
| Remote models | No | No |
Imported XGBoost, ARIMA_PLUS, and ARIMA_PLUS_XREG models | Yes | No |
Exam tip: Remote models cannot be registered, while imported XGBoost, ARIMA_PLUS, and ARIMA_PLUS_XREG models can be registered but cannot be deployed.
The Gemini Enterprise Agent Platform Model Registry (Model Registry) is the central place that organizes machine learning models and their versions for promotion and reuse. A single registered model can hold multiple model versions, each with its own version ID, files, and evaluation results. One version carries the default alias, which is the version used when no specific version is requested, and this structure lets teams retrieve a known version, copy it, or delete old versions without losing the whole history.
Model versions in the Model Registry (opens in a new tab) are separate, retrievable snapshots under one parent model resource. Each version keeps its own artifacts, metadata, and evaluations, while the parent model provides a stable name for discovery. Keeping versions separate makes promotion safe because testing, deployment, and rollback can point to an explicit version ID instead of overwriting files.
The default version is copied when a copy request does not include a specific VERSION_ID in the source path projects/PROJECT_ID/locations/SOURCE_LOCATION/models/MODEL_ID[@VERSION_ID]. When a model is first copied to a new region, it is assigned the default alias in that region. This rule ensures that tools that omit the version still resolve to a predictable version.
Copying models moves a chosen version from a source location to a destination project or region, where it appears as a new model or as a new version of an existing model. Data flows from the source model resource to the destination Model Registry, and the copy operation preserves the link between the new copy and its source version. In the console, the workflow follows an ordered sequence:
us-central1.The choice of target type controls how the destination registry grows:
| Copy option | Destination target | Result in destination |
|---|---|---|
| Copy as new model | New model name or ID in the target region | Creates a separate model entry with its own version history |
| Copy as new version | Existing model in the target region | Adds the copied files as a new version under that existing model |
Choose Copy as new model when the team needs an independent entry for a different use case or region, and choose Copy as new version when the goal is to keep related iterations together for comparison and promotion.
Agent Platform ML Metadata (opens in a new tab) records the parameters, artifacts, and metrics of machine learning work so versions can be compared, rerun, and audited. The system stores metadata as a graph where artifacts and executions are nodes, events are edges that link artifacts as inputs or outputs of executions, and contexts are subgraphs that group related artifacts and executions. Teams attach key-value metadata to artifacts, executions, and contexts, such as the training framework and performance metrics like accuracy, precision, and recall.
A model version's lineage includes all factors that created it and all artifacts that descend from it:
Because lineage connects datasets, runs, versions, and deployments, teams can answer which dataset trained a model, which models used a dataset, which run and hyperparameters produced the most accurate model, where a model was deployed and when, and which version made a prediction at a given time. This connected record supports production analysis, hyperparameter comparison, exact reruns, and governance of downstream use.
Deleting models and versions in the Model Registry (opens in a new tab) enforces lifecycle dependencies that protect running systems. A model that is deployed to an endpoint must first be undeployed from that endpoint before the Model Registry will allow deletion. A BigQuery ML model registered in the Model Registry must first be deleted from BigQuery ML, and deleting a parent model deletes all of its associated model versions and evaluations from the project.
To remove only one iteration, expand the model, select that version, and delete the version while leaving the other versions intact. A model monitor (opens in a new tab) depends on one fixed model version and cannot be switched to a different version after creation. To watch a new version, create a new model monitor instead of editing the old one.
Exam tip: A monitor stays tied to its original model version, and deleting a parent model removes all of its versions and evaluations, so undeploy first and create a new monitor for a new version.
A model version alias in Model Registry is a mutable, named reference that points to one specific version inside a single model resource, and moving the alias promotes a model because alias-based fetch and deploy calls resolve to the new version after reassignment. Applying an existing alias such as production to a newer version automatically removes that alias from the old version, so only one version carries the name at a time and applications can continue to refer to the stable alias name instead of changing version IDs.
The default alias is the alias that Model Registry uses when a request does not specify a model version, and exactly one version of each model must carry the default alias at all times. Model Registry automatically assigns the default alias to the first version when a new model is created, and a different version is made the default by opening the model on the Model Registry page, opening the Actions menu for the chosen version, and selecting Set as default.
Standard BigQuery ML models can be registered in Model Registry and then deployed in Agent Platform to an endpoint for online inference, while remote models cannot be registered at all. Imported XGBoost, ARIMA_PLUS and ARIMA_PLUS_XREG models can be registered for tracking but cannot be deployed in Agent Platform.
A model monitor in Model Registry cannot be switched to a different version after creation because it depends on one fixed model version. To watch a new version, a new model monitor must be created instead of editing the old one.
A data team is developing machine learning models in Google Cloud. To satisfy strict governance and regulatory compliance standards, the team must ensure complete reproducibility and auditability. They need a centralized approach to track model versions, record runtime parameters and evaluation metrics, and capture the end-to-end provenance linking training datasets, execution steps, and resulting model assets.
Which Google Cloud approach best satisfies these model metadata management and governance requirements?
Last updated