Practice architecture assessment vocabulary used in technical due diligence: single points of failure, scalability ratings, API versioning risk, and architecture scorecards.
0 / 13 completed
1 / 13
A due diligence report states 'the architecture has a single point of failure in the payment module'. What does SPOF mean?
A Single Point of Failure (SPOF) is a component without redundancy — if it goes down, the whole system or a critical function fails. In due diligence, a SPOF in a critical module like payments is a significant risk because it means one failure can cause total revenue loss. Acquirers look for redundancy, failover mechanisms, and disaster recovery plans.
2 / 13
'We rate the scalability as limited — the monolith needs refactoring.' What scalability concern does a monolith present?
Monolithic architectures scale less efficiently than microservices because you must scale the entire application even if only one component is under load. For due diligence, a 'scalability limited' rating signals that significant re-architecture investment is needed before the system can handle growth — this is a cost and risk that affects the acquisition valuation.
3 / 13
'The API layer is not versioned — breaking change risk.' Why is API versioning important?
API versioning (/v1/, /v2/) allows the API to evolve without breaking existing consumers. Without versioning, every change that modifies a response format or removes a field is a breaking change that can break downstream integrations immediately. In due diligence, missing versioning signals technical risk — any future change requires coordinating all consumers simultaneously.
4 / 13
What is an 'architecture scorecard' in due diligence?
An architecture scorecard is a structured way to evaluate and communicate architecture quality during due diligence. Each dimension is rated (e.g., Green/Amber/Red or 1-5) with specific evidence. It allows acquirers to compare multiple acquisition targets consistently and understand where investment is needed post-acquisition.
5 / 13
During due diligence, an assessor says 'the system has no observability layer'. Why is this a risk?
Observability (metrics, distributed tracing, structured logging) is critical for operating a system reliably. Without it, diagnosing production incidents takes much longer, engineering teams operate 'blind', and making confident changes becomes risky. In due diligence, missing observability is flagged as technical debt requiring investment post-acquisition.
6 / 13
Sarah (Senior Architect) posted this in Slack: 'The new microservice for user authentication is a complete black box. We have zero visibility into its logs or metrics.' What does Sarah likely mean when she describes the authentication service as a 'black box'?
'Black box' in this context refers to a system where the internal workings are hidden and inaccessible. Sarah's concern isn't about performance or complexity itself, but rather the *lack* of tools for observing and understanding the service's behavior – critical for troubleshooting and maintaining reliability. This absence of observability presents significant risks.
7 / 13
Mark (Lead Developer) left this comment on a code review: 'This function directly accesses the database without any abstraction layer. It's tightly coupled and makes testing extremely difficult.' What architectural concern is Mark highlighting in his comment?
Mark's comment focuses on the detrimental effect of direct database access – tight coupling. This means changes to the database schema or underlying logic would require modifying this function directly, creating a fragile system that is difficult to test and prone to introducing bugs. Architectural concerns like scalability are secondary to this fundamental problem.
8 / 13
You're reviewing the PR description for a new feature: 'The system now integrates with a third-party payment gateway. The API response is JSON formatted and includes transaction details.' What aspect of architectural assessment should be considered regarding this integration?
While PCI DSS compliance is important (option 1), the primary architectural assessment concern here relates to the integration with a third-party payment gateway. Reliability – specifically, the gateway's ability to handle transaction volume and potential failures – is paramount for any financial system. The API response format is relevant but secondary to the overall dependency risk.
9 / 13
Emily (Architect) writes in a documentation section: 'The application's architecture emphasizes loose coupling between services. Each service is responsible for a single business capability and communicates via well-defined APIs.' What architectural pattern does Emily describe?
Emily's description clearly aligns with the principles of microservices. The emphasis on single business capabilities, well-defined APIs, and loose coupling are all hallmarks of this architectural pattern. Event-driven communication is a common implementation strategy for microservices but isn't the core definition itself.
10 / 13
David (a DevOps Engineer) sends this Slack message: 'Our new CI/CD pipeline is completely unaware of the service architecture. It just deploys code to production without any checks on resource usage or dependencies.' What architectural principle does David's message suggest is missing?
David highlights the absence of observability. Observability refers to the ability to monitor and understand the behavior of a system – in this case, its resource usage and dependencies. Without it, you can't detect performance bottlenecks, identify errors, or ensure that deployments are successful. The other options relate to specific CI/CD practices but don't directly address the core issue of understanding the system's architecture.
11 / 13
During a standup meeting, John (Developer) says, 'We're migrating the reporting service to a serverless architecture. It's stateless and scales automatically based on demand.' What does 'stateless' mean in this context regarding the reporting service's architecture?
'Stateless' in this scenario refers to the reporting service not storing any client-specific data between requests. This is crucial for scalability because each request can be handled independently without needing to consult a session or previous state – allowing it to scale efficiently based on demand. Options A and D are incorrect as they describe features that would hinder scaling.
12 / 13
John (DevOps) sent this Slack message: 'The new deployment pipeline doesn't monitor the system's memory usage. We're seeing sporadic performance degradation, but it's hard to pinpoint the root cause.' What architectural concern does John's statement highlight regarding the application's architecture?
This situation demonstrates a lack of observability. Observability—metrics, logs, and traces—is crucial for understanding system behavior and diagnosing issues. Without monitoring memory usage, it's impossible to proactively identify performance degradation, highlighting the architectural concern of insufficient operational visibility.
13 / 13
Maria (Lead Developer) is reviewing a PR and comments: 'This service uses direct database access. It's tightly coupled to the data layer and makes testing incredibly difficult.' What architectural principle is Maria primarily criticizing?
Maria is pointing out the lack of data abstraction. Data abstraction separates the application's business logic from its underlying database implementation, promoting maintainability and testability by allowing changes to the database without impacting the core application code. This directly addresses the principle of decoupling.
What does this Technical Due Diligence Language exercise cover?
This exercise, "Architecture Assessment Vocabulary", tests your understanding of technical due diligence language vocabulary and phrasing through 13 multiple-choice questions drawn from real workplace scenarios.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 13 questions. Each one presents a realistic sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Who is this Technical Due Diligence Language exercise for?
It's designed for IT professionals and learners who want to sound natural discussing technical due diligence language topics in English — useful for meetings, documentation, interviews, and day-to-day communication with English-speaking teams.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more Technical Due Diligence Language exercises?
Browse the full Technical Due Diligence Language exercises hub for more practice, or explore other exercise categories covering vocabulary, grammar, interviews, and workplace communication.