PeopleCert DevOps Foundation Exam Questions Instant Access

Question 1

A team has recently introduced their first Kanban board and are saying that they are finding it hard to focus and are feeling exhausted from context switching. Additionally, the business is complaining that nothing is being finished and they are yet to receive any of what they asked for.

What do the team need to do?

APush more work onto the board to provide more opportunities to deliver something

BAdd more development resources to the team to cope with the workload

CTry using Work in Progress limits

DUnblock any blocked work items

Answer : C

When Kanban teams feel overwhelmed and nothing is getting finished, it's a sign that too much work is in progress (WIP). Work in Progress (WIP) limits are a key Kanban and Lean practice: they restrict how many tasks can be active at one time, forcing teams to focus, finish, and deliver before starting new work.

Pushing more work (A) or adding more resources (B) worsens the problem.

Unblocking work (D) is helpful, but the core issue is overload.

Extract-style reference: ''WIP limits encourage teams to finish work before starting new tasks, reducing context switching and enabling better flow and faster delivery.'' --- Kanban: Successful Evolutionary Change for Your Technology Business, David J. Anderson PeopleCert DevOps Foundation: Limiting WIP is essential for effective flow and sustainable pace.

Question 2

An organization has identified they have a culture of blame where people are fearful of failure and lack the courage to try new things.

What can they do to encourage more courageous and experimentational behaviors?

AIdentify and punish the people that make mistakes

BSharing is inhibited

CBuild rituals that reward risk taking

DBoth b and c

Answer : C

A blame culture is toxic and inhibits innovation. DevOps encourages a culture where risk-taking and experimentation are rewarded, not punished. Organizations should 'build rituals that reward risk taking'---examples include celebrating ''fast failures'' and running blameless post-mortems.

Extract-style reference: ''Encourage a culture where failure is seen as a learning opportunity, not a cause for punishment. Rituals that reward risk-taking foster innovation and create psychological safety.'' --- DevOps Handbook DevOps Foundation v3.6 (Cultural Principles section) advocates psychological safety, learning from failure, and reward systems that incentivize experimentation.

Question 3

Which of the following is NOT a characteristic of a DevOps culture?

AData driven

BReflective

CCommand and control

DAccountability

Answer : C

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

Question 4

A large organization conducts a DevOps toolchain review and discovers that multiple development teams have built their own continuous delivery pipelines with a variety of different tooling.

Which of the following strategies would NOT help them manage their toolchain evolution moving forwards?

AHaving IT Operations or infrastructure squads architect and manage a DevOps toolchain service to offer to the development teams

BTelling all development teams they must immediately migrate to a standard set of tools dictated by IT Operations

CUsing sensible defaults to guide teams' choices

DMaking the DevOps toolchain available self-service

Answer : B

Forcing all development teams to immediately migrate to a standard set of tools dictated by IT Operations is not a recommended DevOps strategy.

DevOps promotes collaboration, flexibility, and evolution of toolchains, allowing teams to choose what fits their needs while moving toward sensible defaults and integration over time.

Abrupt, top-down mandates undermine trust and autonomy, often leading to resistance and lower adoption.

Why are the other options better?

IT Ops or infra squads managing toolchain as a service (A), sensible defaults (C), and self-service (D) are all recognized best practices to support DevOps evolution and developer enablement.

Extract-style reference: ''Mandating a single toolset without considering team needs reduces engagement. Toolchains should be managed as self-service platforms with sensible defaults, supporting but not constraining teams.'' --- State of DevOps Report; DevOps Handbook PeopleCert DevOps Foundation v3.6: Encourages enabling choice, not enforcing uniformity without context.

Question 5

Firmly entrenched silos and a combative relationship between Dev and Ops is an example of:

ALow trust

BPoor leadership

CChange fatigue

DCultural debt

Answer : D

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

Question 6

What makes the concept of learning through immersion particularly useful in a DevOps culture?

APeople learn by doing

BPeople learn from subject matter experts

CPeople learn from their failures in a safe environment

DAll of the Above

Answer : D

Learning through immersion is powerful in DevOps because:

People learn by doing (A)

People learn from subject matter experts (B)

People learn from failures in a safe environment (C)

All of the above (D) are true

DevOps encourages hands-on, real-world, collaborative, and safe-to-fail learning environments.

Extract-style reference: ''Immersive learning, including hands-on labs, peer interactions, and blameless retrospectives, is vital to building DevOps capabilities.'' --- DevOps Handbook, Accelerate PeopleCert DevOps Foundation v3.6: Calls for learning culture, blamelessness, and experimentation.

Question 7

How do you define Wait Time?

ALead time minus cycle time

BCycle time minus lead time

CLead time plus cycle time

DCycle time multiplied by lead time

Answer : A

Wait Time is the time work spends waiting between process steps---wasted, non-value-added time.

Mathematically, Wait Time = Lead Time -- Cycle Time

Lead Time: Time from work request to delivery.

Cycle Time: Time spent actively working on the item.

Why is this important in DevOps? Identifying and reducing wait time (waste) is central to Lean/DevOps, directly improving flow and reducing delays.

Extract-style reference: ''Wait time is calculated as the difference between lead time and cycle time---highlighting bottlenecks in the value stream.'' --- DevOps Handbook PeopleCert DevOps Foundation v3.6: Wait time is a core Lean concept for optimizing flow.

PeopleCert DEVOPS Institute DevOps Foundation v3.6 Exam DevOps Foundation Exam Questions