LPI DevOps Tools Engineer: Software Engineering

What this domain tests

Software Engineering on the LPI DevOps Tools Engineer exam covers how source code becomes a tested, versioned artifact: Git history and branching, code review, automated tests in a CI pipeline, and reproducible builds.

Core rules

• Commit small and often; a commit should be one logical change that builds and passes tests on its own.
• Choose a branching model deliberately. Trunk-based development with short-lived branches and feature flags reduces merge pain; Git Flow suits versioned, infrequently released products but accumulates long-lived branches.
• Pin what you build with: lockfiles, fixed base image digests, and exact tool versions. A build that resolves dependencies at run time is not reproducible.
• Build once and promote the same artifact through stages. Rebuilding per environment lets staging differ from production.
• Tag releases with Semantic Versioning (MAJOR.MINOR.PATCH) and keep artifacts in a repository such as Nexus or Artifactory; avoid mutable tags like latest.
• Put fast unit tests first, then integration and end-to-end tests, matching the test pyramid.

Worked example

A pipeline fails at the integration-test stage while the same tests pass locally. The team used npm install instead of npm ci, so CI resolves newer minor versions; the lockfile is committed but ignored, and the CI image ships Node 16 while developers run Node 20. Reasoning: the divergence is environmental, not a code bug. Fix: use npm ci against the committed lockfile, pin the CI image to the same Node version, and run the suite inside the same container image used for builds. Re-run: green.

Traps

• Committing credentials or .env files; history keeps them even after deletion, so rotate the secret.
• Long-lived branches that drift, producing painful merges.
• Treating "tests pass locally" as evidence; reproducibility is the exam's theme.
• Using git push --force on shared branches instead of --force-with-lease.