Quiz: CI/CD

← Back to quiz index

15 questions

L1 (9 questions)

1. What are the typical stages in a CI/CD pipeline?

Show answer

1. Build (compile, install deps).
2. Test (unit, integration, lint).
3. Package (Docker image, artifact).
4. Deploy to staging.
5. Acceptance/smoke tests.
6. Deploy to production. Each stage gates the next — fail fast, fix early.

2. What is the difference between an artifact and a package in CI/CD?

Show answer

Artifact = any build output (binary, Docker image, test report, log file). Package = a versioned, distributable artifact (Docker image with tag, npm package, Helm chart). Packages go to registries; artifacts may be ephemeral. Always tag packages with the git SHA or semver.

3. What is the difference between continuous delivery and continuous deployment?

Show answer

Continuous delivery = every commit is deployable but requires manual approval for production. Continuous deployment = every commit that passes tests deploys to production automatically. Most teams start with delivery and graduate to deployment as confidence grows.

4. What are deployment safety patterns to prevent bad releases?

Show answer

1. Canary: route small % of traffic to new version first.
2. Blue-green: run old and new side by side, switch traffic.
3. Feature flags: deploy code disabled, enable incrementally.
4. Automated smoke tests post-deploy.
5. Auto-rollback on error rate spike.

5. What should you NOT store in your CI/CD pipeline config?

Show answer

Secrets (API keys, passwords, tokens). Use your CI platform's secret management (GitHub Actions secrets, GitLab CI variables marked protected/masked). Never echo secrets in logs. Rotate CI secrets on the same schedule as production secrets.

6. What is the difference between a build artifact and a container image in CI/CD?

Show answer

Build artifact: any output of the build step (JAR, binary, test report). Container image: a packaged artifact with its runtime environment, ready to deploy anywhere. The CI pipeline typically builds the artifact, packages it into an image, pushes to a registry, and deploys the image.

7. What is the purpose of a staging environment in CI/CD?

Show answer

Staging mirrors production as closely as possible (same infra, config, data shape). It validates that the build works in a production-like setting before deploying for real. Catches issues that unit tests miss: configuration errors, integration failures, performance regressions.

8. What is the expand-contract pattern for database changes in CI/CD?

Show answer

Expand: add new column/table alongside old (backward-compatible). Migrate: update app code to use new schema. Contract: remove old column/table after all code uses the new one. This allows safe rollback at every stage — the old schema and old code always work together.

9. What are GitHub Actions reusable workflows and why use them?

Show answer

Reusable workflows are called from other workflows using workflow_call trigger. They centralize common CI logic (build, test, deploy) in one place. Changes propagate automatically. Pin the calling reference to a tag/SHA for stability. Reduces duplication across repos in an organization.

L2 (6 questions)

1. How do you implement a safe rollback strategy in CI/CD?

Show answer

1. Keep previous artifacts/images available (don't delete old tags).
2. Use deployment strategies: blue-green or canary.
3. Automate rollback on health check failure.
4. Database migrations must be backwards-compatible (expand-contract pattern). Fast rollback = deploy the previous known-good artifact.

2. Why should CI pipelines be fast and what is a good target?

Show answer

Slow CI means slow feedback and context switching. Target: under 10 minutes for the core loop (build + unit tests + lint). Use parallelism, caching (dependencies, Docker layers), and split slow integration tests into a separate stage. Developers should get feedback before they move on.

3. How do you secure a CI/CD pipeline?

Show answer

1. Pin dependencies and action versions (not @latest).
2. Use least-privilege credentials scoped to the pipeline.
3. Never echo secrets in logs.
4. Run in ephemeral environments (no persistent build agents).
5. Sign artifacts and verify before deploy.
6. Review third-party actions/plugins for supply chain risk.
7. Enable branch protection and require reviews.

4. How do you implement trunk-based development with CI/CD?

Show answer

All developers commit to main/trunk frequently (daily+). Short-lived feature branches (< 2 days). Feature flags decouple deploy from release. CI runs on every commit to trunk. Deploy from trunk to production. Benefits: reduced merge conflicts, faster feedback, simpler release process.

5. A CI pipeline is flaky — tests pass sometimes and fail other times. How do you fix it?

Show answer

1. Identify flaky tests (re-run reports, test quarantine).
2. Common causes: timing/race conditions, shared state, network dependencies, order-dependent tests.
3. Fix: use mocks/stubs, isolate test state, add retries with backoff for network calls.
4. Never suppress flaky tests permanently — fix or delete them.

6. How do you implement infrastructure-as-code testing in CI/CD?

Show answer

1. Lint: terraform fmt, tflint, yamllint.
2. Static analysis: checkov, tfsec for security misconfigurations.
3. Unit tests: Terratest or pytest + localstack.
4. Plan: terraform plan in CI, require approval for apply.
5. Integration: spin up ephemeral infra, run smoke tests, tear down.
6. Drift detection: scheduled plan runs.