All jobs / Solutions / cloud architect
Architecture Fundamentals interview questions
Architecture Fundamentals questions a Solutions / cloud architect can be asked, from first job to senior. Open one to see the strongest answer and why it works.
A senior says “that is a trade-off” in a design review and moves on. The junior asks you what was meant.
What does “that is a trade-off” actually mean, and what is the next sentence?
The strongest answer: We gain something and give up something; the next sentence names both and says which the requirement values more
Why it works: Exactly. Name the gain, name the cost, tie the choice to a requirement. That is the whole job.
- Name what you gain.
- Name what you give up.
- Tie the pick to a requirement.
- Then decide — do not park it.
A stakeholder says “we need a reporting feature”. How do you turn that into functional requirements you can design against?
The strongest answer: Ask who uses it, for which decisions, with what data and how often; write each as a concrete behaviour with an example, and agree what is out of scope
Why it works: Exactly — functional requirements are observable behaviours with examples and a scope line, not a feature name.
- Behaviours, examples, scope.
- Ask who, what data, how often.
- Write each as an observable behaviour.
- Agree what is out of scope.
The brief says “it must be fast and reliable”. What do you do with that sentence?
The strongest answer: Turn it into numbers and conditions with the stakeholder — response time at what load, tolerated downtime per month, what happens on failure — before drawing anything
Why it works: Exactly. Adjectives become measurable constraints, agreed with the person who wrote them.
- Adjectives become numbers.
- Agree them with the stakeholder.
- Include failure behaviour, not only speed.
- Do this before the first box.
What are non-functional requirements, and why do architects spend so much time on them?
The strongest answer: Qualities the system must have — performance, availability, security, cost, operability — rather than features; they shape the structure more than any single feature does
Why it works: Exactly. Features decide what the system does; qualities decide how it is built.
- Qualities, not features.
- They shape the structure.
- Write them down and make them testable.
- Not a phase after the features.
You recognise a textbook architecture pattern that seems to fit a new problem. What do you check before applying it?
The strongest answer: That the problem has the same forces the pattern was made for, what the pattern costs in complexity and operations, and whether a simpler structure meets the requirement
Why it works: Right — a pattern is a named trade-off; it pays only when its forces are present and its cost is justified.
- A pattern is a named trade-off.
- Match the forces, not the name.
- Price its complexity.
- Try the simpler structure first.
Security, performance, cost and time to market all “matter”. How do you decide which quality attributes the architecture optimises for?
The strongest answer: Get the stakeholders to rank them against each other using concrete scenarios, record the ranking, and settle every later trade-off against it — you cannot maximise all of them
Why it works: Exactly — an explicit, agreed ranking is what turns “it depends” into consistent decisions.
- Rank the qualities explicitly.
- Use concrete scenarios.
- Get the ranking agreed and written.
- Settle trade-offs against it.
Classic layered architecture versus ports-and-adapters (hexagonal): what does the second one buy you?
The strongest answer: Dependencies point inward: the domain logic knows nothing about the database, web framework or broker, so those can be swapped or faked and the core is tested without infrastructure
Why it works: Right — the point is the direction of dependencies, which makes the core testable and the infrastructure replaceable.
- Dependencies point at the domain.
- Domain knows no framework or database.
- Infrastructure implements the ports.
- Test the core without infrastructure.
A new team inherits a system whose wiki has two hundred pages and three different architecture diagrams.
What architecture documentation do you keep for a system, and how do you stop it going stale?
The strongest answer: A small set — context and container diagrams, the decision records and the runbook — kept next to the code, reviewed in the same pull requests as the change, dated, and generated wherever a tool can generate it
Why it works: Exactly — few artefacts, owned like code, with a date on each; staleness is a review problem, not a tooling problem.
- Few artefacts, owned like code.
- Context, containers, decisions, runbook.
- Review docs in the same PR.
- Date it; generate what you can.
When do you build a component in-house rather than buy or adopt one?
The strongest answer: When it is core to how you differentiate and you will keep investing in it; for everything else buy or adopt, and count the ongoing ownership cost of building, not just the first version
Why it works: Exactly. Differentiation and sustained investment justify building; ownership cost is the real number.
- Build what differentiates you.
- Buy or adopt the rest.
- Count ongoing ownership cost.
- Excitement is not a criterion.
Product cannot say whether the platform will be sold as multi-tenant SaaS or as single-tenant installs; the data model choice differs.
Two options are viable and you cannot know for a year which requirement will dominate. How do you decide?
The strongest answer: Sort by reversibility: make the cheap-to-reverse call now and the expensive one only when you must, keep the interface neutral meanwhile, and set a date or trigger to revisit
Why it works: Right — the skill is telling one-way doors from two-way doors and spending decision effort accordingly.
- Reversible fast, irreversible late.
- Name the one-way doors.
- Keep the interface neutral meanwhile.
- Set a trigger to revisit.