5 exercises — one acronym, four definitions. Only one is accurate. The distractors are plausible-sounding but wrong. Tests real understanding, not just memorisation.
0 / 5 completed
How to approach this exercise
Read all four options carefully — the distractors use real IT vocabulary to sound plausible
Ask: does this definition match how engineers actually use this acronym in conversation?
If unsure, eliminate options that: (1) expand the acronym incorrectly, or (2) describe something too narrow or too broad
The feedback explanations are detailed — even for correct answers, read them for the context examples
1 / 5
CAP
The acronym CAP — as in the CAP theorem — is well-known in distributed systems. Which definition is correct?
CAP theorem (also called Brewer's theorem, after Eric Brewer who proposed it in 2000) states that a distributed system can provide at most two of the following three guarantees simultaneously: C — Consistency (every read receives the most recent write or an error); A — Availability (every request receives a response, though it may not contain the most recent data); P — Partition tolerance (the system continues to function despite network partitions that drop messages between nodes). Since network partitions are a reality in any distributed system, the practical choice is between CP (consistent and partition-tolerant, e.g., HBase, Zookeeper) and AP (available and partition-tolerant, e.g., DynamoDB, Cassandra with eventual consistency). Traditional single-node RDBMS systems choose CA (not partition-tolerant). In interviews: "We chose Cassandra for this service because our priority is availability and partition tolerance — we can tolerate eventual consistency for user activity logs."
2 / 5
ORM
A backend developer says: "We're using an ORM so we don't have to write raw SQL." Which definition of ORM is correct?
ORM — Object-Relational Mapping — is a technique that creates a bridge between the object-oriented world of application code and the relational world of SQL databases. An ORM library allows developers to query and manipulate the database using the objects and methods of their programming language, without writing raw SQL. Examples: Hibernate (Java), SQLAlchemy (Python), Active Record (Ruby on Rails), Entity Framework (.NET), Prisma / TypeORM / Sequelize (Node.js). The advantages: less boilerplate SQL, type safety (especially in TypeScript ORMs), easier migrations. The trade-offs: ORMs can generate inefficient queries for complex cases; experienced engineers know when to drop down to raw SQL for performance-critical queries. Correct usage: "Our ORM generates the JOIN queries automatically, but for the reporting endpoint we wrote raw SQL for performance."
3 / 5
CQRS
An architect says: "We should consider CQRS for the high-read, low-write user dashboard." Which definition of CQRS is correct?
CQRS — Command Query Responsibility Segregation — is an architectural pattern (originally by Greg Young, building on CQS by Bertrand Meyer) that separates the responsibility of handling commands (write operations that change state) from handling queries (read operations that return data). In a CQRS system, you have: a write model (optimised for consistency, validation, business rules) and a separate read model (optimised for query performance — often denormalised, cached, or pre-computed). CQRS is commonly combined with Event Sourcing (storing state as a sequence of events rather than current state). Benefits: the read and write paths can scale independently, be implemented in different databases, and evolve separately. Trade-offs: increased complexity — two models to maintain, potential eventual consistency between write and read sides. A dashboard with 100×more reads than writes is a classic use case. "The write side goes through our domain model; the read side is a pre-computed projection stored in Redis."
4 / 5
mTLS
A DevOps engineer says: "All inter-service communication in our service mesh uses mTLS." Which definition of mTLS is correct?
mTLS — mutual TLS (also written "Mutual TLS") — extends standard TLS by requiring certificate-based authentication on both sides of the connection. In regular HTTPS, only the server presents a certificate (to prove it is who it claims to be). In mTLS, the client also presents a certificate, enabling the server to verify the client's identity. This is essential in zero-trust security architectures and service meshes (Istio, Linkerd, Consul). How it works: (1) Server sends its certificate; (2) Client verifies server certificate; (3) Client sends its certificate; (4) Server verifies client certificate; (5) Encrypted communication begins. Without mTLS in a service mesh, any compromised container could call any other service. With mTLS, each service must present a valid certificate issued by the mesh's Certificate Authority (CA). "Istio handles mTLS transparently — every sidecar proxy authenticates automatically, so we get zero-trust service-to-service auth without changing application code."
5 / 5
SLI
During an SRE meeting, a team discusses its SLI. Which definition is correct — and how does it relate to SLO and SLA?
SLI / SLO / SLA — the "reliability triangle" in Site Reliability Engineering: SLI (Service-Level Indicator): a specific measurable metric — e.g., "the proportion of HTTP requests returning 2xx within 300ms". An SLI answers: "what are we measuring?" SLO (Service-Level Objective): the target value for an SLI — e.g., "the SLI should be ≥ 99.9% over a rolling 30-day window". An SLO answers: "how good does it need to be?" SLA (Service-Level Agreement): a formal contract between a service provider and a customer, specifying the consequences (credits, penalties) if SLOs are violated. An SLA answers: "what happens if we fail?" Teams typically set internal SLOs stricter than public SLAs — e.g., internal SLO: 99.95%, public SLA: 99.9%. The difference between SLO and SLA creates an "error budget" buffer. Option D is a common misconception — SLI is not exclusively P99 latency; it is whatever metric you choose to measure. "Our key SLI is availability: SLO is 99.9%, SLA promises 99.5% — the gap is our error budget."