Intermediate CI/CD test (Intermediate)

Sample questions

5 sample questions from the Intermediate CI/CD test, with the answers. Samples are taken out of the live test, so you will not meet these when you sit it.

1. Which deployment strategy involves deploying to an idle environment and switching traffic all at once after testing?

   1. Rolling update
   2. Canary deployment
   3. Blue-green deployment
   4. Feature flags

   Answer: C. Blue-green deployment

   Blue-green deployment is a strategy where two identical environments are used, and traffic is switched all at once after deployment and testing. Canary deployment, on the other hand, gradually routes a small percentage of traffic to the new version. Rolling update replaces instances gradually, and feature flags allow deploying without releasing immediately.

2. Which of the following statements accurately describes blue-green deployment?

   1. Blue-green deployment allows for zero-downtime deployment by gradually shifting traffic to the new version.
   2. Blue-green deployment minimizes downtime by maintaining two identical production environments.
   3. Blue-green deployment is primarily used for managing dependencies in a CI/CD pipeline.
   4. Blue-green deployment is a deployment strategy that involves rolling back changes if they fail.

   Answer: B. Blue-green deployment minimizes downtime by maintaining two identical production environments.

   Blue-green deployment is a strategy that minimizes downtime during deployment by maintaining two identical production environments. One environment (the 'blue' environment) is active and serving traffic, while the other (the 'green' environment) is used for deployment and testing. Once the deployment is complete and verified, traffic is switched to the 'green' environment. This approach ensures that there is no downtime and allows for quick rollbacks if needed. The other options are either incorrect or describe different deployment strategies.

3. How can a GitLab CI/CD pipeline be scheduled to run at specific times, such as daily or weekly, in a realistic project scenario?

   1. Using the `trigger` keyword in the `.gitlab-ci.yml` file
   2. Using the `schedule` keyword in the `.gitlab-ci.yml` file
   3. Using a cron job on the GitLab server
   4. Defining a custom event in the GitLab UI

   Answer: B. Using the `schedule` keyword in the `.gitlab-ci.yml` file

   In GitLab CI/CD, pipeline scheduling is achieved by using the `schedule` keyword in the `.gitlab-ci.yml` file. This allows pipelines to be triggered at specific intervals, such as daily or weekly. The other options are either unrelated to scheduling or incorrect methods of implementing it.

4. In a GitLab CI/CD pipeline, you are tasked with caching dependencies for a project that frequently updates its dependencies. Which approach should you take to ensure that the cache is correctly restored for each job?

   1. Use a static cache key for all jobs to speed up the process.
   2. Use the cache key based on the Git commit hash and dependency versions to ensure consistent restores.
   3. Store the cache in a shared network drive accessible to all runners.
   4. Ignore the cache key and always rebuild dependencies from scratch.

   Answer: B. Use the cache key based on the Git commit hash and dependency versions to ensure consistent restores.

   To effectively cache dependencies in GitLab CI/CD, you should use a cache key that includes the Git commit hash and dependency versions. This ensures that the cache is only restored when the dependencies and code are the same, preventing inconsistencies. Other options may lead to cache misses or incorrect restores, which can negatively impact build performance and reliability.

5. Which CI/CD platform uses a `.gitlab-ci.yml` file at the repo root for pipeline configuration?

   1. GitLab CI/CD
   2. Jenkins
   3. Azure Pipelines
   4. GitHub Actions

   Answer: A. GitLab CI/CD

   GitLab CI/CD uses a `.gitlab-ci.yml` file at the repo root for configuration. This is different from Jenkins, which uses a `Jenkinsfile`, and GitHub Actions, which uses YAML files in `.github/workflows/`.