SAFe for Architects ARCH 6.0 Exam Questions

Domain 1: Agile Architecture and SAFe

What is the primary aim of Agile Architecture in SAFe?

⬜ To eliminate the need for any architectural planning
✅ To balance intentional architecture with emergent design so systems can evolve incrementally while still supporting current and future needs
⬜ To require a complete upfront design before any code is written
⬜ To centralize every technical decision with a single Enterprise Architect

Explanation:-
Agile Architecture blends deliberate, planned architecture with the design that emerges as teams build and learn, avoiding both chaotic emergent-only design and rigid big-upfront-design.
Source: https://framework.scaledagile.com/agile-architecture

Why can’t SAFe rely on emergent design alone at enterprise scale?

⬜ Emergent design is illegal under the SAFe Candidate Agreement
✅ Without any intentional architecture, large systems risk inconsistent standards, poor reusability, security gaps, and expensive rework across teams
⬜ Emergent design only works for hardware systems, not software
⬜ Emergent design eliminates the need for Enablers

Explanation:-
At scale, purely emergent design across many independent teams tends to produce duplicated, inconsistent, and hard-to-integrate solutions, so some intentional architecture is needed to provide shared direction.
Source: https://framework.scaledagile.com/agile-architecture

What is the Architectural Runway?

⬜ A backlog of unfinished user stories
✅ The existing code, components, and technical infrastructure needed to implement near-term features with minimal redesign and delay
⬜ A physical space where architects meet
⬜ The list of all defects logged against a Solution

Explanation:-
Architectural Runway represents how much of the technical foundation is already in place to support upcoming features without significant rework, enabling continuous value delivery.
Source: https://framework.scaledagile.com/architectural-runway

Domain 2: DevOps and Release on Demand

What is the primary purpose of Continuous Exploration in the Continuous Delivery Pipeline?

⬜ To automatically deploy code to production
✅ To identify and prioritize new features and ideas that will deliver value to customers before building them
⬜ To run automated regression tests only
⬜ To calculate the ART Predictability Measure

Explanation:-
Continuous Exploration is where ideas are researched, defined, and prioritized (often as Features or Enablers) before entering development.
Source: https://framework.scaledagile.com/continuous-delivery-pipeline

What is the primary purpose of Continuous Integration in the Continuous Delivery Pipeline?

⬜ To decide the enterprise’s annual budget
✅ To develop, test, integrate, and validate features in a staging environment ready for deployment
⬜ To gather customer feedback after release
⬜ To write the Portfolio Vision

Explanation:-
Continuous Integration takes work from multiple teams, combines it, and verifies it works together and meets quality standards before it moves toward deployment.
Source: https://framework.scaledagile.com/continuous-delivery-pipeline

What is the primary purpose of Continuous Deployment in the Continuous Delivery Pipeline?

✅ To take validated code from staging and move it into production, making it available for release
⬜ To brainstorm brand-new feature ideas
⬜ To write Lean Business Cases for epics
⬜ To conduct the Inspect and Adapt workshop

Explanation:-
Continuous Deployment is the process of taking validated changes and preparing/moving them into the production environment, separate from when they’re actually released to customers.
Source: https://framework.scaledagile.com/continuous-delivery-pipeline

What is the primary purpose of Release on Demand?

⬜ To release every change immediately upon being coded, with no separation between deploy and release
✅ To release value to customers whenever the business needs it, decoupled from the deployment of that value into production
⬜ To require all releases to happen only once per year
⬜ To replace the need for a Continuous Delivery Pipeline

Explanation:-
Release on Demand separates deployment (getting code into production) from release (making a capability available to customers), so the business can choose exactly when value is exposed.
Source: https://framework.scaledagile.com/continuous-delivery-pipeline

Which of the following best describes a healthy DevOps culture in the context of architecture and delivery?

⬜ Development and Operations work in separate silos with formal handoff documents
✅ Shared responsibility, collaboration, and trust between Development and Operations, supported by automation, measurement, and fast recovery
⬜ Only the Operations team is responsible for production issues
⬜ DevOps means eliminating the Operations role entirely

Explanation:-
A strong DevOps culture emphasizes collaboration and shared ownership across Dev and Ops, reinforced by automation and continuous measurement, rather than siloed handoffs.
Source: https://framework.scaledagile.com/devops

Domain 3: Architecture with Business Value

What is the purpose of an Exploration Enabler?

⬜ To automate deployment pipelines
✅ To support the research, design spikes, and analysis needed to understand a problem or opportunity before committing to a solution
⬜ To fix production incidents
⬜ To document completed Features after release

Explanation:-
Exploration Enablers capture the work needed to explore customer needs, evaluate alternatives, or research a technical approach before building it.
Source: https://framework.scaledagile.com/enablers

What is the purpose of an Architecture Enabler?

⬜ To fund marketing campaigns for a new Solution
✅ To build the architectural runway needed to support current and future business Features
⬜ To onboard new employees
⬜ To replace Continuous Integration

Explanation:-
Architecture Enablers extend the Architectural Runway so upcoming business Features can be implemented without excessive redesign.
Source: https://framework.scaledagile.com/enablers

What is the purpose of an Infrastructure Enabler?

✅ To build or improve the technical infrastructure (e.g., environments, tooling, pipelines) required to develop, test, and deploy solutions
⬜ To gather customer requirements
⬜ To write the Portfolio Vision
⬜ To replace the need for a Lean Business Case

Explanation:-
Infrastructure Enablers cover work like environment setup, tooling, and platform capabilities that the delivery pipeline depends on.
Source: https://framework.scaledagile.com/enablers

What is the purpose of a Compliance Enabler?

⬜ To speed up feature delivery by skipping documentation
✅ To satisfy regulatory, security, or other compliance requirements a Solution must meet
⬜ To replace Continuous Deployment
⬜ To fund Strategic Investment Planning

Explanation:-
Compliance Enablers capture the work needed to meet legal, regulatory, security, or audit requirements applicable to the Solution.
Source: https://framework.scaledagile.com/enablers

Why would an Architect use WSJF (Weighted Shortest Job First) when prioritizing Enablers alongside Features?

⬜ Because Enablers are never worth prioritizing
✅ Because it provides an economically sound way to sequence both Enablers and Features by dividing the Cost of Delay by job size
⬜ Because WSJF applies only to Portfolio Epics, never Enablers
⬜ Because it removes the need for any Architectural Runway

Explanation:-
WSJF gives teams and architects a consistent, economic way to sequence Enablers next to Features so architectural investment is weighed against business value, not treated as a separate, lower-priority category by default.
Source: https://framework.scaledagile.com/wsjf

Which components typically make up the Cost of Delay used in WSJF?

✅ User-business value, time criticality, and risk reduction/opportunity enablement value
⬜ Only the number of story points
⬜ Only the developer’s hourly rate
⬜ Only the number of defects found

Explanation:-
Cost of Delay combines user/business value, time criticality, and risk reduction or opportunity enablement value to reflect the economic impact of delaying a job.
Source: https://framework.scaledagile.com/wsjf

An architect insists on building a highly flexible, generalized solution for a need that is unlikely to change for years. What SAFe principle is this architect violating?

⬜ Built-In Quality
✅ Avoiding unnecessary complexity/over-engineering (“gold-plating”) relative to actual, near-term business value
⬜ Continuous Deployment
⬜ Weighted Shortest Job First

Explanation:-
Agile Architecture favors building just enough to support current and near-term needs economically, rather than over-investing in speculative flexibility that isn’t justified by business value.
Source: https://framework.scaledagile.com/agile-architecture

How does SAFe recommend Nonfunctional Requirements (NFRs) be treated?

⬜ As ordinary user stories that must be estimated and demoed like any Feature
✅ As system-wide constraints (e.g., performance, security, scalability) that constrain the design and acceptance criteria of the system, not one-off stories
⬜ As optional documentation with no impact on acceptance criteria
⬜ As something only the Product Owner needs to know about

Explanation:-
NFRs are typically expressed as constraints that apply across the system and shape the Definition of Done and acceptance criteria, rather than being implemented as isolated user stories.
Source: https://framework.scaledagile.com/nonfunctional-requirements

Which of the following is an example of a Nonfunctional Requirement?

⬜ “As a user, I want to reset my password”
✅ “The system must respond to 95% of requests within 200ms”
⬜ “Add a new column to the reports table”
⬜ “Fix the typo on the login page”

Explanation:-
Performance targets like response-time thresholds are classic NFRs — they constrain how the system must behave rather than describing a specific user-facing feature.
Source: https://framework.scaledagile.com/nonfunctional-requirements

What is the core idea behind Set-Based Design?

⬜ Commit to a single design option as early as possible to save time
✅ Explore multiple design or requirement options in parallel and narrow down based on empirical data before converging on a final solution
⬜ Only the most senior architect may propose design options
⬜ Avoid any experimentation with alternative designs

Explanation:-
Set-Based Design keeps several viable options open longer, using data and experimentation to converge on the best solution rather than committing to one option too early based on limited information.
Source: https://framework.scaledagile.com/set-based-design

Why does Set-Based Design typically delay the final design decision compared to a traditional point-based approach?

⬜ Because delaying decisions is inherently wasteful and should be avoided
✅ Because keeping options open until more information is available (via data, prototypes, or feedback) tends to lead to better, more economically sound decisions
⬜ Because SAFe requires all decisions to be made by a committee
⬜ Because it eliminates the need for an Architectural Runway

Explanation:-
By deferring commitment, teams can use real feedback and data to choose the best-performing option rather than betting everything on an early guess.
Source: https://framework.scaledagile.com/set-based-design

What does it mean to extend the Architectural Runway “just in time”?

⬜ Building all possible future architecture needs at the very start of the program
✅ Building enough runway to support near-term Features as they’re needed, rather than far in advance or only after teams are already blocked
⬜ Never investing in architecture until a production outage forces it
⬜ Letting each team build its own separate runway with no coordination

Explanation:-
Extending the runway just in time balances the risk of under-investing (teams get blocked) against over-investing (wasted effort on speculative architecture that may never be used).
Source: https://framework.scaledagile.com/architectural-runway

An ART consistently builds architecture far ahead of any near-term Feature need, based on speculation about future requirements. What risk does this create?

⬜ No risk; more architecture is always better
✅ Wasted investment and potential rework if the speculative assumptions turn out to be wrong before the runway is actually used
⬜ It guarantees the ART’s Flow Predictability will improve
⬜ It eliminates the need for WSJF prioritization

Explanation:-
Building architecture too far ahead of validated need risks investing in the wrong things, since assumptions about the future are less reliable the further out they extend.
Source: https://framework.scaledagile.com/architectural-runway

How should an architect approach the trade-off between building new business Features and paying down architectural/technical debt?

⬜ Always prioritize new Features and never address technical debt
✅ Weigh both economically (e.g., using WSJF) and ensure some ongoing capacity is allocated to maintaining runway and quality alongside new value delivery
⬜ Always prioritize technical debt over any new Feature
⬜ Technical debt should be addressed only once a year during a dedicated Enabler PI

Explanation:-
SAFe treats maintaining architecture and addressing technical debt as an economic trade-off against new Feature value, best managed through prioritization frameworks like WSJF and capacity allocation guardrails, not as an afterthought.
Source: https://framework.scaledagile.com/wsjf

Why is architecture and Enabler work in SAFe subject to the same economic prioritization thinking as business Features?

⬜ Because Enablers are technically identical to Features and should always be estimated the same way
✅ Because all work — Features and Enablers alike — competes for the same limited capacity, so it should be sequenced based on its economic impact, not by default assumption
⬜ Because SAFe legally requires equal treatment under the Candidate Agreement
⬜ Because Enablers should always be prioritized below every Feature

Explanation:-
Since Enablers and Features draw from the same capacity, SAFe applies consistent economic prioritization (like WSJF) across both rather than treating architecture work as automatically lower priority.
Source: https://framework.scaledagile.com/wsjf

Domain 4: PI Execution

What is a key responsibility of an Architect during PI Planning?

⬜ Writing every team’s Iteration Backlog personally
✅ Communicating architectural vision, identifying cross-team dependencies, and surfacing architectural risks that affect the draft plan
⬜ Approving the ART’s annual budget
⬜ Running the Daily Stand-up for every team

Explanation:-
Architects help teams understand the architectural context, flag dependencies between teams, and highlight risks so they can be addressed before the plan is finalized.
Source: https://framework.scaledagile.com/pi-planning

During PI Planning, multiple teams discover they depend on a shared component that isn’t ready yet. What should happen next?

⬜ Each team proceeds independently and ignores the dependency
✅ The dependency is visualized (e.g., on the program board) and addressed collaboratively, adjusting plans, sequencing, or scope as needed
⬜ The PI Planning event is canceled
⬜ Only the Release Train Engineer is told, and no plan changes are made

Explanation:-
Surfacing and visualizing cross-team dependencies during PI Planning lets the ART adjust sequencing or scope collaboratively rather than discovering the conflict mid-PI.
Source: https://framework.scaledagile.com/pi-planning

Why is identifying architectural risk during PI Planning important?

⬜ It has no real impact on the plan and is just a formality
✅ Unaddressed architectural risks can block multiple teams mid-PI, so surfacing them early lets the ART plan around or mitigate them upfront
⬜ It replaces the need for the Inspect and Adapt event
⬜ It is solely the Product Owner’s responsibility, not the architect’s

Explanation:-
Architectural risks that go unaddressed can cause significant rework or blockages later in the PI, so identifying and planning for them during PI Planning reduces disruption.
Source: https://framework.scaledagile.com/pi-planning

Which Built-In Quality dimension focuses on ensuring value moves smoothly through the system without unnecessary delays or bottlenecks?

⬜ Code Quality
✅ Flow
⬜ Release Quality
⬜ System Quality

Explanation:-
The Flow dimension of Built-In Quality is about keeping work moving smoothly across the Continuous Delivery Pipeline, minimizing hand-offs and delays.
Source: https://framework.scaledagile.com/built-in-quality/

Which Built-In Quality dimension focuses on structural integrity that can adapt as new information and feedback arrive?

⬜ Code Quality
✅ Architecture and Design Quality
⬜ Release Quality
⬜ Flow

Explanation:-
Architecture and Design Quality is about building systems that are flexible and maintainable enough to evolve as requirements and feedback change.
Source: https://framework.scaledagile.com/built-in-quality/

Which Built-In Quality dimension focuses on practices like pair programming, continuous integration, and coding standards to prevent technical debt?

⬜ System Quality
⬜ Release Quality
✅ Code Quality
⬜ Flow

Explanation:-
Code Quality covers day-to-day engineering practices — clean code, pairing, continuous integration, and coding standards — that keep the codebase healthy over time.
Source: https://framework.scaledagile.com/built-in-quality/

Which Built-In Quality dimension focuses on validating that the fully integrated system performs reliably and meets its requirements end-to-end?

✅ System Quality
⬜ Code Quality
⬜ Architecture and Design Quality
⬜ Flow

Explanation:-
System Quality is concerned with the behavior of the whole integrated system, not just individual components, including performance, security, and reliability.
Source: https://framework.scaledagile.com/built-in-quality/

Which Built-In Quality dimension focuses on ensuring that what’s released actually solves the right problem and delivers real value to customers?

⬜ Flow
⬜ Code Quality
✅ Release Quality
⬜ System Quality

Explanation:-
Release Quality ensures the released capability genuinely meets customer needs and delivers the intended value, not just that it was technically deployed successfully.
Source: https://framework.scaledagile.com/built-in-quality/

When should a team use a Spike to address an architectural unknown?

⬜ Never; Spikes are only for user-facing Feature research
✅ When there is significant uncertainty about a technical approach that needs research or a proof of concept before committing to an implementation
⬜ Only after the Feature has already been fully implemented
⬜ Only during the Innovation and Planning Iteration, never during a normal Iteration

Explanation:-
Spikes are timeboxed investigations used to reduce technical or design uncertainty before committing to a full implementation approach.
Source: https://framework.scaledagile.com/spikes

After a Spike investigating an architectural approach concludes, what typically happens next?

⬜ The findings are discarded regardless of outcome
✅ The results inform a go/no-go or design decision, and any resulting implementation work is captured as new stories or Enablers
⬜ The team must repeat the same Spike indefinitely until it produces working code
⬜ The Spike automatically becomes a released Feature with no further work

Explanation:-
A Spike’s output is knowledge that reduces risk and informs the next decision — if implementation is warranted, that work is then planned as normal stories or Enablers.
Source: https://framework.scaledagile.com/spikes

What does it mean to “shift testing left” from an architecture and quality standpoint?

⬜ Moving all testing to the very end of the Program Increment
✅ Building testing and validation (including architectural fitness checks) into development as early as possible rather than only after implementation is complete
⬜ Removing the need for automated tests entirely
⬜ Assigning all testing responsibility exclusively to a separate QA team

Explanation:-
Shifting left means catching defects and architectural issues earlier in the development process through practices like TDD and continuous validation, rather than waiting for a late testing phase.
Source: https://framework.scaledagile.com/test-driven-development/

Why does SAFe encourage automating architectural fitness checks (e.g., dependency rules, performance budgets) as part of the pipeline?

⬜ Because manual review is always more reliable than automation
✅ Because automated checks give teams fast, repeatable feedback on whether changes still comply with the intended architecture, supporting flow and quality together
⬜ Because it removes the need for any architect involvement going forward
⬜ Because it is required to pass the SAFe exam and has no practical benefit

Explanation:-
Automating architectural constraints as part of CI/CD gives teams immediate feedback when a change violates intended architecture, catching issues early instead of relying solely on periodic manual reviews.
Source: https://framework.scaledagile.com/test-driven-development/

What is a key focus of the System Demo during PI Execution from an architectural perspective?

⬜ Reviewing individual developers’ personal performance
✅ Demonstrating that the integrated system, built by multiple teams, actually works together end-to-end
⬜ Approving next year’s budget
⬜ Replacing the need for PI Planning

Explanation:-
The System Demo validates that the pieces built by different teams truly integrate and function together, which is central to verifying the architecture is holding up under real, integrated conditions.
Source: https://framework.scaledagile.com/continuous-delivery-pipeline

During an Iteration Review, a team’s demoed Feature technically works but doesn’t follow agreed architectural conventions. What should happen?

⬜ Ignore it since the Feature technically works
✅ Raise the concern so the team and architect can address the deviation, protecting the health of the shared Architectural Runway
⬜ Cancel the Iteration Review immediately
⬜ Wait until the next Program Increment to mention it

Explanation:-
Even working functionality can create long-term problems if it deviates from the agreed architecture, so deviations should be surfaced and addressed promptly to protect runway health.
Source: https://framework.scaledagile.com/agile-architecture

How should an architect typically coach teams during PI Execution to keep code aligned with the intended architecture without becoming a bottleneck?

⬜ By personally reviewing and approving every single commit
✅ By sharing architectural guidance, guardrails, and context so teams can make good day-to-day decisions themselves, checking in periodically rather than gating every change
⬜ By avoiding any communication with teams once PI Planning ends
⬜ By requiring teams to submit written requests for every technical decision

Explanation:-
Effective architects enable teams with shared context and lightweight guardrails so decisions can be made quickly and consistently, rather than becoming a centralized approval bottleneck.
Source: https://framework.scaledagile.com/agile-architecture

How should the Architectural Runway typically be adjusted based on feedback gathered during PI Execution?

⬜ It should never change once PI Planning is complete
✅ It should be refined and extended incrementally based on what teams actually learn and need as they build, rather than treated as a fixed, one-time plan
⬜ It should be discarded and rebuilt from scratch every Iteration
⬜ It should only be updated once per year

Explanation:-
Architecture in SAFe is meant to evolve incrementally — execution feedback should inform ongoing adjustments to the runway rather than treating the original plan as fixed.
Source: https://framework.scaledagile.com/architectural-runway

Domain 5: Leading during a Lean-Agile Transformation

What is a key part of an Architect’s role in leading a Lean-Agile transformation?

⬜ Enforcing a single fixed technical design across the enterprise indefinitely
✅ Acting as a change agent who helps shift the organization’s mindset and technical practices toward Lean-Agile ways of working
⬜ Avoiding involvement in any organizational change efforts
⬜ Delegating all coaching responsibilities to the Release Train Engineer

Explanation:-
Architects often serve as influential change agents, helping the organization adopt Lean-Agile principles alongside the technical transformation.
Source: https://framework.scaledagile.com/agile-architecture

How should an architect balance providing intentional architectural guidance with avoiding becoming a bottleneck for teams during a transformation?

⬜ By making every technical decision personally to ensure consistency
✅ By providing lightweight guardrails and shared principles, then trusting and coaching teams to make good decisions within them
⬜ By refusing to provide any guidance at all
⬜ By requiring written sign-off from the architect before any code is committed

Explanation:-
Effective architects during a transformation enable team autonomy through shared context and guardrails rather than trying to control every decision centrally.
Source: https://framework.scaledagile.com/agile-architecture

Why might an organization encourage decentralized technical decision-making with light architectural guardrails during a Lean-Agile transformation?

⬜ Because centralized decision-making always scales better
✅ Because decisions made by those closest to the work, within shared guardrails, tend to be faster and better-informed than decisions forced through a central bottleneck
⬜ Because it removes all need for an Architectural Runway
⬜ Because guardrails eliminate the need for any coordination

Explanation:-
Decentralizing decisions to the people with the most context, while keeping enough shared guardrails to maintain coherence, speeds up flow without sacrificing alignment.
Source: https://framework.scaledagile.com/agile-architecture

What is the value of a Community of Practice (CoP) for architects during a transformation?

⬜ It replaces the need for individual architects on ARTs
✅ It gives architects and technical practitioners across the organization a forum to share standards, patterns, and lessons learned
⬜ It exists solely to plan social events
⬜ It formally disciplines underperforming teams

Explanation:-
A CoP lets architects and other practitioners exchange knowledge and align on shared practices across teams and ARTs, supporting consistency without heavy central control.
Source: https://framework.scaledagile.com/agile-architecture

How does the mindset of a Lean-Agile technical leader typically differ from a traditional “gatekeeper” architect?

⬜ There is no meaningful difference
✅ A Lean-Agile technical leader focuses on enabling and coaching teams toward good decisions, rather than being the sole approver of every technical choice
⬜ A Lean-Agile technical leader has no involvement in technical direction at all
⬜ A Lean-Agile technical leader only communicates through written approval forms

Explanation:-
The shift is from being a control point that approves every decision to being an enabler who equips teams with context, principles, and coaching so they can decide well themselves.
Source: https://framework.scaledagile.com/agile-architecture

How should an architect approach leading architecture evolution across the enterprise during a transformation?

⬜ By mandating one big redesign completed all at once before any new Features can be built
✅ By guiding incremental evolution of the Architectural Runway in step with business priorities and team learning
⬜ By avoiding any architectural change until the transformation is fully complete
⬜ By letting every team redesign independently with no shared direction

Explanation:-
Consistent with Agile Architecture principles, leading evolution incrementally — extending the runway in step with real business needs and learning — avoids both stagnation and disruptive, all-at-once redesigns.
Source: https://framework.scaledagile.com/architectural-runway