Free Solutions Architect Practice Assessment (2026)

Cohesyve · Practice for candidates

Going for a Solutions Architect role? Find out how you'd actually score.

Run a Solutions Architect simulation built the same way employers build theirs, and get a full report showing exactly where you lost marks — before it counts.

free assessments a month

no card required

Full

scored report every run

Every

question type included

5 free assessments a month · No card required · Pro from $16/mo

Overview

A solutions architect assessment sits between technical design and commercial judgement. You are given a customer or business problem, a set of constraints, and often an existing system you have to work with rather than replace, and asked to produce a solution and explain it to two audiences at once. The exercises test integration thinking and stakeholder communication as much as architecture. This page sets out what to expect.

Why employers assess this role

Solutions architects commit organisations to build effort and to integration surfaces that persist for years, and a design that ignores a commercial constraint or a legacy system is usually discovered only after work has started. Employers assess up front because the role sits between engineering and the business, and fluency in one of those languages without the other is not visible on a CV.

What gets tested

Requirements elicitation and clarifying the briefEnd-to-end solution design across systemsIntegration patterns and data flow designBuild, buy and reuse evaluationNon-functional requirements — scale, availability, securityTrade-off analysis against cost and timelineStakeholder communication across technical and business audiencesRisk identification and phased delivery planning

The format

Duration

60–120 minutes

Question types

Solution design from a business brief
Integration design between named systems
Build versus buy evaluation with a recommendation
Stakeholder explanation or objection-handling exercise

Levels

Entry · Mid · Senior

What you'll be asked to do

Turn a business problem into a design

The brief is written in business language and is deliberately incomplete. Assessors watch for the questions you ask before you start drawing.

•Design a solution for a company that wants a single customer view across three systems
•Propose an approach for a business that needs to onboard partners faster
•Translate a vague request for reporting into a defined data and interface design

Design the integration

How the parts talk to each other, and what happens when one of them is unavailable. This is where most of the technical marks sit.

•Integrate an order system with a finance package that only accepts nightly file imports
•Choose between synchronous calls and an event-driven approach and defend it
•Define how the solution behaves when a downstream system is down for six hours

Evaluate build against buy

A recommendation with reasoning, not a preference. Assessors look for total cost, lock-in, fit and delivery speed being weighed against each other.

•Recommend whether to build a bespoke workflow engine or configure a commercial product
•Assess whether an existing internal component should be reused or replaced
•Compare two vendor options against stated functional and commercial criteria

Explain it to stakeholders

A written or spoken section aimed at a non-technical audience, often with an objection to handle. Frequently underestimated and heavily weighted.

•Summarise the recommendation in a page for a finance director who is worried about cost
•Respond to an engineering objection that the design is over-complicated
•Explain what the business gets at the end of phase one and what it does not

Cohesyve for candidates

Practise a Solutions Architect assessment before the real one

Run the same AI job simulations companies use to evaluate applicants. You get a scored report showing where you're strong and where you're not, plus what to work on.

Sample tasks — and what strong looks like

A retailer wants online and in-store stock to show the same numbers. The store system updates twice a day and cannot be changed. Design a solution.

Mid

What strong looks like: Accepts the constraint rather than designing around a change that cannot happen, is explicit about the staleness window and how it is communicated to customers, and proposes a mechanism such as reservation or buffering to manage the risk of overselling. Weak answers assume real-time integration and quietly ignore the stated limitation.

The business wants a customer portal delivered in three months. Your assessment is that the full scope needs six. Set out your recommendation.

Senior

What strong looks like: Proposes a phased delivery with a genuinely useful first release, states plainly what is deferred and what the consequence is, and gives the business a decision to make rather than either a flat refusal or an agreement that will fail later. Weak answers either promise the date or reject it without offering an alternative.

Two internal teams have each built a customer record store. You are asked to design the single source of truth.

Senior

What strong looks like: Establishes ownership and the system of record before designing anything technical, addresses reconciliation of conflicting existing records, defines the migration path for both consumers, and names the organisational agreement required for the design to hold. Weak answers draw a new central database and treat the political problem as out of scope.

Explain a proposed event-driven integration to a stakeholder who asks why it cannot just be a nightly export.

Mid

What strong looks like: Answers in business terms — what changes for customers and operations, what it costs, what risk it removes — concedes where the nightly export is genuinely adequate, and does not retreat into technical vocabulary. Weak answers assert that the approach is modern or best practice without connecting it to anything the stakeholder cares about.

How to prepare

#1
Practise starting every design with the clarifying questions you would ask, because assessments deliberately withhold information and the questions themselves are scored.
#2
Rehearse writing a one-page recommendation for a non-technical reader, as this section carries surprising weight and is where technically strong candidates most often lose ground.
#3
Work through integration scenarios involving a system that cannot be changed, since real briefs almost always contain one and idealised designs are marked down.
#4
Build the habit of naming what happens when each dependency fails, including the manual fallback, because availability reasoning distinguishes mid from senior submissions.
#5
Practise phasing a design into deliverable stages with a clear statement of what each phase does and does not provide.
#6
Run one complete timed exercise covering design, recommendation and stakeholder explanation, because the communication section is the one people leave unfinished.

Common mistakes

Designing the ideal solution and ignoring the budget, timeline or legacy constraint in the brief.
Recommending a technology without connecting it to a business outcome the stakeholder cares about.
Skipping the clarifying questions and building on assumptions that are never stated.
Treating build versus buy as a preference rather than an evaluation against criteria.
Designing only the happy path with no answer for a dependency being unavailable.
Writing the stakeholder summary in the same technical register as the design document.

How it's scored

Criterion	What strong looks like
Requirements understanding	The real problem is separated from the requested solution, gaps in the brief are surfaced as explicit questions or stated assumptions, and the design answers what the business actually needs.
Technical soundness	Integration points, data flow and failure behaviour are defined, and non-functional requirements are addressed rather than listed.
Trade-off reasoning	Options are compared against stated criteria including cost, time and lock-in, and a clear recommendation is made rather than a menu offered.
Deliverability	The solution is phased, risks are named with mitigations, and the first release is something the business could genuinely use.
Stakeholder communication	The same solution is explained convincingly to a technical and a business audience, with objections answered directly rather than deflected.

Frequently Asked Questions

How is this different from a cloud architect assessment?

Cloud architect exercises weight infrastructure design, cost and resilience most heavily. Solutions architect exercises weight requirements, integration across existing systems and stakeholder communication, and often include a commercial recommendation.

Will I have to present my design live?

Often, at the later stages. Many assessments include a written design followed by a short presentation or objection-handling conversation, and the ability to defend a choice without becoming defensive is part of what is scored.

How much detail should the design contain?

Enough that a delivery team could start — components, interfaces, data flow, failure behaviour — but not implementation-level detail. Going too deep too early is a common way to run out of time before the recommendation section.

What if I disagree with the premise of the brief?

Say so, with reasoning, and then answer the question anyway. Challenging a flawed premise constructively scores well; refusing to engage with the exercise does not.

Is it worth practising one of these before the real thing?

It is, particularly the written recommendation, which is rarely something people practise. Cohesyve includes five free scored assessments each month with a full report, so you can see how your design and your explanation are marked separately.

Practise another role

Cohesyve · Practice for candidates

Practise a Solutions Architect assessment now — free.

Five scored assessments a month, a full report on every run, and a learning pathway built from what you got wrong. No card required.