5 exercises — acronyms appear inside Slack threads, Jira tickets, PR reviews, and architecture docs. Practise reading them in authentic messages, not just isolated definitions.
SPOF / HA — Single Point Of Failure; High Availability
RTO / RPO / MTTR — Recovery Time / Recovery Point Objectives; Mean Time to Recovery
0 / 5 completed
1 / 5
A Slack message reads: "The ETA for the hotfix is EOD. LGTM on the PR once QA signs off. TBD who covers while I'm OOO tomorrow." What does LGTM mean in this context?
LGTM = Looks Good To Me — one of the most common approvals in code reviews and Slack. When a reviewer says "LGTM" on a PR, they are signalling that the code is ready to merge from their perspective. In the message above, the full meaning is: "The estimated time of arrival (ETA) for the hotfix is by end of day (EOD). I approve (LGTM) the pull request, pending QA sign-off. It's to be determined (TBD) who will cover while I'm out of office (OOO) tomorrow." Other common approval-related acronyms: SGTM = Sounds Good To Me, ACK = Acknowledged, +1 = I agree / I approve (not strictly an acronym, but widely used). LGTM is so embedded in developer culture that GitHub and GitLab display ✅ icons for it in some review tools.
2 / 5
A project manager writes in Jira: "This is a P1 bug affecting the critical path. What's the ETA on the fix? The CTO is asking for an update." What does P1 mean here, and what is the critical path?
P1 = Priority 1 — the highest severity or urgency level in most issue-tracking systems. P1 bugs typically require immediate response (often within hours), and the SLA for resolution is strict. Some teams use "SEV-1" instead, but P1/P2/P3 is the more common Jira convention. The critical path comes from project management (CPM — Critical Path Method) and means the longest sequence of dependent tasks from start to finish; any delay on the critical path directly delays the project completion date. In context, the PM is saying: "This is the most urgent bug, and it's delaying our entire project timeline." CTO = Chief Technology Officer. ETA = Estimated Time of Arrival (completion time for the fix).
3 / 5
In a PR comment, a security engineer writes: "Please resolve the TODOs before merge. Also — hardcoded API keys are a serious XSS vector. Move these to env vars." Which statement correctly explains XSS?
XSS = Cross-Site Scripting — one of the most common web security vulnerabilities (listed in the OWASP Top 10). An attacker injects malicious JavaScript into a web page; when another user loads that page, the script executes in their browser and can steal cookies, tokens, or personal data. Despite the abbreviation using "X" (from the historical spelling "cross"), it is spoken as "Cross-Site Scripting" or just "X-S-S." Note: the comment in the exercise contains a slight technical confusion — hardcoded API keys are primarily a credential exposure risk; XSS is the injection vulnerability. However, the reviewer's core advice is correct: never hardcode credentials, always use environment variables. Related: CSRF (Cross-Site Request Forgery) — a different attack where a user's browser is tricked into making unauthorised requests.
4 / 5
An architect writes in a design document: "The current monolith has a SPOF in the DB layer. Moving to microservices improves HA and eliminates this SPOF, but increases operational complexity." What does SPOF mean?
SPOF = Single Point Of Failure — a component or part of a system that, if it fails, causes the entire system to stop functioning. A classic example: a single database server with no replicas. If it goes down, the whole application is down. Eliminating SPOFs is a core reliability engineering goal. HA = High Availability — designing systems to be resilient and remain operational even when individual components fail. Typical HA strategies: redundancy (multiple instances), failover (automatic switch to backup), and replication (data copies in multiple locations). In the architect's statement: the monolith has a single database that is a SPOF — migrating to microservices (with separate databases per service) reduces this risk but adds complexity.
5 / 5
A DevOps engineer writes in an incident ticket: "The RTO for this tier-1 service is 4h; RPO is 1h. Our current backup strategy only meets the RTO — we're failing the RPO. MTTR last incident was 3.5h." What is the difference between RTO and RPO?
RTO (Recovery Time Objective) = the maximum acceptable time for a service to be restored after a failure. If RTO = 4h, the system must be back online within 4 hours of an incident. RPO (Recovery Point Objective) = the maximum acceptable amount of data loss, measured in time. If RPO = 1h, backups must occur at least every hour — you can lose at most 1 hour of data. In the ticket: meeting the 4h RTO means restoring service is achievable; failing the 1h RPO means backups are too infrequent (e.g., daily backups), so more than 1 hour of data could be lost in an incident. MTTR = Mean Time to Recovery — average time taken to restore service after all incidents. An MTTR of 3.5h is within the 4h RTO. These three acronyms (RTO, RPO, MTTR) appear constantly in SRE, platform engineering, and disaster recovery planning — memorise them as a set.