Welcome to the fifth and final lesson in our course on working with container registries. You've built a solid foundation in Google Artifact Registry fundamentals, created secure repositories, mastered the push-pull workflow, and successfully deployed container images. Now it's time to learn how to manage those images responsibly over time through vulnerability scanning and cleanup policies.

Vulnerability scanning automatically analyzes your images against databases of known vulnerabilities through the Container Analysis API, providing detailed security reports as new threats are discovered in container components. Cleanup policies provide automated rules that remove old, unused, or untagged images, preventing repositories from accumulating hundreds of versions that lead to unnecessary storage costs and operational complexity.

You'll achieve two key outcomes: viewing vulnerability scan findings using the gcloud artifacts docker images describe command for security analysis and creating automated cleanup rules using the gcloud artifacts repositories set-cleanup-policies command with configuration files.

Before diving into vulnerability scanning and cleanup policies, you need to ensure you have the proper foundation from previous lessons and understand the permissions required for these advanced Artifact Registry operations.

You should have an existing Artifact Registry repository with at least one container image — specifically, the my-web-app repository with a Docker image tagged as latest from lessons two and three. Additionally, you should have enabled the Container Analysis API at the project level in an earlier lesson, which automatically enables vulnerability scanning for all images pushed to any repository in your project. You can verify your repository exists by running the familiar command from previous lessons.

This command should return details about your repository, including the repository format, creation time, and configuration settings. You can also check which images exist in your repository using the list command.

For the advanced operations covered in this lesson, your Google Cloud credentials need appropriate IAM permissions beyond the basic push and pull permissions you used previously. The essential roles are:

• Vulnerability Scanning:

  • roles/artifactregistry.reader: Allows you to view repository contents and image metadata.
  • roles/containeranalysis.occurrences.viewer: Lets you retrieve and view vulnerability scan results from the Container Analysis API.

Google Artifact Registry provides automatic vulnerability scanning through the Container Analysis API, which you enabled at the project level in an earlier lesson. Vulnerability scanning is a project-wide setting — once enabled, the Container Analysis API automatically scans all images pushed to any repository in your project, analyzing each layer for known vulnerabilities and continuously updating results as new vulnerability databases become available. You do not configure scanning per-repository; it applies to all repositories in your project.

When you pushed your Docker image in lesson three, the Container Analysis API automatically began scanning it in the background. You can retrieve vulnerability count summaries for any image using the gcloud artifacts docker images describe command with the --show-package-vulnerability flag, which provides high-level vulnerability statistics.

The scan findings output provides vulnerability counts by severity level.

This summary view is ideal for quickly assessing the overall security posture of an image. Critical and High severity vulnerabilities represent the most serious security risks that should be addressed immediately. Medium findings represent moderate risks for regular maintenance cycles, while Low findings often indicate minor improvements that can be addressed as time permits.

For detailed information about each vulnerability — including CVE identifiers, affected packages, and specific remediation steps — use the separate gcloud artifacts docker images list-vulnerabilities command.

Cleanup policies in Google Artifact Registry are defined using structured JSON configuration that specifies rules for automatically deleting images. Each policy consists of one or more rules with an action and a condition that defines which images to target.

Here's a basic cleanup policy that deletes untagged images older than 7 days.

Policy components:

• action: What to do with matching images (DELETE or KEEP).
• condition: Defines criteria for rule application.
  • tagState: Can be TAGGED, UNTAGGED, or ANY.
  • olderThan: Age threshold in seconds (604800s = 7 days, 86400s = day, = days).

Apply your cleanup policy to a repository using the gcloud artifacts repositories set-cleanup-policies command.

The --policy flag reads policy content from your local file. On success, gcloud returns a confirmation message.

Verify the policy configuration by retrieving the repository details.

This command returns the complete repository configuration, including active cleanup policies.

Artifact Registry evaluates cleanup policies on a regular schedule (typically daily). Policy effects are not immediate — new policies take effect during the next scheduled evaluation cycle, providing a safety buffer against accidental deletion due to configuration errors.

Monitor policy effects by checking your repository's image list periodically.

Over time, you should see that images matching your policy criteria are automatically removed while protected images remain available.

Several common pitfalls can cause unexpected behavior when working with Artifact Registry. Following these best practices helps you implement scanning and cleanup policies safely and effectively in production environments.

• Avoid Accidental Deletion with Immutable Tags.
  Pushing a new latest tag untags the previous image, making it a target for cleanup. Use immutable tags (e.g., version numbers, Git SHAs) to protect important releases from accidental deletion.

• Test Policies in Non-Production Environments.
  Never apply a new policy directly to production, as an incorrect rule can cause irreversible data loss. Always test policies in a non-production environment first to verify their behavior.

• Understand Rule Evaluation Order.
  Rules are evaluated in order. KEEP actions are evaluated before DELETE actions, so place KEEP rules first in your policy file to protect important images from matching a later deletion rule.

• Verify IAM Permissions.
  Ensure you have the correct IAM roles: roles/artifactregistry.repoAdmin to manage cleanup policies and roles/containeranalysis.occurrences.viewer to view vulnerability scans.

• Act on Vulnerability Scan Findings.
  Scanning without action provides little security benefit. Regularly review findings, prioritize remediation based on severity, and integrate patching and rebuilding images into your development workflow.

• Monitor and Adjust Policies.
  Policies are not "set and forget." Regularly monitor storage costs and image counts to confirm policies are working as expected. Adjust rules and retention periods as needed.

By internalizing these practices, you shift from simply using Artifact Registry as a storage bucket to managing it as a critical component of your software supply chain. A thoughtful approach to tagging, testing, and remediation ensures your container registry remains secure, cost-effective, and operationally sound, preventing common issues before they can impact your production environment.

In this lesson, you mastered advanced Artifact Registry management for production environments. You learned to identify security risks by viewing automatic vulnerability scans with gcloud artifacts docker images describe and the Container Analysis API, and to control costs by creating automated cleanup rules with gcloud artifacts repositories set-cleanup-policies. These skills transform Artifact Registry from a simple image store into a secure, automated component of your software delivery pipeline.

In the upcoming practice, you'll apply these skills by analyzing scan results and creating custom cleanup policies. The commands and principles are directly transferable to your own projects, provided your local gcloud CLI is configured with the necessary IAM roles for repository administration and vulnerability analysis.