A Quick Map of the Tooling Landscape

Everything in this course so far has deliberately avoided leading with tools, because tools are implementations of ideas, and understanding the idea first is what lets you evaluate any tool — including ones invented after this course was written. This final module closes the loop the other direction: for each category of tool you'll hear about constantly in a DevOps/DevSecOps context, what mindset-level problem is it actually solving, and what are a few names you'll recognize. One short paragraph each — deliberately not a tutorial.

CI/CD — Continuous Integration / Continuous Delivery

This category automates Module 4's feedback loop and Module 1's small-batch philosophy: every time code changes, it's automatically built, tested, and (for CD) deployed, instead of a human manually running those steps. "Continuous Integration" means changes are merged and tested frequently, in small batches. "Continuous Delivery/Deployment" extends that to automatically getting a passing change into production (or ready to be, with one click). Examples you'll encounter: GitHub Actions and GitLab CI (built into their respective platforms), Jenkins (an older, highly customizable, self-hosted option), and CircleCI.

Infrastructure as Code

This is the tooling behind Module 8's "cattle, not pets" mindset: describing servers, networks, and cloud resources as code instead of manual configuration. Terraform (by HashiCorp) is the most widely used, cloud-provider-agnostic option. Ansible focuses more on configuration management (setting up software on existing servers) and is popular for its simple, agentless design. CloudFormation and Pulumi are other common choices — CloudFormation being AWS-specific, Pulumi notable for letting you write infrastructure definitions in general-purpose programming languages instead of a dedicated config language.

Containers & Orchestration

Containers solve a specific piece of Module 8's reproducibility problem: packaging an application together with everything it needs to run (dependencies, runtime, configuration) into one portable unit, so it behaves identically on a developer's laptop and in production — directly attacking "it works on my machine." Docker is the tool most associated with popularizing this approach. Once you have many containers running across many machines, you need something to schedule, scale, and heal them automatically — that's orchestration, and Kubernetes (often abbreviated K8s) is the dominant tool in this space, handling things like restarting a crashed container or spreading load across machines.

Observability — Logging, Metrics, Tracing

This is the sensor layer Module 4 described as making the organizational feedback loop possible at all. Logging tools capture discrete events ("user X failed to log in at time Y"); metrics tools track numeric trends over time (response times, error rates, CPU usage); tracing tools follow a single request as it moves through multiple services, useful for finding exactly where in a complex system something went wrong. Common names: Prometheus and Grafana (metrics collection and dashboards, often used together), the ELK/Elastic stack and Datadog (logging and broader observability platforms), and OpenTelemetry (an increasingly standard way of generating the underlying data these tools consume).

Secrets Management

Passwords, API keys, and certificates ("secrets") can't simply live in the same code repository as everything else — Module 8's version-controlled transparency, which is a strength for infrastructure code, becomes a serious liability if it means anyone with repo access can read production credentials. Secrets management tools store these values securely and hand them out to applications and pipelines only when needed, with an audit trail of who accessed what. HashiCorp Vault is a well-known standalone option; most major cloud providers also offer a built-in equivalent (AWS Secrets Manager, and similar services from other clouds).

SAST, DAST, and SCA — the DevSecOps toolset

These three acronyms are the automated backbone of Module 9's "shift everywhere" security approach, each catching a different category of problem. SAST (Static Application Security Testing) scans your source code itself for known-dangerous patterns, without running it — catching issues early, often right in the IDE or a pull request. DAST (Dynamic Application Security Testing) tests a running version of the application from the outside, the way an attacker actually would, catching a different class of issues that only show up at runtime. SCA (Software Composition Analysis) scans your third-party dependencies for known vulnerabilities — this is exactly the category of tool that, used continuously rather than periodically, would have surfaced the unpatched Apache Struts flaw in the Equifax case study before attackers did. Examples: Snyk and Dependabot are widely used for SCA (dependency scanning); SonarQube is a common SAST tool; OWASP ZAP is a well-known open-source DAST tool.