Artifact Registry creation in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Configuration

intermediate

Creating a Docker repository in Artifact Registry

You want to create a Docker repository named my-docker-repo in Artifact Registry within the us-central1 region. Which gcloud command correctly creates this repository?

A gcloud artifacts repositories create my-docker-repo --repository-format=docker --location=us-east1

B gcloud artifacts repositories create my-docker-repo --repository-format=maven --location=us-central1

C gcloud artifacts repositories create my-docker-repo --repository-format=docker --location=us-central1

D gcloud artifacts repositories create my-docker-repo --repository-format=container --location=us-central1

💡 Hint

Remember that Docker repositories use the 'docker' format and location must match your desired region.

The correct command uses '--repository-format=docker' and '--location=us-central1' to create a Docker repository in the specified region. Option C uses the wrong format 'maven'. Option C uses the wrong location 'us-east1'. Option C uses an invalid format 'container'.

❓ Architecture

intermediate

Choosing Artifact Registry location for multi-region access

Your team is distributed across multiple continents and needs fast access to container images stored in Artifact Registry. Which location type should you choose to optimize latency and availability?

A Choose a single-region location closest to your main office

B Choose a multi-region location that covers all your users

C Create multiple single-region repositories in each continent

D Use a regional location but replicate images manually

💡 Hint

Think about how Google Cloud manages multi-region locations for global access.

Multi-region locations provide automatic replication and low latency access across a wide area, making them ideal for distributed teams. Single-region locations limit access speed to that region. Creating multiple single-region repositories increases management complexity. Manual replication is error-prone and inefficient.

❓ security

advanced

Configuring IAM permissions for Artifact Registry access

You want to allow a service account to push and pull Docker images from an Artifact Registry repository named prod-repo. Which IAM role should you assign to the service account for the least privilege?

A roles/storage.objectAdmin

B roles/artifactregistry.admin

C roles/artifactregistry.reader

D roles/artifactregistry.writer

💡 Hint

Consider the difference between read, write, and admin roles.

The 'roles/artifactregistry.writer' role allows pushing and pulling images, which is the least privilege needed. 'roles/artifactregistry.admin' grants full control, which is more than needed. 'roles/artifactregistry.reader' only allows pulling images. 'roles/storage.objectAdmin' is unrelated to Artifact Registry permissions.

❓ service_behavior

advanced

Understanding Artifact Registry image versioning behavior

You push a Docker image tagged v1.0 to an Artifact Registry repository. Later, you push another image with the same tag v1.0 but different content. What happens to the stored images?

A The new image overwrites the old image with tag v1.0; only one image with that tag exists.

B Both images are stored separately with the same tag v1.0 pointing to the latest image.

C Artifact Registry rejects the second push because the tag v1.0 already exists.

D The old image is deleted and the new image is stored with a new unique tag.

💡 Hint

Think about how Docker tags work in registries.

Docker tags are mutable pointers to image digests. Pushing a new image with the same tag updates the tag to point to the new image, effectively overwriting the previous tag reference. The old image may still exist by digest but is no longer referenced by that tag. Artifact Registry allows tag updates and does not reject pushes with existing tags.

✅ Best Practice

expert

Implementing secure Artifact Registry access in CI/CD pipelines

You want to securely authenticate your CI/CD pipeline to push images to Artifact Registry without embedding long-lived credentials. Which approach follows best security practices?

A Use Workload Identity Federation to allow the pipeline to impersonate a service account without keys.

B Use a service account key file stored in the pipeline repository and authenticate with it.

C Store the service account password as a secret in the pipeline and use it for authentication.

D Use user credentials from a developer's account to authenticate the pipeline.

💡 Hint

Consider how to avoid long-lived keys and manual credential management.

Workload Identity Federation allows external identities (like those from CI/CD systems) to impersonate Google service accounts without needing to manage or store long-lived keys, improving security. Using key files or passwords stored in repositories or secrets increases risk. Using developer user credentials is insecure and not recommended.

Practice

1. What is the main purpose of creating an Artifact Registry in Google Cloud?

easy

A. To host virtual machines

B. To securely store and manage software packages

C. To monitor network traffic

D. To create databases

Solution

1. Step 1: Understand Artifact Registry purpose

   Artifact Registry is designed to store and manage software packages securely.

2. Step 2: Compare options with purpose

   Options B, C, and D relate to other services like Compute Engine, VPC, and Cloud SQL, not Artifact Registry.

3. Final Answer:

   To securely store and manage software packages -> Option B

4. Quick Check:

   Artifact Registry = Secure package storage [OK]

Hint: Artifact Registry = package storage, not VMs or databases [OK]

Common Mistakes:

• Confusing Artifact Registry with Compute Engine
• Thinking it manages databases
• Assuming it monitors network traffic

2. Which of the following is the correct command syntax to create an Artifact Registry repository with Docker format in region us-central1?

easy

A. gcloud artifacts repositories create my-repo --repository-format=docker --location=us-central1

B. gcloud artifacts create repository my-repo --format=docker --region=us-central1

C. gcloud create artifacts repository my-repo --format=docker --location=us-central1

D. gcloud artifacts repositories new my-repo --repository-format=docker --location=us-central1

Solution

1. Step 1: Recall correct gcloud command structure

   The correct command is 'gcloud artifacts repositories create' followed by repository name and flags '--repository-format' and '--location'.

2. Step 2: Match options with correct syntax

   gcloud artifacts repositories create my-repo --repository-format=docker --location=us-central1 matches the correct syntax exactly. Other options have wrong order or wrong flags.

3. Final Answer:

   gcloud artifacts repositories create my-repo --repository-format=docker --location=us-central1 -> Option A

4. Quick Check:

   Correct command syntax = gcloud artifacts repositories create my-repo --repository-format=docker --location=us-central1 [OK]

Hint: Use 'gcloud artifacts repositories create' with format and location [OK]

Common Mistakes:

• Using 'create' before 'artifacts repositories'
• Mixing up --region and --location flags
• Incorrect flag names like --format instead of --repository-format

3. What will be the result of running this command?

gcloud artifacts repositories create test-repo --repository-format=maven --location=us-east1

medium

A. Creates a Docker format repository ignoring the format flag

B. Fails because 'maven' is not a valid repository format

C. Creates a Maven format Artifact Registry repository in us-east1 region

D. Creates a repository but defaults location to global

Solution

1. Step 1: Check repository format validity

   'maven' is a valid repository format supported by Artifact Registry.

2. Step 2: Check location flag effect

   Specifying '--location=us-east1' sets the repository region correctly.

3. Final Answer:

   Creates a Maven format Artifact Registry repository in us-east1 region -> Option C

4. Quick Check:

   Valid format and location = Creates a Maven format Artifact Registry repository in us-east1 region [OK]

Hint: Supported formats include maven, docker, npm, etc. [OK]

Common Mistakes:

• Assuming 'maven' is invalid format
• Thinking location defaults to global if specified
• Believing format flag is ignored

4. You run this command but get an error:

gcloud artifacts repositories create my-repo --repository-format=pip --location=us-west1

What is the likely cause?

medium

A. Missing project flag in the command

B. The location 'us-west1' is invalid

C. Repository name 'my-repo' is invalid

D. The repository format 'pip' is not supported

Solution

1. Step 1: Verify supported repository formats

   Artifact Registry does not support 'pip' as a repository format; common formats are docker, maven, npm, etc.

2. Step 2: Check location and name validity

   'us-west1' is a valid location and 'my-repo' is a valid name; missing project flag usually defaults to current project.

3. Final Answer:

   The repository format 'pip' is not supported -> Option D

4. Quick Check:

   Unsupported format causes error = The repository format 'pip' is not supported [OK]

Hint: Check format spelling and support before creating repo [OK]

Common Mistakes:

• Assuming all language names are valid formats
• Ignoring error messages about format
• Thinking location or name is the problem

5. You want to create an Artifact Registry repository that supports both Docker and npm packages in the us-central1 region. What is the best approach?

hard

A. Create two separate repositories: one with format docker and one with format npm, both in us-central1

B. Create one repository with format docker,npm in us-central1

C. Create a repository with format docker and upload npm packages to it

D. Create a repository with format npm and upload docker images to it

Solution

1. Step 1: Understand repository format limitation

   Artifact Registry repositories support only one format each; you cannot mix formats in one repository.

2. Step 2: Plan repository creation accordingly

   To support both Docker and npm, create two repositories with respective formats in the same region.

3. Final Answer:

   Create two separate repositories: one with format docker and one with format npm, both in us-central1 -> Option A

4. Quick Check:

   One format per repo = Create two separate repositories: one with format docker and one with format npm, both in us-central1 [OK]

Hint: One repo = one format; use multiple repos for multiple formats [OK]

Common Mistakes:

• Trying to combine formats in one repository
• Uploading wrong package types to a repo
• Ignoring regional consistency