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.

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.

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.

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.

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.

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.

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.

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.