DEVOPS-FOUNDATION Practice Questions

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.

Deployment frequency is not a culture metric.

It’s a process metric, indicating how often code is released.

Culture metrics focus on engagement, morale, retention, psychological safety, and NPS.

Why not the others?

Employee NPS: Measures employee satisfaction and willingness to recommend.

Engagement/morale: Direct indicators of cultural health.

Retention: How well an org keeps talented people, reflecting culture.

Extract-style reference:

“Measuring DevOps culture relies on employee engagement, morale, and retention, not on delivery

metrics like deployment frequency.”

— State of DevOps Report

PeopleCert DevOps Foundation v3.6: Culture metrics focus on people, not just process.

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.

Epics delivered is a software/process metric, not a business performance metric.

Business performance metrics include financial and market indicators: earnings, cashflow, market

share, revenue growth.

Why not the others?

Earnings, Cashflow, Marketshare: Directly tied to business health.

Extract-style reference:

“Business performance metrics focus on outcomes such as earnings, cashflow, and marketshare.

Agile metrics like epics delivered measure team output, not business value.”

— Project to Product, Mik Kersten

PeopleCert DevOps Foundation v3.6: Distinguishes business impact from process metrics.

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.

The two best measures to show shared success across technology teams are throughput and stability:

Throughput (deployment frequency, lead time): Measures how fast teams deliver value.

Stability (change failure rate, MTTR): Measures how reliably systems operate.

Why these two?

Focusing on both ensures teams deliver quickly and safely. High throughput without stability causes

outages; stability without throughput slows business.

Other options:

Deployment frequency + change lead/cycle time: Both are throughput measures, missing stability.

MTTR + change failure rate: Both are stability, missing throughput.

Employee retention and NPS: People measures, not delivery.

Extract-style reference:

“High performers in DevOps exhibit both high throughput (deployments per day) and high stability

(low failure rates, fast recovery), proving it’s possible to achieve both.”

— Accelerate: The Science of Lean Software and DevOps, Ch. 2

PeopleCert DevOps Foundation v3.6: Shared success is about flow and reliability, not just one or the

other.

Both B and C (Application of agile and lean methods + Management commitment to culture change)

are critical success factors when launching DevOps in a traditional IT organization.

Agile/Lean methods: Accelerate delivery, reduce waste, create feedback.

Management commitment to culture change: Essential for breaking silos, changing behaviors, and

making DevOps sustainable.

Forming a pilot team (A) helps, but isn’t sufficient without these foundations.

Extract-style reference:

“DevOps success starts with leadership commitment to cultural change and adopting Agile and Lean

principles throughout the organization.”

— DevOps Handbook, State of DevOps Report

PeopleCert DevOps Foundation v3.6: Lists cultural commitment and Lean/Agile as prerequisites for

DevOps transformation.

Thank you for your visit.

Command (authoritarianism) is not a crucial ingredient for leading digital transformation.

The key ingredients:

Collaboration

Curiosity

Courage

DevOps leadership is about empowering teams, experimenting, and driving change, not command-

and-control.

Extract-style reference:

“Digital transformation leaders embrace collaboration, curiosity, and courage, fostering an

environment where experimentation and learning drive change.”

— Accelerate, DevOps Handbook

PeopleCert DevOps Foundation v3.6: Advocates servant and transformational leadership, not

command/control.

Coercive communication (using force or threat) is not a transformational leadership dimension.

Transformational leaders:

Inspire vision

Recognize contributions

Stimulate new ideas (intellectual stimulation)

Foster intrinsic motivation

Extract-style reference:

“Transformational leadership builds trust, motivates by vision, provides intellectual stimulation, and

recognizes individuals—not by coercion, but by inspiration.”

— Transformational Leadership (James Burns), PeopleCert DevOps Foundation v3.6

Loosely coupled architectures are not typical IT constraints; in fact, they are often a solution to

constraints.

Typical IT constraints include:

Security assessments (slow approvals)

Bureaucratic processes (excessive paperwork or approvals)

Development delays (resource or tool bottlenecks)

Extract-style reference:

“Loosely coupled architectures enable teams to work independently, reducing constraints imposed

by tightly integrated systems.”

— Accelerate: The Science of Lean Software and DevOps

DevOps Foundation v3.6 lists constraints as blockers to fast flow and highlights architectural

decoupling as a DevOps enabler.