Search the practice set
126 questions, 454 terms and 400 topics in 20 areas.
47 results for “Code Review”
Architecture Review Board
A forum that reviews significant designs against standards, risks and strategy before commitment.
Authorization Code Flow with PKCE
The OAuth flow recommended for all client types, in which an authorisation code is exchanged for tokens using a proof key that binds the exchange to the original requester.
Infrastructure as Code
Defining infrastructure in version-controlled declarative files that a tool reconciles against the real environment.
Policy as Code
Expressing governance rules as executable code evaluated automatically, so compliance is prevented at creation rather than reported after the fact.
Well-Architected Review
A structured self-assessment of a workload against defined pillars — operational excellence, security, reliability, performance, cost, and sustainability.
Application Performance Monitoring
Instrumentation inside the application that attributes latency and errors to specific code paths, queries and dependencies.
Architecture Trade-off Analysis Method
A structured evaluation that scores an architecture against prioritised quality-attribute scenarios and identifies the points where those attributes conflict.
Blameless Postmortem
An incident review that seeks the systemic conditions that made a failure possible, explicitly excluding individual fault.
C4 Model
A set of four nested diagram levels — context, container, component, code — that keeps each diagram at one consistent level of abstraction.
Clean Architecture
Concentric layers with a strict dependency rule — source code dependencies point only inwards, towards higher-level policy.
Configuration Drift
Divergence between the infrastructure described in code and the infrastructure actually running, usually caused by manual changes.
Edge Function
Code executed at a CDN point of presence close to the user, in a constrained, fast-starting runtime, typically to modify or route a request before it reaches an origin.
Failure Thinking
Making "what happens when this fails?" a standing question applied to every component and every dependency in a design.
Feature Flag
A runtime switch that decouples deploying code from releasing behaviour, so unfinished or risky work can ship dark.
Human in the Loop
Requiring human review or approval at a defined point in an automated flow, chosen by the reversibility and cost of the action.
Layered Architecture
Organising code into horizontal layers — presentation, application, domain, data — where each layer may only call the one beneath it.
OWASP Top Ten
A periodically updated consensus list of the most critical web application security risks, useful as a design-review checklist.
Observability
The property of being able to answer new questions about a system's internal state from its external outputs, without shipping new code.
Presenting to Engineers
Presenting a design at the level of mechanism, including the alternatives rejected and the parts you are still unsure about.
Refactoring
Changing the internal structure of code without changing its external behaviour, in small verified steps.
SOLID
Five object-oriented design principles — single responsibility, open/closed, Liskov substitution, interface segregation, dependency inversion.
STRIDE
A mnemonic for six threat categories — spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege — walked across each component and data flow.
Secrets Management
Storing, distributing, rotating and auditing credentials so that they never live in code, images or configuration files.
Technical Proposal
A written argument for a course of action, circulated for review before the work starts, structured so that disagreement surfaces early and cheaply.
Terraform State
The file mapping declared resources to real infrastructure, without which the tool cannot tell what it already created — and which becomes critical infrastructure in its own right.
Threat Modelling
A structured exercise that identifies what can go wrong with a design, before it is built, by walking the system's trust boundaries.
A design review presents a new event-driven platform. What cost questions do you ask before approving it?
What the interviewer is testing Whether cost is part of your architecture review or an afterthought handled by finance later, and whether you know the specific
In a design review, a respected senior engineer proposes an approach you believe is wrong. The room defers to them. How do you handle it?
What the interviewer is testing Whether you can be effective without authority, which is most of the architect's job. It is also testing whether you assume you
You are reviewing a design for an internal tool with 200 users. It proposes Kubernetes, microservices, Kafka, a service mesh and CQRS. How do you handle the review?
What the interviewer is testing Judgement, and whether you can push back without alienating a team. Anyone can spot over engineering; the question is what you d
Your services currently trust anything inside the VPC. A security review says move to zero trust. What changes, and what will it cost you?
What the interviewer is testing Whether "zero trust" is a concrete set of changes to you, or a slogan. What actually changes Workload identity. Every service ge
A table has 14 indexes and writes have become slow. How do you decide which to remove?
The approach 1. Get usage statistics, not opinions. Every major engine reports index scan counts — PostgreSQL's pg stat user indexes , SQL Server's sys.dm db in
A team shows you a design with eight services. Without knowing the domain, what questions tell you whether the boundaries are right?
What the interviewer is testing Whether you can evaluate a structure from its properties rather than needing to be a domain expert in every system you review. T
Half your production changes are made through the console during incidents. The IaC repository no longer matches reality. What do you do?
Why this matters beyond tidiness The code has stopped being a description of reality, which removes the properties it was adopted for: the ability to recreate a
You are reviewing a new public API before launch. What do you check, in priority order?
1. Object level authorization — check this first, on every endpoint The most common serious API vulnerability. For each endpoint accepting an identifier, verify
Code Review
Where architectural rules are enforced by people rather than by tools.
Architecture Review Boards
Thresholds, early engagement and a real route to accept deviation.
Infrastructure as Code
Declarative infrastructure, drift, state files and rebuild-from-empty.
Application Performance Monitoring
Attributing latency to code paths, queries and dependencies.
Architecture Governance
Preventive, automated controls rather than review meetings.
C4 Model
Context, container, component and code as four separate diagrams.
Decision Practice
Thresholds, review, supersession and keeping the log alive.
Design Patterns
Reusable solutions at code level, and when they become ceremony.
Documentation Practice
Keeping documents close to the code and honest about staleness.
FinOps Practice
Inform, optimise, operate — and cost as a design-review criterion.
Identity & Access Management
Workload identity, roles, permission boundaries and usage-based review.
Network Performance
Latency floors, bandwidth-delay product, and what no code change fixes.
Schema Registry
Enforcing compatibility on events the way CI enforces it on code.