Worked solutions
Compare your reasoning with the evidence, not just the answer letter. These are original learning scenarios, not official exam questions.
Case 1 · One sign-in, two different factors
Best choice: MFA for the factors; SSO for session reuse. The password is a knowledge factor and the separately held authenticator supplies a possession factor. Reusing that sign-in across applications is SSO.
Verification or reasoning check: Name the knowledge and possession factors, then separately identify the reused sign-in session.
Why the other choices fit less well
- SSO for the factors; MFA for session reuse: This reverses the roles. SSO concerns reusing an authenticated session; MFA concerns distinct factor categories.
- OTP proves MFA, regardless of the password: OTP means one-time password. A single OTP can be one factor; the evidence of two distinct factor categories establishes MFA in this case.
- Two applications prove two-factor authentication: The number of applications does not establish the number of authentication factors.
Remember: Multiple steps do not automatically mean MFA; an SSO session can be established using MFA.
Technical context: NIST SP 800-63B-4: authentication factors · NIST: single sign-on. The scenario facts are original teaching inputs.
Case 2 · Calendar access without sharing a password
Best choice: OAuth. OAuth enables limited delegated access using access tokens. The token’s scope and the resource server’s checks constrain what the tool may do.
Verification or reasoning check: Check the granted scope and the calendar resource server’s authorization decision; do not treat token possession as proof of a separate user-login protocol.
Why the other choices fit less well
- SAML: SAML exchanges security assertions and can support federated sign-in. The described scoped API access-token delegation is the OAuth use case.
- TLS: TLS protects a channel. It does not itself grant the scheduling tool the described calendar permission.
- PKI: PKI supports public-key trust and certificates. It is not the delegated API authorization framework described.
Remember: OAuth alone is an authorization framework, not a user-authentication protocol.
Technical context: RFC 6749: OAuth 2.0 authorization framework · OASIS SAML 2.0 Core. The scenario facts are original teaching inputs.
Case 3 · A root-cause classification
Best choice: CWE. CWE classifies software and hardware weakness types. It answers the root-cause category question.
Verification or reasoning check: Separate the vulnerability identifier, its weakness classification, and its severity assessment before setting a remediation priority.
Why the other choices fit less well
- CVE: A CVE record identifies a specific publicly disclosed vulnerability; its identifier is not the weakness taxonomy.
- CVSS: CVSS describes vulnerability characteristics and severity. A score or vector does not replace a weakness classification.
- NVD: NVD is a vulnerability-data repository that can include links and analysis. The requested weakness taxonomy is CWE.
Remember: CVE, CWE and CVSS answer different questions. Severity alone is not business risk.
Technical context: MITRE: About CWE · FIRST: CVSS v4.0 user guide · NIST: NVD overview. The scenario facts are original teaching inputs.
Case 4 · An alert becomes a repeatable workflow
Best choice: SOAR. SOAR coordinates tools and repeatable response steps. The approval gate remains part of the stated workflow.
Verification or reasoning check: Trace enrichment, ticket creation and the approval gate in the playbook; confirm isolation cannot run before the required approval.
Why the other choices fit less well
- SIEM: SIEM supports event collection and analysis, already present in this case. A product may combine SIEM and SOAR; the missing function is orchestration.
- SOC: The SOC is the operational team or function. Its people define and supervise the workflow, but the requested automation capability is SOAR.
- EDR: EDR investigates and responds on endpoints. It may execute an authorized isolation action, but it is not the whole cross-tool workflow described.
Remember: Name the capability, not only a product. One platform can include several security functions.
Technical context: Microsoft: Sentinel SOAR automation · Microsoft: endpoint detection and response. The scenario facts are original teaching inputs.
Case 5 · Service returns, but how much data is missing?
Best choice: RTO was met; RPO was missed. The 45-minute recovery is within the 60-minute RTO. Data is 10 minutes behind the outage, exceeding the stated 5-minute RPO.
Verification or reasoning check: Calculate 14:45 minus 14:00 for recovery duration and 14:00 minus 13:50 for the data gap; compare each with its own target.
Why the other choices fit less well
- Both objectives were met: Recovery took 45 minutes, but the 10-minute data gap exceeds the 5-minute RPO allowance.
- RPO was met; RTO was missed: This swaps the measures. RTO is checked against 45 minutes of downtime; RPO against the 10-minute data gap.
- Both objectives were missed: The RPO was missed, but the service returned within the allowed recovery time.
Remember: A working restored service does not by itself demonstrate that the recovery-point requirement was met.
Technical context: NIST: recovery time objective · NIST: recovery point objective. The scenario facts are original teaching inputs.
Case 6 · A status response for one certificate
Best choice: OCSP. OCSP supplies certificate-status responses without requiring the client to obtain a full CRL. The response still needs proper validation.
Verification or reasoning check: Validate the responder’s authority, signature, certificate identifier and response freshness under the client’s policy. A status of good is not a substitute for all certificate checks.
Why the other choices fit less well
- CSR: A certificate signing request asks for certificate issuance. It is not a revocation-status response.
- CRL: A certificate revocation list lists revoked certificates. The case specifically requests an individual protocol response instead of downloading the list.
- PKI: PKI is the broader infrastructure supporting public-key trust. The specific status-query protocol is OCSP.
Remember: Issuing a certificate, maintaining trust infrastructure and checking revocation status are different jobs.
Technical context: RFC 6960: Online Certificate Status Protocol · RFC 2986: certification request syntax. The scenario facts are original teaching inputs.
Case 7 · Authentication must match the visible From domain
Best choice: DMARC. DMARC evaluates alignment with the author’s From domain using authenticated SPF or DKIM results and communicates domain policy preferences.
Verification or reasoning check: Identify the visible From domain and the authenticated SPF or DKIM identity; check their alignment rather than accepting any unrelated pass.
Why the other choices fit less well
- SPF alone: SPF checks whether a host is authorized for the relevant envelope identity. An SPF pass alone does not establish alignment with the visible From domain.
- DKIM alone: DKIM verifies a signing-domain signature. A valid signature from an unrelated domain alone does not establish the requested alignment.
- BIMI: BIMI supports qualifying brand-logo display. The authentication-alignment mechanism requested here is DMARC.
Remember: Passing email authentication does not prove the message content is safe or the sender is trustworthy.
Technical context: RFC 9989: DMARC · RFC 7208: SPF · RFC 6376: DKIM. The scenario facts are original teaching inputs.
Case 8 · Alerting is not the requested stopping action
Best choice: IPS. An intrusion prevention system can detect and attempt to stop matching activity, including dropping traffic when configured to do so.
Verification or reasoning check: Use an authorized test to confirm the configured matching traffic is blocked and recorded, while expected legitimate traffic still passes.
Why the other choices fit less well
- IDS: An IDS detects and alerts. The explicit inline dropping requirement makes IPS the better match.
- CSPM: CSPM assesses cloud configurations and posture; it is not the inline signature-based traffic prevention described.
- DLP: DLP governs sensitive-data handling. The case describes an intrusion signature and inline prevention rather than a sensitive-data policy.
Remember: Prevention capability is not a guarantee that every attack will be detected or stopped.
Technical context: NIST SP 800-94: intrusion detection and prevention systems. The scenario facts are original teaching inputs.