All jobs / Solutions / cloud architect
Architecture Governance interview questions
Architecture Governance questions a Solutions / cloud architect can be asked, from first job to senior. Open one to see the strongest answer and why it works.
What belongs in an architecture decision record, and what does not?
The strongest answer: The context and constraints, the options considered, the decision and its consequences, and its status; not a design document, not a tutorial, and not a defence of the winner alone
Why it works: Exactly. Context, options, decision, consequences, status. Short, and honest about what was rejected.
- Context and constraints.
- Options considered, including rejected ones.
- Decision and consequences.
- Status, so it can be superseded.
A customer requires that their data stays in their country. What does that change in the architecture?
The strongest answer: Where data is stored and processed, including backups, logs, analytics copies and support access — you map every place the data flows before promising anything
Why it works: Exactly. Residency is about every copy and every processor, not the primary database alone.
- Map every place the data flows.
- Backups, logs and analytics count.
- Support access counts too.
- Encryption is not residency.
Procurement has given you six weeks to recommend an identity provider.
How do you run a fair selection between three vendors for a critical platform component?
The strongest answer: Write weighted criteria from the requirements before seeing demos, run the same proof of concept with each, include exit cost and operational fit, and record the decision with its reasoning
Why it works: Exactly. Criteria before demos, identical trials, exit cost counted, decision recorded.
- Weighted criteria before demos.
- Same proof of concept for each.
- Count exit cost and operations.
- Record the decision.
The same class of incident keeps recurring across different teams. What does the architect do?
The strongest answer: Read the reviews together to find the shared cause — a missing platform capability, a default, a pattern — fix it once at the platform or standard level, and track whether the class disappears
Why it works: Exactly. Systemic causes need systemic fixes, then evidence that they worked.
- Find the shared cause across reviews.
- Fix at the platform or standard level.
- Prefer defaults over documents.
- Track whether the class disappears.
The company is adding card payments to a product that has never handled regulated data.
The platform handles regulated payment data alongside ordinary product data. How do you shape the architecture?
The strongest answer: Draw the compliance boundary as small as possible around the regulated data and the systems that touch it, tokenise or reference it outside that boundary, and make the boundary visible in network, identity and deployment
Why it works: Exactly. A minimal, visible boundary; references outside it; controls concentrated inside it.
- Smallest possible boundary.
- Tokenise outside it.
- Boundary visible in network, identity, deploys.
- Outsourcing shrinks, not removes.
What is an architecture review board for, and what makes one harmful?
The strongest answer: To catch cross-team risk early, share context and keep a small set of standards coherent; it turns harmful when it becomes a gate every change must pass, reviews late, or decides instead of advising
Why it works: Exactly. Early, advisory, focused on cross-team risk; not a gate, not late, not a throne.
- Catch cross-team risk early.
- Advise, do not gate.
- Keep a small set of standards coherent.
- Late review is theatre.
How do you keep architecture decisions discoverable across fifty teams?
The strongest answer: A common ADR template and location per team, a lightweight index of decisions that cross team boundaries, superseding rather than editing, and linking ADRs from the code and the diagrams they shape
Why it works: Exactly. Local by default, indexed where it crosses teams, immutable history, linked from the artefacts.
- Common template, local location.
- Index cross-team decisions.
- Supersede; never edit history.
- Link from code and diagrams.
How do you decide what belongs in a shared platform and what stays with product teams?
The strongest answer: Platform owns what many teams need the same way and would build worse alone — identity, deploy, observability, data access patterns; product teams own what differentiates; the platform is a product with users, not a mandate
Why it works: Exactly. Common, undifferentiated, better done once — offered as a product teams want to use.
- Common needs, done once, done well.
- Differentiation stays with products.
- Platform is a product with users.
- Adoption, not mandate.
How do you write a target architecture that teams will actually move towards?
The strongest answer: Describe a small number of principles and the few target states that matter, show the current state honestly, define the next two or three steps with owners, and revisit it quarterly — not a diagram of a finished world
Why it works: Exactly. Principles, honest current state, near-term owned steps, regular revision.
- Few principles, few target states.
- Honest current state.
- Next steps with owners.
- Revisit quarterly.
Customers in several jurisdictions each demand their data stays local. How do you architect for that without one platform per country?
The strongest answer: A cell-based design: shared control plane with no customer data, regional data planes holding their tenants’ data, routing by tenant home, and strict rules for what may cross — with the residency status of every data flow documented
Why it works: Exactly. Control plane shared, data planes regional, flows classified.
- Shared control plane, no customer data.
- Regional data planes.
- Route by tenant home.
- Classify every cross-region flow.
How do you keep an architecture from drifting once the architects move on to the next thing?
The strongest answer: Encode the properties that matter as automated checks — dependency rules, latency budgets, cost thresholds, security policies — that run in the pipeline and fail loudly, alongside periodic reviews of what the checks do not cover
Why it works: Exactly. Executable architecture: the checks hold the line while people move.
- Encode properties as automated checks.
- Run them in the pipeline.
- Fail loudly.
- Review what the checks miss.
How do you design so that a compliance audit is a report, not a project?
The strongest answer: Make the controls part of the platform — access through identity with logs, changes through reviewed pipelines, configuration as code, evidence collected automatically — so the audit reads what the system already records
Why it works: Exactly. Controls in the platform, evidence as a by-product.
- Controls built into the platform.
- Identity, pipelines and config as code.
- Evidence collected automatically.
- The audit reads what already exists.
The acquired company runs on a different cloud with its own identity provider and a product that overlaps yours by half.
Your company has acquired a competitor with an overlapping product. What is the architecture plan for the first ninety days?
The strongest answer: Inventory both estates, secure identity and access first, keep both products running, decide the target for each overlapping capability on business grounds, and integrate at the data and identity edges before touching cores
Why it works: Exactly. Know what you have, secure it, keep the lights on, decide per capability, integrate at the edges.
- Inventory both estates.
- Identity and access first.
- Decide per capability, on business grounds.
- Integrate edges before cores.
Teams want autonomy over their stacks; leadership wants consistency. Where do you draw the line?
The strongest answer: Standardise the seams — identity, observability, deployment, data contracts, security baselines — and leave the interior of each service to the team; a short list of golden paths with a documented way to deviate
Why it works: Exactly. Consistent seams, free interiors, paved paths with a deviation process.
- Standardise the seams.
- Free the interiors.
- Golden paths, not mandates.
- A documented way to deviate.
A reporting system from a previous era still receives nightly data feeds; the team that built it left years ago.
How do you retire a system that “everyone uses” but nobody owns?
The strongest answer: Measure who actually uses it and for what, find or build the replacement for each real use, give dates and migration help, remove access in stages, and archive the data with a retention decision — decommissioning is a project with a sponsor
Why it works: Exactly. Measure, replace, communicate, stage, archive, sponsor.
- Measure real usage.
- Replace each real use.
- Stage the removal.
- Archive with a retention decision.