Practice technical risk vocabulary for due diligence: risk classification, disaster recovery gaps, test coverage, legacy dependencies, and deal-breaker vs. manageable risk framework.
0 / 10 completed
1 / 10
A due diligence report classifies a finding as 'high risk: no disaster recovery plan'. What does this mean?
A missing disaster recovery (DR) plan means the company has no tested procedure for restoring operations after a major failure (data centre outage, data corruption, cyberattack). This is high risk for acquirers because a post-acquisition incident could cause major financial and reputational damage, and building a DR capability requires significant investment.
2 / 10
'Medium risk: 80% test coverage but no integration tests.' Why are integration tests important despite high unit test coverage?
High unit test coverage provides confidence that individual functions work correctly in isolation. But many production bugs occur at integration points — between services, at database boundaries, or in API contracts. A system with no integration tests may work perfectly in unit tests but fail when components are assembled together in production.
3 / 10
'The legacy dependency is unsupported.' Why is an unsupported dependency a technical risk?
An unsupported dependency is one where the original maintainer has stopped providing updates, security patches, or bug fixes. This means: known CVEs will remain unpatched, compatibility issues with future platform updates will be unresolved, and the dependency becomes a growing liability over time. Replacing it requires refactoring — which is a cost and schedule risk.
4 / 10
In the risk classification framework, what distinguishes a 'deal-breaker' risk from a 'manageable' risk?
Risk classification helps acquirers make informed decisions: deal-breaker risks (e.g., unresolvable IP issues, active data breaches, hidden liabilities) may cause the acquirer to walk away or dramatically reprice the deal. Manageable risks are real but addressable — they inform the integration plan and may adjust the purchase price but don't invalidate the acquisition.
5 / 10
'We classify risks as deal-breaker, manageable, or acceptable.' What does 'acceptable' mean in this context?
An acceptable risk is one that falls within the acquirer's normal risk tolerance — it's acknowledged, documented, and monitored, but doesn't require specific mitigation. For example, 'the tech stack uses a framework version that is 2 years behind the latest release' may be acceptable if there's no active CVE. The three-tier classification (deal-breaker/manageable/acceptable) helps focus due diligence effort on the risks that matter most.
6 / 10
Sarah (Senior Developer) comments on a PR draft: 'This uses the deprecated `AuthClient` – that's flagged as high risk due to potential future API changes. We should seriously consider migrating.' What is Sarah primarily expressing regarding the use of the `AuthClient`?
Sarah is highlighting a potential problem – the `AuthClient` is deprecated. This means there's a risk of future API changes breaking the code relying on it, necessitating migration. The core concern isn't just efficiency but the *stability* and maintainability of the system due to this outdated component; options A, C, and D misinterpret the urgency of the situation.
7 / 10
Mark (DevOps Engineer) sends a Slack message: 'Just noticed the deployment pipeline is failing intermittently. Logs show intermittent connection timeouts to the staging database server – we've seen this before with older versions of our data migration scripts.' What technical risk does Mark's message suggest?
Mark's message points to the risk associated with legacy components – specifically, older data migration scripts. These often have compatibility issues or bugs that surface under specific load conditions, leading to intermittent failures as seen in the timeouts. Options A and B focus on different types of problems; C is a related but less precise description of the immediate issue.
8 / 10
A due diligence report identifies 'Moderate Risk: Significant reliance on third-party library `X` with no active maintenance or vulnerability disclosures.' What is the *primary* concern driving this risk classification?
The core risk here isn't about performance, licensing, or documentation. The classification focuses on the *absence* of maintenance and vulnerability disclosures for `X`. This means there's a high probability that unpatched security flaws exist, making the application vulnerable to exploits – this is precisely what drives the 'moderate' risk level; options A, B, and C represent secondary concerns.
9 / 10
During a standup meeting, David (Lead Developer) says: 'We're using the `FastCache` service for session data. It's technically a third-party dependency, but we haven't defined any SLAs or monitoring around its availability – it's currently 'acceptable' from a risk perspective.' What is David attempting to justify?
David's statement reveals that 'acceptable' means they've consciously decided to accept the risk of `FastCache` being unavailable or poorly supported. This isn't about choosing a low-quality solution; it's about acknowledging the potential downsides and not actively mitigating them. Options A, B, and C misinterpret the meaning of 'acceptable' in this context.
10 / 10
Emily (Developer) writes a PR description: 'Implemented new user profile validation. Uses `Jsonschema` library for schema definition and validation. No specific testing of edge cases has been performed yet.' What risk is Emily implicitly acknowledging?
Emily acknowledges that she hasn't thoroughly tested the edge cases related to the `Jsonschema` validation. This means there's a risk of invalid data being accepted and saved – the schema might not cover all possible user input scenarios. Options A, B, and C are tangential concerns; the core issue is the lack of rigorous testing of the validation logic.
What does this Technical Due Diligence Language exercise cover?
This exercise, "Technical Risk Vocabulary in Due Diligence", tests your understanding of technical due diligence language vocabulary and phrasing through 10 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 10 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.