5 exercises — PKI and TLS/mTLS, SSO and MFA, RBAC vs. ABAC access control, and IDS vs. IPS detection and prevention.
0 / 5 completed
1 / 5
A security architecture document mentions "PKI" as the foundation for issuing TLS certificates. What does PKI stand for, and what problem does it solve?
PKI (Public Key Infrastructure) is the trust framework underlying HTTPS and most modern authentication systems. A Certificate Authority (CA) issues digital certificates that bind a public key to an identity (a domain name, an organisation), and browsers/clients trust that certificate because they trust the CA that signed it — this chain of trust is what lets your browser show a padlock icon without you personally verifying the website's cryptographic keys.
Related vocabulary:public/private key pair — the public key can be shared openly and used to encrypt data or verify a signature; the private key must stay secret and is used to decrypt or create a signature. Certificate chain — the sequence of certificates from a website's certificate up to a trusted root CA.
2 / 5
A backend engineer says: "We're moving from TLS to mTLS for service-to-service communication." What is the difference between TLS and mTLS?
In standard TLS, only the server proves its identity via a certificate — this is why your browser can verify it's really talking to your bank's website, but the bank's server has no cryptographic proof of who you are (that's handled separately, typically by a password or session token, at the application layer).
mTLS (mutual TLS) requires both sides to present certificates, so each party cryptographically verifies the other. This is especially valuable in a microservices architecture (often implemented via a service mesh like Istio or Linkerd) where you want to guarantee that only legitimate internal services — not an attacker who has gained network access — can call sensitive internal APIs.
The tradeoff: mTLS requires managing certificates for every service (issuance, rotation, revocation), which adds operational complexity compared to standard TLS.
3 / 5
A login flow uses "SSO" combined with "MFA" for enterprise users. How would you explain these two abbreviations and why they're often paired together?
SSO (Single Sign-On) centralises authentication through one identity provider (e.g. Okta, Entra ID, Google Workspace), so employees log in once and gain access to email, code repositories, internal tools, and more without separate logins for each. This is both a convenience and a security consolidation — but it also concentrates risk: if that one central login is compromised, an attacker potentially gains access to everything connected to it.
MFA (Multi-Factor Authentication) directly mitigates that concentrated risk by requiring something beyond just a password — commonly "something you know" (password) plus "something you have" (a phone, a hardware key) or "something you are" (biometrics). Requiring MFA specifically at the SSO layer means every connected application inherits that stronger protection automatically, rather than needing MFA configured separately for each individual app.
4 / 5
An access-control design document compares "RBAC" and "ABAC" as two approaches. What's the practical difference, and when would a team choose one over the other?
Choosing between RBAC and ABAC is a real architectural tradeoff frequently discussed in security certification material and system design interviews.
RBAC is easy to understand and audit ("what can an Editor do?") but can become unwieldy when permission requirements are highly contextual — e.g. "Editors can edit documents, but only ones from their own department, and only during business hours" starts to strain a pure role model, often requiring a proliferation of narrow roles (Editor-Finance, Editor-Finance-BusinessHours...) to express.
ABAC handles this naturally by evaluating rules against attributes directly (department == resource.department AND time BETWEEN 9am-5pm) without needing a combinatorial explosion of specific roles, at the cost of policies being harder to read at a glance and harder to test exhaustively.
Practical guidance often cited: start with RBAC for its simplicity, and introduce ABAC (or a hybrid) only once genuine contextual requirements outgrow what roles alone can cleanly express.
5 / 5
A network security review mentions deploying "an IDS initially, and considering an IPS later." What's the key operational difference between these two, and why might a team deploy IDS first?
The IDS vs. IPS distinction hinges on a single word: detection versus prevention, i.e. passive alerting versus active blocking.
IDS — sits (often) out-of-band, inspecting a copy of traffic, and generates alerts for a security team to review and act on manually. Because it doesn't block anything itself, a false positive (a legitimate request incorrectly flagged as malicious) only produces an alert, not an outage.
IPS — sits in-line (directly in the traffic path) and can automatically drop or block matching traffic before it reaches its destination. This is more powerful — it can stop an attack in real time — but a false positive can now cause a real incident, blocking legitimate users or requests.
Why "IDS first" is common practice: deploying detection rules in IDS mode lets a team observe real traffic, tune rules to reduce false positives, and build confidence in the ruleset's accuracy before "flipping the switch" to IPS mode, where the same rules start actively blocking traffic — a much higher-stakes failure mode if the rules aren't well-tuned.
What will I practice in "Security Abbreviations — IT Abbreviations Exercises"?
This is an IT Abbreviations exercise set. It walks through 5 scenario-based multiple-choice questions built around real usage of IT Abbreviations terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 5 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the IT Abbreviations vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more IT Abbreviations exercises?
See the IT Abbreviations exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — IT Abbreviations vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.