A single point of failure is a component or dependency whose failure can seriously disrupt a service because no adequate alternative is ready. In a cloud environment, lost data or a hardware failure that takes down part of the architecture can expose missing redundancy or an overly tightly coupled setup. Moving to the cloud does not make failures disappear. section 8.3.1
Look for weak points in both the system and the work that keeps it running:
- Ask what happens when a piece of the architecture fails, and whether another can take over without major disruption. section 8.3.1 section 14.5.1
- Check backups, recovery plans, and instructions that someone else could follow to restore the environment. section 14.5.1
- Identify who pays for and renews essential services. An account billed to an original developer's personal card may be an operational dependency that needs resolving. section 14.5.1
A dependency outside the architecture
A production service can go dark because a domain or SSL certificate is not renewed. Google temporarily lost control of the blogger.in domain after a missed payment. A resilience review therefore needs to ask not only what fails over, but also who owns and renews the services on which production depends. section 14.5.1
During due diligence, ask how the team knows production is healthy right now: which daily checks are made, which logs are reviewed, and what early warning signs people watch. Then discuss known weak points and how they are being addressed. The aim is a defensible picture of what it takes to keep the service running, not an assumption that cloud hosting alone provides resilience. section 14.5.1 section 8.3.1
