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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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