Continuous Delivery’s primary benefit is that it reduces the cost, time, and risk of delivering

incremental changes. By keeping software deployable at all times, teams can ship small, low-risk

releases as needed.

A: Prioritizing features over deployability increases risk.

B: Not all releases are deployed immediately; CD keeps them ready.

D: CD doesn’t automate everything—some manual steps may remain, especially in Continuous

Delivery (vs. Continuous Deployment).

Extract-style reference:

“Continuous Delivery reduces deployment pain by ensuring that code is always in a deployable state,

decreasing the cost, time, and risk associated with releases.”

— Continuous Delivery, Jez Humble & David Farley

PeopleCert Syllabus: Highlights CD as a strategy for safer, more efficient business change.

The State of DevOps Reports show that LOW performing organizations have higher change failure

rates, meaning a larger percentage of changes lead to incidents, outages, or degraded service. In

contrast, high performers have more frequent deployments, faster lead times, and quicker recovery

from incidents.

Reference: DevOps Foundation v3.6 syllabus section 2.2; Accelerate: The Science of Lean Software

and DevOps.

When developers practice agile but operations is slow to deploy, it means IT Operations have not

kept pace—classic “left behind” scenario. DevOps aims to align development and operations,

breaking down barriers and enabling faster, safer, and more frequent deployments. DevOps is not

only about development (B is incorrect), does not break cadence but instead aligns it (C is incorrect),

and is not the same as agile but complements it (D is incorrect).

Reference: DevOps Foundation v3.6 syllabus section 1.5; The Phoenix Project; Accelerate.

DevOps is not simply a team, methodology, or standard. The PeopleCert DevOps Foundation v3.6

materials define DevOps as a “cultural and professional movement” that stresses communication,

collaboration, integration, and automation to improve workflow between software developers and IT

operations professionals. The cultural transformation is fundamental, emphasizing shared

responsibilities, breaking down silos, and fostering continuous improvement.

Reference: DevOps Foundation v3.6 syllabus section 1.1; State of DevOps Report; "The Phoenix

Project".

Agile funding is flexible and adapts to the iterative, incremental nature of Agile and DevOps projects.

It can be fixed cost for some work, continuous cost for ongoing value streams, and is reviewed

frequently to align with evolving priorities.

All three characteristics are true, so D (“All of the Above”) is correct.

Extract-style reference:

“Agile funding models support continuous review and adaptation, providing the flexibility required

for digital transformation and DevOps ways of working.”

— Project to Product, Mik Kersten

PeopleCert DevOps Foundation v3.6: Advocates funding models that encourage agility,

experimentation, and rapid value delivery.

A DevOps culture is built on principles like being data-driven, reflective (willing to learn from

experience), and accountable (taking ownership, not blaming others).

Command and control cultures are the opposite: hierarchical, rigid, discouraging initiative and

learning. DevOps strives for empowerment, experimentation, and psychological safety.

Why not the others?

Data-driven: Decisions are based on measurement and feedback, core to DevOps.

Reflective: Regular retrospectives and post-incident reviews are essential DevOps rituals.

Accountability: Teams are responsible for the software they build and operate.

Reference/Extract:

“DevOps culture values collaboration, continuous learning, and a data-driven, accountable approach

to improvement. Command and control structures stifle innovation and slow down feedback.”

— State of DevOps Report (2019), PeopleCert DevOps Foundation v3.6 Section 3.2

The most effective approach to tool selection in DevOps is to establish a toolchain—a set of

integrated tools that support the end-to-end lifecycle (planning, coding, building, testing, releasing,

deploying, operating, and monitoring).

This encourages consistency, automation, and traceability, while still allowing flexibility for teams.

Why not standardize on one vendor?

This reduces flexibility, can cause vendor lock-in, and doesn’t support the varied needs of Dev and

Ops teams.

Encouraging independent selection (C) increases fragmentation.

Focusing solely on testing (D) ignores the broader lifecycle.

Extract-style reference:

“Establishing an integrated toolchain provides end-to-end visibility and automation across the

software delivery pipeline, aligning tools with process and cultural change.”

— State of DevOps Report; DevOps Handbook

PeopleCert DevOps Foundation v3.6: Recommends a toolchain approach for supporting collaborative

DevOps practices.

Shift Left Testing means moving testing earlier in the development process, so defects are found

sooner and fixes are cheaper.

Unit testing as part of CI is the classic “shift left” strategy: automated unit tests run with every code

change, catching errors before code moves further down the pipeline.

Testing in production (A) is “shift right.”

Manual testing (B) is typically late-stage and not automated.

Biannual vulnerability assessments (D) are after-the-fact and far from “shift left.”

Extract-style reference:

“Shift left means performing testing activities earlier, for example by including unit tests in the CI

process, reducing costly late-stage defects.”

— DevOps Handbook

PeopleCert Foundation: “Shift left” is a key DevOps testing principle—find issues fast, fix fast, deploy

safely.

Cultural debt—not just low trust or poor leadership—best describes the scenario of entrenched silos

and combative Dev/Ops relations.

Cultural debt leads to resistance to new ways of working, lack of cooperation, and a focus on

individual rather than collective success.

Why not the others?

Low trust and poor leadership are symptoms of cultural debt.

Change fatigue occurs after repeated failed initiatives; here, the core issue is cultural stasis.

Reference/Extract:

“DevOps transformation often fails without addressing cultural debt. Breaking down silos, building

shared understanding, and changing incentives are essential for sustainable change.”

— DevOps Handbook, State of DevOps Report, PeopleCert DevOps Foundation v3.6 Section 3.4

Manufacturing is not a type of IT work in DevOps.

DevOps classifies IT work as:

Business projects: New value-creating work.

Planned work: Routine, repeatable tasks (maintenance, upgrades).

Unplanned work: Incidents, emergencies, support.

Extract-style reference:

“IT work includes business projects, planned work, and unplanned work. Manufacturing is an

analogy for flow, but not a category of IT work itself.”

— The Phoenix Project

PeopleCert DevOps Foundation v3.6: Recognizes these three categories to manage and improve IT

workloads.