Skip to content
tezvyn:

CI/CD & Automation

GitHub Actions, Terraform, ArgoCD, IaC, pipelines

309 bites

Test yourself: Top 30 CI/CD & Automation interview questionsMultiple choice, with the correct answer and why it is correct on every question. Free, no sign-in.

Everything in CI/CD & Automation, page 14

Package Lock Files: Ensuring Reproducible Builds
intermediate2 min read

Package Lock Files: Ensuring Reproducible Builds

A package lock file is a snapshot of your dependency tree, ensuring everyone on your team and your CI server installs the exact same package versions. It's crucial for preventing "works on my machine" bugs.

intermediate2 min read

Maven Coordinates (GAV): The Address of Your Code

Maven Coordinates (GAV) are like a postal address for a software library. You use them in a pom.xml to declare your project's identity and specify its dependencies.

Transitive Dependencies: The Hidden Baggage in Your Code
easy2 min read

Transitive Dependencies: The Hidden Baggage in Your Code

Think of transitive dependencies as your dependency's dependencies. You add one library, but it pulls in others you didn't explicitly ask for. This happens in any project using a package manager.

easy2 min read

Docker Registry: A Library for Your Images

A Docker Registry is like GitHub, but for Docker images. It's a centralized storage system where you push and pull images, enabling sharing and deployment. The biggest footgun is using the :latest tag, which can lead to unpredictable builds.

easy1 min read

Semantic Versioning: A Three-Part Numbering System

Semantic Versioning (SemVer) is a widely used convention for assigning software versions. It uses a three-part Major.Minor.Patch number to create unique identifiers for software states.

easy2 min read

Package Manifest: Your Project's List of Ingredients

A package manifest is your project's recipe, listing all dependencies and build scripts. Package managers use it to install the right libraries. The footgun is forgetting that the manifest (e.g., package.json) and the lockfile work together for consistency.

advanced2 min read

Test Data Management (TDM): Stop Flaky Tests

Test Data Management (TDM) treats test data like code: versioned, managed, and reliably provisioned to ensure consistent, meaningful tests. This is crucial in CI/CD pipelines where automated tests require repeatable data states.

advanced2 min read

DAST: Probing a Running App for Security Flaws

DAST acts like an automated pen-tester, attacking your running application from the outside to find flaws without seeing the code. It's used in CI/CD to catch common web vulnerabilities. The footgun: DAST can't see the code, so it misses business logic errors.

advanced2 min read

Mutation Testing: A Fire Drill for Your Test Suite

Mutation testing is a fire drill for your test suite. It deliberately injects small bugs ('mutants') into your code to see if your tests fail as expected. This ensures tests validate behavior, not just execute lines.

intermediate2 min read

Software Performance Testing: How a System Behaves Under Stress

Performance testing answers 'how does it work under load?' It simulates user traffic to measure a system's responsiveness, stability, and resource use. The footgun is testing unrealistic scenarios instead of finding real-world breaking points.

intermediate2 min read

Regression Testing: Don't Break What's Already Working

Regression testing asks: 'Did my new code break old features?' It's re-running existing tests after a change to catch unintended side effects. It's crucial in CI/CD pipelines before deploying. The footgun is a slow suite that developers skip.

intermediate2 min read

Quality Gates: Your Automated Code Quality Checklist

A quality gate is an automated checklist that asks, 'Is this code ready to release?' It runs in CI/CD to enforce standards on metrics like bugs and test coverage, blocking merges that fail. The footgun is using one gate for all projects; tailor rules to.

easy2 min read

Smoke Testing: Is This Build Even Worth Testing?

Smoke testing asks: 'Is this build so broken it's not even worth testing?' It's a quick, shallow check of critical functions, run on every new build before more exhaustive QA. The footgun is thinking a passed smoke test means the build is bug-free.

easy2 min read

Integration Testing: Do Your Components Play Well Together?

Integration testing verifies that different software modules, like an API and a database, work correctly together. It's used to catch bugs in the interactions between components, such as data format mismatches. The footgun is writing slow, brittle tests.

easy2 min read

Unit Testing: Verifying Code's Smallest Parts

Think of unit tests as checking each Lego brick for defects before building the castle. They confirm your smallest code pieces, like a single function, behave correctly in isolation.

Build Matrix: Test All The Combinations
advanced2 min read

Build Matrix: Test All The Combinations

A build matrix automatically creates multiple jobs by combining different configurations. Use it to test your code across various operating systems, language versions, or dependencies without duplicating your workflow file.

advanced2 min read

Cross-Compilation: Build Anywhere, Run Elsewhere

A cross-compiler builds code for a different machine than the one it runs on. This lets you use a powerful PC to compile for a tiny IoT device or a mobile phone. The footgun is forgetting that the target's OS and libraries matter, not just.

advanced2 min read

Reproducible Builds: Trust What You Run

A reproducible build guarantees that the same source code always compiles into the exact same binary. This is crucial for verifying that a distributed application wasn't tampered with.

advanced2 min read

Incremental Build: Develop and Ship Software in Pieces

Incremental builds deliver software in usable chunks, not one big release. This lets you ship value and gather feedback early on large projects. The footgun is poor planning, leading to disconnected features and architectural debt instead of a cohesive…

intermediate2 min read

Code Coverage: What Your Tests Don't Tell You

Code coverage measures which lines of code your tests execute, not how well they're tested. It's used in CI to enforce a testing baseline, but the footgun is mistaking high coverage for high quality—100% coverage can exist with zero useful assertions.

We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.

See open roles