Exam: Chapters 16–18 · Security+ SY0-701

Chapters 16–18 Practice Exam

📝 20 scored questions ⏱️ 25-minute target 🎯 Pass threshold: 80% (16/20)

Time remaining

25:00

Part A — Multiple Choice (Questions 1–20)

Ch 16 · Hashing & Digital Signatures

Question 1 of 20

A security team discovers that a company stores all user passwords as unsalted MD5 hashes. An attacker steals the database. Which attack method allows the attacker to crack the most passwords in the shortest time?

A. Brute force — trying every possible character combination B. Dictionary attack using bcrypt-hashed wordlists C. Rainbow table lookup — comparing stolen hashes against a pre-computed table of MD5 hash values D. Known-plaintext attack against the MD5 algorithm itself

✅ C — Rainbow table lookup. Without salting, identical passwords produce identical MD5 hashes every time. Attackers pre-compute a massive table of word/hash pairs offline. Cracking then becomes a simple lookup — near-instant regardless of password complexity. Salting defeats this entirely because each user's salt makes the same password hash to a completely different value, requiring a separate brute-force per user.

Ch 16 · Hashing & Digital Signatures

Question 2 of 20

An administrator downloads a critical security patch from a vendor website. Before installing it, she wants to verify the file has not been tampered with in transit. What should she do?

A. Verify the digital certificate on the vendor's download page B. Compute the SHA-256 hash of the downloaded file and compare it to the value published by the vendor C. Check that the file size matches the vendor's specification D. Run the file through antivirus before installation

✅ B — Hash comparison. The vendor publishes the expected SHA-256 hash alongside the download. The administrator computes the hash of the file she downloaded and compares. If they match, the file is byte-for-byte identical to what the vendor published — any tampering or corruption in transit would produce a completely different hash (avalanche effect). File size (C) can match even with subtle code injection.

Ch 16 · Hashing & Digital Signatures

Question 3 of 20

A developer needs to digitally sign a software release. Which sequence of operations correctly creates a digital signature?

A. Encrypt the document with the recipient's public key, then hash the result B. Hash the document with MD5 and publish the hash on a public server C. Hash the document with SHA-256, then encrypt the hash using the developer's own private key D. Encrypt the entire document with the developer's private key

✅ C. Digital signature creation: (1) Hash the document → produces a fixed-size digest. (2) Encrypt the digest with your own private key. The result is the signature. Verification: recipient decrypts the signature with your public key (getting the digest back), independently hashes the document, and compares. Note: D is wrong — you don't encrypt the whole document; that would be inefficient and doesn't leverage asymmetric key pairs correctly for signing vs. encryption purposes.

Ch 16 · Hashing & Digital Signatures

Question 4 of 20

A CFO digitally signs a purchase order authorizing a $2M transfer. Three days later, she claims she never sent it and demands a refund. The bank's legal team is confident the claim will fail. Which security property defeats her claim?

A. Confidentiality — the message was encrypted so only the bank could read it B. Integrity — the message was not modified after signing C. Non-repudiation — only the CFO's private key could have produced that valid signature, proving she sent it D. Authentication — the CFO's identity was verified at login

✅ C — Non-repudiation. The signature was created using the CFO's private key — a key only she should possess. The bank can verify the signature with her public key. Since only her private key can produce a signature that verifies with her public key, she cannot credibly deny having sent the message. Integrity (B) confirms the message wasn't altered, but non-repudiation is what prevents the denial of origin specifically.

Ch 16 · Hashing & Digital Signatures

Question 5 of 20

A security engineer argues that adding a salt to password hashes before storage adds significant protection. A colleague counters that salts are stored in plaintext in the same database, so they add nothing. Who is correct and why?

A. The colleague is correct — a salt stored in plaintext next to the hash provides no protection B. The engineer is correct — salts are not secret, but uniqueness per user defeats pre-computed rainbow tables and forces independent brute force for each account C. The colleague is correct — salts must be stored separately to provide protection D. The engineer is correct — salts are secret values that must never be exposed

✅ B — The engineer is correct. Salt's purpose is uniqueness, not secrecy. Even stored in plaintext, each user's unique salt means identical passwords hash to different values. An attacker can't use a single rainbow table — they'd need a separate table pre-computed for each unique salt, making pre-computation attacks economically infeasible. They must brute-force each account independently. Salt is explicitly not secret — the specification is clear on this.

Ch 17 · Blockchain

Question 6 of 20

What is the primary mechanism that makes blockchain records tamper-evident?

A. Each block is encrypted with a government-issued key that only authorized parties can access B. Each block contains the cryptographic hash of the previous block — altering any block changes its hash, which breaks the chain from that point forward C. Blocks are stored on multiple servers that compare and vote on correct values every hour D. Each transaction is signed by a central authority before being added to a block

✅ B — Hash chaining. Block N contains: transaction data + timestamp + hash of Block N-1. If an attacker modifies Block N, its hash changes. Block N+1 contains the old hash of Block N — now there's a mismatch. Every subsequent block is also invalidated. To successfully alter one historical block, the attacker must recompute every block after it faster than the honest network adds new blocks — computationally infeasible on large networks.

Ch 17 · Blockchain

Question 7 of 20

In 2018, Ethereum Classic experienced a successful attack that allowed the attacker to double-spend cryptocurrency by rewriting recent transaction history. What type of attack was this?

A. A Sybil attack — the attacker created many fake node identities to outvote legitimate nodes B. A replay attack — the attacker replayed valid transactions to execute them multiple times C. A 51% attack — the attacker controlled over 50% of the network's mining power, allowing them to rewrite recent blocks D. A smart contract exploit — a bug in a deployed contract allowed fund drainage

✅ C — 51% attack. Ethereum Classic was a smaller network with less total mining power than Ethereum. An attacker who controls >50% of PoW mining power can mine their own private chain faster than the honest network. They spend coins on the public chain, then release their longer private chain, which the network accepts as canonical (longest chain wins) — reversing their transactions and allowing double-spend. This is why larger networks with more hashrate are more attack-resistant.

Ch 17 · Blockchain

Question 8 of 20

A pharmaceutical company wants to track drugs from manufacturer to patient with records that no single participant can alter unilaterally, and where every step — production, shipping, customs, pharmacy — is logged immutably. Which architecture is most appropriate?

A. A centralized database managed by the pharmaceutical company with access logs B. RFID tags on each package with a central RFID tracking system C. A permissioned blockchain where each supply chain participant runs a node — no single party controls the ledger, and all entries are hash-chained and distributed D. A PKI system where each participant digitally signs shipment manifests stored in a central repository

✅ C — Permissioned blockchain. A centralized database (A) is controlled by one party — they can alter records. RFID (B) tracks location but the data is in a central database that can be modified. A permissioned (private) blockchain allows only known participants but maintains the core blockchain properties: distributed ledger, no single controlling party, hash-chained records. Participants can verify that no entry has been altered since logging.

Ch 17 · Blockchain

Question 9 of 20

A developer deploys a smart contract to a blockchain to automatically release escrow funds when a property sale closes. Two months after deployment, a logic bug is discovered that could drain funds. What property of smart contracts makes this especially problematic?

A. Smart contracts can only be updated by the original CA that certified them B. Once deployed on a blockchain, smart contract code is immutable — the bug cannot be patched; a new contract must be deployed and funds migrated manually C. Smart contracts automatically roll back when errors are detected D. Smart contracts require 51% node approval to execute, which would block the buggy transaction

✅ B — Immutability cuts both ways. The same immutability that prevents tampering with legitimate records also prevents patching bugs. Deployed smart contract code is permanently part of the blockchain. This was demonstrated catastrophically by the 2016 DAO hack — a bug in Ethereum smart contract code was exploited to drain $60M, and the only remedy required a controversial hard fork of the entire Ethereum blockchain. Code must be thoroughly audited before deployment.

Ch 17 · Blockchain

Question 10 of 20

What is the primary environmental advantage of Proof of Stake over Proof of Work as a consensus mechanism?

A. Proof of Stake is more resistant to 51% attacks because staked collateral is destroyed if validators cheat B. Proof of Stake produces larger blocks, enabling more transactions per second C. Proof of Stake eliminates the massive energy consumption of Proof of Work's computational puzzles — validators are selected based on staked collateral, not computational racing D. Proof of Stake requires less storage space for the blockchain history

✅ C. PoW requires miners to perform billions of hash computations per second in a race — this is intentionally wasteful, consuming electricity equivalent to some small countries. PoS selects validators based on how much cryptocurrency they "stake" as collateral. No computational race occurs. Ethereum's 2022 switch from PoW to PoS reduced its energy consumption by ~99.95%. The security model differs — PoS relies on economic disincentives (loss of stake) rather than computational cost.

Ch 18 · Digital Certificates

Question 11 of 20

A web server administrator generates a key pair and sends a Certificate Signing Request (CSR) to a public CA. What does the CSR contain, and what critical element is deliberately excluded?

A. The server's public key, private key, and organization identity B. The server's public key and organization identity — the private key never leaves the server and is never sent to the CA C. The server's private key encrypted with the CA's public key D. The server's previous certificate signed by an intermediate CA

✅ B. A CSR contains: the server's public key + identity information (domain, organization, country) + a signature proving the requester holds the matching private key. The private key never leaves the server — it is never transmitted anywhere. The CA signs the public key + identity data, creating the certificate. If the private key were sent to the CA, the entire trust model would collapse — anyone who ever had access to the CA could impersonate the server.

Ch 18 · Digital Certificates

Question 12 of 20

An organization's web server private key is stolen in a breach. The server's certificate has 8 months remaining on its validity period. What is the correct immediate response?

A. Wait until the certificate expires in 8 months, then renew with a new key pair B. Change the server's IP address to render the certificate invalid C. Immediately revoke the compromised certificate, generate a new key pair, obtain a new certificate, and deploy it — validity period is irrelevant when the private key is compromised D. Update the certificate's Subject field to indicate the private key is compromised

✅ C. Certificate validity and key compromise are independent. An attacker with the stolen private key can impersonate the server for the entire remaining 8 months if the certificate is not revoked. The certificate must be revoked immediately through the CA — this updates the CRL and OCSP responder. Simultaneously, generate a new key pair (never reuse a compromised key), submit a new CSR, obtain a new certificate. The attacker's copy of the old certificate becomes useless once revoked.

Ch 18 · Digital Certificates

Question 13 of 20

A high-traffic e-commerce server wants to provide certificate revocation status to clients without the latency of clients querying the CA's OCSP responder on every TLS handshake. Which mechanism achieves this?

A. Certificate Revocation List (CRL) — the server downloads the full list daily B. Standard OCSP — clients query the CA's OCSP responder during each handshake C. OCSP Stapling — the server pre-fetches a CA-signed certificate status response and includes it in the TLS handshake, so clients receive fresh revocation status without a separate CA query D. Certificate Transparency logs — clients check if the certificate appears in the log

✅ C — OCSP Stapling. The server queries the OCSP responder periodically (e.g., every few hours), caches the CA-signed response, and "staples" it to the TLS handshake. Clients receive the signed status from the server instead of making a separate connection to the CA. Benefits: eliminates per-client OCSP latency, eliminates the privacy issue (CA doesn't see which sites clients visit), and works even if the OCSP responder is temporarily unavailable. The stapled response is CA-signed so clients can verify it.

Ch 18 · Digital Certificates

Question 14 of 20

A company owns *.company.com — a wildcard certificate. They need to also secure staging.api.company.com. Will the wildcard certificate cover this subdomain?

A. Yes — wildcard certificates cover all subdomains at any depth under the base domain B. No — a wildcard covers exactly one level of subdomain; staging.api.company.com has two levels (staging under api under company.com) and requires a SAN certificate C. Yes — but only if staging.api.company.com is manually listed in the SAN field of the wildcard certificate D. No — wildcard certificates are restricted to production environments by CA policy

✅ B. *.company.com covers: www.company.com, api.company.com, mail.company.com — one wildcard level. It does NOT cover staging.api.company.com because that is two levels deep. For multi-level or mixed domain coverage, a SAN (Subject Alternative Name) certificate explicitly lists every hostname it covers — api.company.com, staging.api.company.com, www.company.com, etc. SANs are more flexible, wildcards are more convenient for a known subdomain pattern.

Ch 18 · Digital Certificates

Question 15 of 20

Why do Certificate Authorities use intermediate CA certificates to sign server certificates, rather than having the Root CA sign them directly?

A. Root CAs are legally prohibited from issuing certificates to individual servers B. The Root CA can be kept offline and air-gapped — if an Intermediate CA is compromised, only its certificates need revocation; the Root CA's trust anchor remains intact and secure C. Root CAs are limited to a fixed number of certificate signings per year by NIST D. Intermediate CAs apply stronger encryption than Root CAs can

✅ B — Defense in depth. The Root CA's private key is the foundation of the entire trust hierarchy — if it's compromised, every certificate in the chain becomes suspect. By keeping the Root CA offline (powered down, in a vault, accessed only for ceremony), its key is protected from network attacks. Intermediate CAs operate online and sign end-entity certificates. If an Intermediate CA is compromised, only its issued certificates need revocation — the Root CA simply revokes the Intermediate CA certificate and issues a new one.

Ch 16 · Hashing & Digital Signatures

Question 16 of 20

A system uses HMAC-SHA256 to verify the integrity of API messages between two internal services. An auditor notes this cannot provide non-repudiation. Why not?

A. HMAC uses a public key; since the key is public, anyone can create a valid HMAC B. HMAC uses a shared secret key — both sender and receiver can compute a valid HMAC, so neither party can prove which one generated a specific message C. HMAC provides non-repudiation; the auditor is incorrect D. HMAC does not use cryptography and therefore cannot prove anything

✅ B. HMAC (Hash-based Message Authentication Code) uses a shared symmetric key. Both parties know the key and can compute valid HMACs. In a dispute, either party could have generated the message — there's no way to distinguish who produced it. Digital signatures use asymmetric keys: only the holder of the private key can sign. Anyone with the public key can verify. This asymmetry is what creates non-repudiation — the signer cannot deny signing because only they have the private key.

Ch 17 · Blockchain

Question 17 of 20

A vendor claims that once data is written to their blockchain system, it is "100% permanent and can never be altered by anyone." Is this claim accurate?

A. Yes — no cryptographic system has ever successfully altered a deployed blockchain B. Yes — blockchain hash-chaining is mathematically impossible to reverse under any circumstances C. Practically yes but not technically absolute — a 51% attack could theoretically rewrite recent history on small networks, though this is economically infeasible on large public blockchains D. No — any node operator with admin privileges can propose and execute a block deletion

✅ C. The "100% permanent" claim is technically an overstatement. A 51% attack can rewrite recent blocks — this has happened on smaller networks (Ethereum Classic 2018, Bitcoin Gold). On Bitcoin or Ethereum, the cost of acquiring 51% of hash power or stake makes such an attack economically irrational, not mathematically impossible. Additionally, hard forks (as with the 2016 DAO hack) can roll back history by network consensus. For exam purposes: blockchain is immutable in practice on large networks, but not mathematically absolute.

Ch 18 · Digital Certificates

Question 18 of 20

A developer configures an internal API server with a self-signed certificate. A security auditor flags this as a risk. The developer responds: "Self-signed certificates use the same AES-256 encryption as CA-signed certificates — they're equally secure." Is the developer's reasoning correct?

A. Yes — encryption strength is identical, so there is no meaningful security difference B. No — encryption strength is the same, but a self-signed certificate provides no independent identity verification; clients cannot confirm the server is who it claims to be, creating MITM vulnerability C. No — self-signed certificates use weaker encryption algorithms than CA-signed certificates D. Yes — for internal APIs, self-signed certificates provide equivalent protection to CA-signed ones

✅ B. The developer confuses confidentiality with authentication. Self-signed certificates do encrypt traffic — the cipher suite and key length are identical. The problem is identity verification. A CA-signed certificate means an independent third party verified the server's identity before signing. A self-signed certificate just says "I am who I say I am" — clients must either trust blindly or accept MITM risk. An attacker can generate their own self-signed certificate for the same domain and intercept traffic if clients disable certificate verification (which they commonly do for self-signed).

Ch 16 · Hashing & Digital Signatures

Question 19 of 20

A security team switches from MD5 to bcrypt for password hashing. Beyond collision resistance, what key advantage does bcrypt provide over a fast hash like MD5 or SHA-256 for password storage?

A. bcrypt produces longer hash outputs, requiring more storage space per password B. bcrypt is intentionally slow — its configurable work factor means an attacker attempting brute force must invest significant computation per guess, multiplying attack time by orders of magnitude C. bcrypt requires a hardware security module to compute, preventing software-based attacks D. bcrypt automatically salts passwords, while MD5 and SHA-256 cannot be used with salts

✅ B — Key stretching. A modern GPU can compute billions of MD5/SHA-256 hashes per second. bcrypt's work factor makes each hash computation take ~100ms on current hardware. Cracking a single password now takes 100ms per guess instead of nanoseconds — a slowdown of 10 million×. As hardware improves, the work factor can be increased to maintain the same wall-clock time. Note: bcrypt does automatically include salting (D is partially true), but intentional slowness is the primary advantage over fast hashes.

Ch 18 · Digital Certificates

Question 20 of 20

A Root CA certificate is described as "self-signed." What does this mean and why does it not undermine the trust model?

A. Root CA certificates never expire — self-signing makes them permanent B. The Root CA signs its own certificate because there is no higher authority above it — trust comes not from a chain of signatures but from pre-installation in OS and browser trust stores by the platform vendor C. Root CAs use symmetric encryption to self-sign, which is stronger than asymmetric signing D. Self-signed Root CAs must be renewed annually by NIST to remain trusted

✅ B. The trust hierarchy must end somewhere. Root CAs are at the top — there is no authority above them to sign their certificate, so they sign their own (self-signed). This would normally provide no verification, but Root CA certificates are distributed out-of-band: Microsoft, Apple, Mozilla, and Google manually vet CAs and pre-install their Root certificates in OS and browser trust stores. When your browser trusts DigiCert, it's because Microsoft/Apple decided to trust DigiCert and shipped their Root certificate in Windows/macOS. That's the trust anchor.

Part B — Scenario Analysis (Unscored — for practice)

Ch 16–17 · Scenario

Scenario A — Software Integrity & Credential Storage Failures

A software company has two concurrent security crises: (1) Users have been tricked into installing malware disguised as the company's legitimate application — attackers created convincing fake download sites. (2) A database breach exposed 2 million user passwords stored as unsalted MD5 hashes — 800,000 have already been cracked by the attacker. Design remediation for both problems.

Problem 1 — Fake software / malware distribution:

Immediate: Implement code signing. Generate a key pair for the company, obtain a code-signing certificate from a trusted CA (DigiCert, Sectigo). Sign all release binaries with the private key. Users' OS now displays "Verified Publisher: Company Name" — unsigned or differently-signed executables trigger a warning.

Ongoing: (1) Submit software to Certificate Transparency monitoring — get alerted if anyone obtains a certificate for your domain. (2) Publish SHA-256 hashes of all releases on a separate, secured page. (3) Instruct users to download only from official URLs and verify the publisher signature before executing. (4) Submit fake sites to Google Safe Browsing / phishing takedown services.

Problem 2 — Unsalted MD5 password breach:

Immediate: Force password reset for all 2 million accounts — assume every password is compromised, not just the 800K cracked so far. Notify users per breach notification regulations (GDPR 72-hour window, state laws). Revoke all active sessions.

Remediation: Re-hash all passwords using bcrypt (work factor 12+) or Argon2id with unique per-user salts. On next login, hash the entered password with the new algorithm and replace the old MD5 hash. After a transition period, expire any accounts that haven't logged in (old hashes removed).

Long-term architecture: Never store passwords reversibly. Use bcrypt/Argon2 exclusively. Enable MFA to reduce impact of future credential compromise. Monitor for credential stuffing attacks (same breached passwords tried on other sites).

Ch 18 · Scenario

Scenario B — Internal PKI Deployment

A company has 300 internal servers all using self-signed certificates. Employees constantly click through "Your connection is not private" warnings, and the security team suspects employees now ignore all certificate warnings reflexively — a dangerous habit. The CISO wants to deploy a proper internal PKI and implement revocation. Design the architecture and rollout strategy.

PKI Architecture:

Root CA: Deploy an offline Root CA (Windows Server AD CS or open-source). Generate the Root CA key pair on an air-gapped machine. Store the Root CA private key on an HSM and in secure offline backup. The Root CA will be used only to sign Intermediate CA certificates — it is powered off between ceremony events.

Intermediate CA(s): Deploy one or more online Intermediate CAs for day-to-day certificate issuance. If one Intermediate CA is compromised, revoke it and issue a replacement from the Root CA — the Root CA trust anchor is unaffected. Sign the Intermediate CA certificate with the Root CA during a key ceremony.

Trust distribution: Push the Root CA certificate to all employee devices via Group Policy (Windows) or MDM (macOS/iOS/Android). Once installed, all certificates issued by the Internal PKI will show as trusted — eliminating certificate warnings for legitimate internal servers.

Revocation: Configure OCSP responder on the Intermediate CA for real-time revocation checking. Enable OCSP Stapling on all internal servers — servers pre-fetch their revocation status and include it in TLS handshakes. This eliminates per-client OCSP latency and works even during brief OCSP responder outages.

Rollout strategy: (1) Stand up PKI in test environment. (2) Issue test certificates, verify trust chain on pilot machines. (3) Push Root CA cert via GPO to all machines. (4) Begin replacing self-signed certs server by server, starting with the most-visited internal services. (5) After 90 days, configure browsers to reject self-signed certs on internal networks — employees can no longer bypass warnings. (6) Audit quarterly.

Warning fatigue: Communicate to employees that "you should now NEVER see a certificate warning on internal sites — if you do, report it immediately as a potential MITM attack." This converts the warning from ignored noise back into a meaningful security signal.

← Exam: Ch 12–15 All Chapters Exam: Ch 19–25 →

—

Pass threshold: 80% (16 / 20 correct)

← Ch 12–15 Exam All Chapters Ch 19–25 Exam →

Exam: Integrity, Trust & Verification