Questions for the SAFE-DEVOPS were updated on : Nov 21 ,2025
What does the %C&A metric measure in the Continuous Delivery Pipeline?
D
Explanation:
The %C&A metric measures the percent of time downstream customers receive work that is usable
as-is in the Continuous Delivery Pipeline. The %C&A metric is a measure of the quality of the work
output from a process step. It indicates the percentage of time that the downstream customers
receive work that is acceptable as is, without any rework or errors. To calculate the %C&A metric, the
people responsible for the next step need to inspect the work output from the previous step and
determine whether it meets the quality standards and expectations. They also need to provide
feedback to the previous step on the defects or issues they find and how they affect the value
stream. By measuring the %C&A metric, the enterprise can gain insight into the current state of the
delivery process, such as the lead time, cycle time, throughput, quality, and waste. This insight can
help the enterprise identify bottlenecks, dependencies, handoffs, delays, and inefficiencies that
affect the flow of value. The %C&A metric can also help the enterprise understand how the flow of
value can be improved by applying the principles and practices of DevOps, such as culture,
automation, lean flow, measurement, and recovery.
By improving the %C&A metric, the enterprise
can increase customer satisfaction, reduce costs, accelerate time-to-market, and enhance business
agility
Who is responsible for ensuring quality is built into the code in SAFe?
B
Explanation:
Agile Teams are responsible for ensuring quality is built into the code in SAFe. SAFe is a framework
for scaling agile practices across the enterprise, based on the principles of Lean, Agile, and DevOps.
SAFe organizes the enterprise into Agile Release Trains (ARTs), which are teams of Agile Teams that
deliver value in a regular cadence. Agile Teams are the fundamental building blocks of SAFe, and they
are cross-functional, self-organizing, and self-managing teams that deliver value in short iterations.
Agile Teams are responsible for ensuring quality is built into the code in SAFe, by applying the
following practices:
Test-first – Test-first is a practice that involves writing tests before writing code, to ensure that the
code meets the requirements and standards, and does not introduce any defects or vulnerabilities.
Test-first helps to improve the design and maintainability of the code, and to accelerate the feedback
and validation process. Test-first can be implemented using various techniques, such as Test-Driven
Development (TDD), Behavior-Driven Development (BDD), or Acceptance Test-Driven Development
(ATDD).
Built-in quality – Built-in quality is a practice that involves applying quality standards and checks
throughout the solution lifecycle, rather than inspecting quality after the fact. Built-in quality helps to
prevent defects from escaping to downstream stages or customers, and to reduce the cost and risk of
rework and waste. Built-in quality can be achieved using various methods, such as code quality and
security analysis, code review, pair programming, refactoring, and continuous testing.
Continuous testing – Continuous testing is a practice that involves automating and executing tests at
every stage of the Continuous Delivery Pipeline, to verify that the solution meets the functional and
nonfunctional requirements and standards, and to detect and resolve any issues or defects as early
as possible. Continuous testing helps to ensure the reliability and performance of the solution, and
to support the delivery and deployment of value to the customer.
Continuous testing can be
performed using various tools and frameworks, such as unit testing, integration testing, system
testing, acceptance testing, performance testing, and security testing
What are two activities performed as part of defining the hypothesis in Continuous Exploration?
(Choose two.)
B, D
Explanation:
Two activities performed as part of defining the hypothesis in Continuous Exploration are identifying
metrics based on leading indicators and defining the minimum viable product. Continuous
Exploration (CE) is an aspect of the Continuous Delivery Pipeline that drives innovation and fosters
alignment on what should be built by continually exploring the market and customer needs, defining
a vision, roadmap, and set of features for a solution that addresses those needs. CE is based on
applying customer-centric and design thinking to understand and create alignment on new
development opportunities, while recognizing that all such ideas are hypotheses that need to be
validated. CE involves four activities: hypothesize, collaborate and research, synthesize, and validate.
The hypothesize activity describes the practices for generating ideas and the measurements needed
to validate them with customers. The hypothesize activity involves the following practices:
Identifying metrics based on leading indicators – Leading indicators are metrics that measure the
expected outcomes and benefits of the solution, such as customer satisfaction, retention,
engagement, and revenue. Leading indicators help to evaluate the validity of the hypotheses and
assumptions about the customer value proposition, and to guide the decision making and
prioritization of the features. Leading indicators are also known as key performance indicators (KPIs)
or objectives and key results (OKRs).
Defining the minimum viable product (MVP) – An MVP is a version of the solution that has just
enough features to test the hypotheses and assumptions about the customer value proposition, and
to elicit feedback from the customer. An MVP is not a fully functional or polished product, but rather
a learning vehicle that allows the enterprise to validate the problem-solution fit and the product-
market fit.
An MVP helps to reduce the uncertainty and risk of developing the wrong solution, and to
accelerate the learning and discovery process11
What are two benefits of DevOps? (Choose two.)
D, E
Explanation:
Two benefits of DevOps are fewer defects and less time spent fixing security issues. DevOps is a
mindset, culture, and set of technical practices that supports the integration, automation, and
collaboration needed to effectively develop and operate a solution. DevOps helps break down
organizational silos and develop a Continuous Delivery Pipeline — a high-performance innovation
engine capable of delivering market-leading solutions at the speed of business. DevOps has many
benefits for the enterprise, such as:
Fewer defects – DevOps improves the quality and consistency of the solution by enforcing frequent
testing and validation throughout the solution lifecycle. DevOps applies various testing techniques
and tools, such as unit testing, integration testing, acceptance testing, performance testing, and
security testing, to verify that the solution meets the functional and nonfunctional requirements and
standards. DevOps also enables early detection and resolution of defects, by implementing fast and
frequent feedback loops within and across the value stream. DevOps reduces the cost and risk of
defects, by shifting quality left and building quality in, rather than inspecting quality out.
Less time spent fixing security issues – DevOps enhances the security and compliance of the solution
by integrating security practices into the value stream. DevOps applies the DevSecOps approach,
which emphasizes the importance of proper information security practices in the pursuit of
continuous delivery. DevSecOps involves applying automated tools and processes to detect and
respond to security threats and vulnerabilities in the development and production environments,
and ensuring compliance with security policies and standards. DevSecOps also involves collaborating
with security teams and stakeholders, to foster a culture of shared responsibility and awareness for
security.
DevSecOps reduces the time and effort spent on fixing security issues, by shifting security
left and building security in, rather than bolting security on8
What is a core DevOps principle?
B
Explanation:
Culture is a core DevOps principle. DevOps is not only a set of technical practices, but also a mindset
and a culture that supports the integration, automation, and collaboration needed to effectively
develop and operate a solution. DevOps culture is based on the following values and behaviors:
Shared responsibility – DevOps culture fosters a sense of shared ownership and accountability for the
entire solution lifecycle, from ideation to operation. Development and operations teams work
together, not only to help each other, but also to ensure that the overall organization succeeds.
DevOps culture eliminates the blame game and the silo mentality, and encourages mutual trust and
respect among all stakeholders.
Continuous learning – DevOps culture promotes a culture of continuous learning and improvement,
where teams are constantly seeking feedback, experimenting with new ideas, and learning from
failures. DevOps culture embraces a growth mindset, where teams are not afraid to try new things,
challenge the status quo, and learn from their mistakes. DevOps culture also supports a learning
organization, where teams share their knowledge and best practices, and leverage the collective
intelligence of the whole enterprise.
Customer focus – DevOps culture emphasizes the importance of delivering value to the customer,
and aligning the solution to the customer needs and expectations. DevOps culture applies customer-
centric and design thinking approaches, such as personas, empathy maps, and customer journeys, to
understand and empathize with the customer problems and desires. DevOps culture also validates
the assumptions and hypotheses about the customer value proposition, by collecting and analyzing
data and feedback from the customer.
Automation – DevOps culture leverages automation to improve the efficiency, quality, and reliability
of the solution delivery process. DevOps culture applies automation to various aspects of the
Continuous Delivery Pipeline, such as testing, integration, deployment, monitoring, and
security.
DevOps culture also uses automation to reduce manual work, eliminate human errors, and
accelerate feedback loops5
What falls outside the scope of the Stabilize activity?
C
Explanation:
Blue/green deployment falls outside the scope of the Stabilize activity. The Stabilize activity is part of
the Release on Demand aspect of the Continuous Delivery Pipeline, which is responsible for releasing
new functionality to end users, either immediately or incrementally, based on business and customer
needs. The Stabilize activity ensures that the solution is working well from a functional and
nonfunctional perspective, and that it can be operated and supported effectively. The Stabilize
activity involves the following practices:
Continuous security monitoring – Applying automated tools and processes to detect and respond to
security threats and vulnerabilities in the production environment, and ensuring compliance with
security policies and standards.
Failover and recovery processes – Establishing and testing backup and restore mechanisms, disaster
recovery plans, and business continuity procedures, to ensure the availability and resilience of the
solution in case of failures or disruptions.
Features monitoring – Collecting and analyzing data on the usage, performance, and outcomes of the
released features, to measure their value and impact, and to identify any issues or defects that need
to be fixed or improved.
Support and maintenance – Providing ongoing support and maintenance for the solution, such as
resolving incidents, handling requests, applying patches, and performing upgrades, to ensure the
reliability and quality of the solution.
Blue/green deployment, on the other hand, is a technical practice that belongs to the Continuous
Deployment aspect of the Continuous Delivery Pipeline, which is responsible for deploying new
functionality into the production environment, where it can be tested and validated. Blue/green
deployment is a change management strategy that reduces the downtime and risk of deploying new
versions of software. It involves having two identical but separate environments: one is the active
environment that serves the user traffic (blue), and the other is the inactive environment that hosts
the new version of the software (green). The deployment process consists of switching a small
portion of the user traffic from the blue environment to the green environment, after verifying that
the new version is working properly. The portion of users who receive the new version are called
canaries, as they serve as early indicators of the quality and performance of the new version. If the
canary release is successful, the entire user traffic is gradually switched to the green environment,
which becomes the new active environment. If the canary release fails, the user traffic is switched
back to the blue environment, which remains the active environment. Blue/green deployment has
several benefits, such as:
It allows for fast and reliable rollback, in case of any issues or errors in the new version, by simply
switching back to the active environment.
It eliminates the need for complex and error-prone migration scripts, as the inactive environment
can be prepared and tested in advance, without affecting the active environment.
It enables testing and experimentation of the new version with a subset of users, by directing some
user traffic to the inactive environment, before switching completely.
It facilitates continuous delivery and deployment, by automating the switching process and reducing
the transaction cost and risk of moving changes to production
Which two areas should be monitored in the Release on Demand aspect to support DevOps and
Continuous Delivery? (Choose two.)
B, D
Explanation:
Two areas that should be monitored in the Release on Demand aspect to support DevOps and
Continuous Delivery are the build status and the deployment cycle time. The build status is the
measure of whether the code and components can be successfully compiled, linked, packaged, and
verified into deployable binaries. The build status indicates the quality and consistency of the code
and the readiness for deployment. Monitoring the build status helps to support the Release on
Demand aspect in SAFe by providing valuable information for the following purposes:
To identify and fix any errors or defects that may prevent the code from being deployed or released
To ensure that the code meets the quality standards and security checks, such as static code analysis,
code coverage, and code review
To verify that the code and components are integrated and merged correctly into the trunk
To track the progress and status of the features and capabilities that are being developed and
delivered
The deployment cycle time is the measure of how long it takes to deploy the code and components
from the source control system to the production environment. The deployment cycle time indicates
the efficiency and reliability of the deployment process and the speed of delivery. Monitoring the
deployment cycle time helps to support the Release on Demand aspect in SAFe by providing valuable
information for the following purposes:
To optimize the deployment process and reduce the lead time and variability
To automate the deployment process and eliminate manual steps and errors
To align the deployment process with the market demand and release strategy
To evaluate the impact and value of the deployed features and capabilities 7
Why are canary releases used?
D
Explanation:
Canary releases are used to allow incremental release of new functionality to customers. A canary
release is a change management strategy for software releases that reduces the downtime and risk
of deploying new versions of software. A canary release involves having two identical but separate
environments: one is the active environment that serves the user traffic, and the other is the inactive
environment that hosts the new version of the software. The release process consists of switching a
small portion of the user traffic from the active environment to the inactive environment, after
verifying that the new version is working properly. The portion of users who receive the new version
are called canaries, as they serve as early indicators of the quality and performance of the new
version. The canary release has several benefits, such as:
It allows for fast and reliable rollback, in case of any issues or errors in the new version, by simply
switching back to the active environment.
It eliminates the need for complex and error-prone migration scripts, as the inactive environment
can be prepared and tested in advance, without affecting the active environment.
It enables testing and experimentation of the new version with a subset of users, by directing some
user traffic to the inactive environment, before switching completely.
It facilitates continuous delivery and deployment, by automating the switching process and reducing
the transaction cost and risk of moving changes to production
Which DevOps principle focuses on identifying and eliminating bottlenecks in the Continuous
Delivery Pipeline?
C
Explanation:
Lean flow is the DevOps principle that focuses on identifying and eliminating bottlenecks in the
Continuous Delivery Pipeline. Lean flow is the application of Lean thinking and principles to optimize
the flow of value from ideation to delivery. Lean flow aims to reduce waste, increase efficiency, and
deliver value faster and more reliably. Lean flow involves the following practices:
Reducing batch size – Breaking down large batches of work into smaller, more manageable pieces
that can be delivered more frequently and with less risk.
Limiting work in progress (WIP) – Restricting the amount of work that can be started or in flight at
any given time, to avoid overloading the system and creating queues and delays.
Implementing pull systems – Aligning the production and consumption of work by allowing
downstream customers to pull work from upstream suppliers when they are ready, rather than
pushing work based on forecasts or schedules.
Managing queue lengths – Monitoring and controlling the amount of work waiting to be processed
at each stage of the value stream, to reduce lead time and variability.
Reducing handoffs – Minimizing the number of transitions and dependencies between different
teams or individuals, to avoid communication gaps, context switching, and rework.
Implementing Work in Process (WIP) visualization – Making the work and its status visible to all
stakeholders, using tools such as Kanban boards, Cumulative Flow Diagrams (CFDs), and Value
Stream Maps (VSMs), to enable collaboration, coordination, and improvement.
Implementing Work in Process (WIP) feedback – Establishing fast and frequent feedback loops within
and across the value stream, using tools such as automated testing, monitoring, and metrics, to
detect and resolve issues, validate assumptions, and learn from outcomes3
Which technical practice is key to enabling trunk-based development?
A
Explanation:
Gated commits are a key technical practice that enables trunk-based development. Gated commits
are a mechanism that ensures that only code that passes certain quality checks and tests can be
committed to the main trunk of the shared codebase. Gated commits prevent broken changes from
affecting other developers or the Continuous Delivery Pipeline. Gated commits typically involve the
following steps:
A developer writes code and runs local tests on their own machine or branch.
The developer pushes the code to a remote repository, where a pre-commit hook triggers a build and
test process on a separate server.
The build and test process verifies that the code meets the quality standards and does not introduce
any errors or conflicts with the existing code on the trunk.
If the build and test process succeeds, the code is automatically merged into the trunk and becomes
available for other developers and downstream activities.
If the build and test process fails, the code is rejected and the developer is notified of the issues that
need to be fixed before retrying the commit.
Gated commits support trunk-based development by ensuring that the trunk is always in a
releasable state, which means that at least once a day, developers must integrate their changes to
the trunk. This is accomplished through short-lived feature branches related to project tasks.
Gated
commits reduce the complexity and conflicts of merging long-lived branches, improve the quality
and consistency of the code by enforcing frequent testing and validation, accelerate the delivery and
deployment of new functionality by minimizing the transaction cost and risk, and foster a culture of
collaboration and transparency among developers
What is the correct order of activities in the Continuous Integration aspect?
D
Explanation:
The correct order of activities in the Continuous Integration aspect is: Develop, Build, Test end-to-
end, Stage. Continuous Integration (CI) is an aspect of the Continuous Delivery Pipeline that
automates the development, testing, integration, and validation of new functionality in preparation
for deployment and release. CI is the second aspect in the four-part Continuous Delivery Pipeline of
Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment (CD), and Release
on Demand. CI consists of four activities, as shown in Figure 1:
Develop – This activity involves implementing stories by refining features from the ART Backlog,
coding, testing, and committing the work product into the source control system. Testing in this
activity tends to focus on unit and story-level testing and often requires test doubles to replicate
other components or subsystems that are not readily available or easily tested.
Build – This activity involves creating deployable binaries and merging development branches into
the trunk. Building in this activity includes compiling, linking, packaging, and verifying the code and
components. Building also involves applying code quality and security checks, such as static code
analysis, code coverage, and code review.
Test end-to-end – This activity involves validating the solution end-to-end, including the functional
and nonfunctional aspects, such as performance, usability, reliability, and security. Testing in this
activity requires integrating the code and components with other subsystems and services, and using
test environments that resemble the production environment as much as possible. Testing also
involves applying automated testing tools and frameworks, such as regression testing, integration
testing, system testing, and acceptance testing.
Stage – This activity involves hosting and validating solutions in a staging environment before
production. Staging in this activity includes deploying the solution to a pre-production environment
that mimics the production environment in terms of hardware, software, configuration, and
data.
Staging also involves applying final checks and verifications, such as smoke testing, exploratory
testing, and user acceptance testing910
1: https://www.lean.org/the-lean-post/articles/understanding-the-fundamentals-of-value-stream-
mapping/ 2: https://www.gembaacademy.com/school-of-lean/value-stream-mapping/adapting-
value-stream-mapping-for-office-and-service-environments/what-is-the-c-a-percentage-complete-
accurate-metric 3: https://scaledagileframework.com/guidance-applied-innovation-accounting-in-
safe/ 4: https://support.scaledagile.com/s/article/Exam-Study-Guide-SDP-6-0-SAFe-for-DevOps 5:
https://www.redhat.com/en/topics/devops/what-is-blue-green-deployment 6:
https://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html 7:
https://scaledagileframework.com/guidance-applied-innovation-accounting-in-safe/ 8:
https://support.scaledagile.com/s/article/Exam-Study-Guide-SDP-6-0-SAFe-for-DevOps 9:
https://scaledagileframework.com/continuous-integration/ 10
:
https://support.scaledagile.com/s/article/Exam-Study-Guide-SDP-6-0-SAFe-for-DevOps
Innovation accounting stresses the importance of avoiding what?
C
Explanation:
Innovation accounting stresses the importance of avoiding vanity metrics. Vanity metrics are metrics
that look good on paper but do not reflect the true value or impact of an innovation. Examples of
vanity metrics include the number of downloads, page views, followers, or likes, which may not
indicate whether the users are actually engaged, satisfied, or loyal to the product or service. Vanity
metrics can be misleading, deceptive, or irrelevant, and can cause the enterprise to waste time and
resources on pursuing the wrong goals or strategies. Innovation accounting, on the other hand, is a
term coined by Eric Ries in his book The Lean Startup, which describes a process of measuring and
learning from the outcomes of innovation experiments. Innovation accounting involves defining the
hypothesis, building the minimum viable product (MVP), and evaluating the results using actionable
metrics. Actionable metrics are metrics that demonstrate the cause and effect relationship between
the actions taken and the outcomes achieved. Examples of actionable metrics include the conversion
rate, retention rate, revenue per customer, or customer satisfaction score, which can indicate
whether the product or service is delivering value to the customer and the enterprise.
Actionable
metrics can help the enterprise to validate or invalidate the hypothesis, and to decide whether to
pivot or persevere with the innovation78
What is the purpose of the blue/green deployment pattern?
D
Explanation:
The purpose of the blue/green deployment pattern is to deploy between an inactive and active
environment. The blue/green deployment pattern is a change management strategy for software
releases that reduces the downtime and risk of deploying new versions of software. The blue/green
deployment pattern involves having two identical but separate environments: one is the active
environment (blue) that serves the user traffic, and the other is the inactive environment (green) that
hosts the new version of the software. The deployment process consists of switching the user traffic
from the blue environment to the green environment, after verifying that the new version is working
properly. The blue environment can then be kept as a backup or updated to become the next green
environment. The blue/green deployment pattern has several benefits, such as:
It allows for fast and reliable rollback, in case of any issues or errors in the new version, by simply
switching back to the blue environment.
It eliminates the need for complex and error-prone migration scripts, as the green environment can
be prepared and tested in advance, without affecting the blue environment.
It enables testing and experimentation of the new version with a subset of users, by directing some
user traffic to the green environment, before switching completely.
It facilitates continuous delivery and deployment, by automating the switching process and reducing
the transaction cost and risk of moving changes to production
Which statement describes the Lean startup lifecycle?
B
Explanation:
The statement that describes the Lean startup lifecycle is: Define the hypothesis, build a minimum
viable product (MVP), continuously evaluate the MVP while implementing additional Features until
WSJF determines work can stop. The Lean startup lifecycle is a highly iterative build-measure-learn
cycle that has proven to be effective in optimizing the economic value of strategic investments. It
consists of three learning milestones: MVP, tune the engine, and pivot or persevere. The MVP is the
smallest possible experiment that allows the enterprise to test the assumptions and hypotheses of
an epic or a large initiative. The tune the engine phase involves quickly adjusting and moving
towards the goal based on the data and feedback gathered from the MVP. The pivot or persevere
phase involves deciding whether to deliver additional value or move on to something more valuable
based on the validated learning. The Lean startup lifecycle is supported by the SAFe Lean Startup
Cycle, which provides guidance and tools for applying the Lean startup principles in the context of
SAFe. The SAFe Lean Startup Cycle includes the following steps:
Define the hypothesis – This step involves creating an epic hypothesis statement that defines the
initiative, its expected benefits, and its leading indicators.
Build the MVP – This step involves defining, building, and deploying the MVP that tests the
hypothesis and delivers the minimum amount of value to the customer.
Evaluate the MVP – This step involves measuring and analyzing the results of the MVP against the
leading indicators and the hypothesis.
Implement additional Features – This step involves developing and delivering additional features or
capabilities that enhance the value proposition of the initiative, based on the learning from the MVP.
WSJF determines work can stop – This step involves using the Weighted Shortest Job First (WSJF)
prioritization method to determine whether the initiative has delivered enough value to the
customer and the enterprise, or whether it needs more investment or termination3
Who should be consulted first when calculating the % Complete and Accurate?
A
Explanation:
The people responsible for the next step should be consulted first when calculating the % Complete
and Accurate (%C&A) metric. The %C&A metric is a measure of the quality of the work output from a
process step. It indicates the percentage of time that the downstream customers receive work that is
acceptable as is, without any rework or errors. To calculate the %C&A metric, the people responsible
for the next step need to inspect the work output from the previous step and determine whether it
meets the quality standards and expectations. They also need to provide feedback to the previous
step on the defects or issues they find and how they affect the value stream.
By consulting the
people responsible for the next step, the %C&A metric can reflect the actual customer satisfaction
and the potential waste in the process1