Question 482 of 1,152

General Security Concepts →hardMultiple SelectObjective-mapped

Quick Answer

The answer is to use separate signing keys for each product line or release environment and to store the private key in a non-exportable hardware security module (HSM). This combination directly reduces cryptographic risk because an HSM ensures the code signing key protection is hardware-bound and never resides on build servers in extractable form, so even if a server is compromised, the attacker cannot steal the key to sign malicious firmware. Meanwhile, separate keys limit the blast radius so a breach of one key does not jeopardize all releases. On the Security+ SY0-701 exam, this tests your understanding of cryptographic key management and hardware root of trust under Domain 3.0 (Cryptography). A common trap is to assume that simply encrypting the key on the server is sufficient, but the exam expects you to recognize that non-exportable HSM storage is the only way to prevent key extraction. Memory tip: “HSM keeps keys from leaving home, separate keys keep the damage alone.”

SY0-701 General Security Concepts Practice Question

This SY0-701 practice question tests your understanding of general security concepts. The scenario asks you to isolate a root cause — eliminate options that address a different problem before choosing. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.

A development team signs branch-router firmware before deployment. The same code-signing private key is stored on two build servers, and a compromise of either server would let an attacker sign malicious updates that look legitimate. Which two changes best reduce the cryptographic risk while preserving the ability to sign trusted releases? Select two.

Clue words in this question

Noticing these words before you look at the options changes how you read each choice.

Clue: "best"
Why it matters: Signals that multiple options may be partially correct. Choose the option that most directly solves the exact problem described, not the one that sounds most complete.

Question 1hardmulti select

Review the full routing breakdown →

A
Move the signing private key into a non-exportable hardware security module or managed key service.
Keeping the signing key in an HSM or managed key service prevents attackers from copying it off the server. If the build host is compromised, the attacker still cannot easily extract the private key. That preserves trusted signing while materially reducing the chance of key theft and unauthorized firmware signing.
B
Use separate signing keys for each product line or release environment to limit blast radius.
Separate keys reduce the impact of a compromise because one stolen key cannot sign every product or environment. If a single build path is abused, the attacker is constrained to a smaller trust boundary. This is a strong key-management control when operationally feasible.
C
Encrypt the build server disks with full-disk encryption so the private key stays protected.
Why wrong: Full-disk encryption protects data at rest, but it does not stop an attacker who has already compromised the running server. Once the system is booted and unlocked, the key can still be accessed by malware or an interactive intruder. It reduces theft risk, not signing-key exposure during operation.
D
Store the private key in a read-only artifact repository so all build agents can access it.
Why wrong: Putting the private key in a repository makes distribution easier, but it increases exposure dramatically. Read-only access does not matter if an attacker can clone or exfiltrate the repository contents. A private signing key should be tightly protected, not broadly shared.
E
Replace the signing process with file hashes and checksums to verify release integrity.
Why wrong: Hashes and checksums can show that a file changed, but they do not prove authenticity or source. An attacker who can replace the firmware can also replace the hash value. Digital signatures are needed when the goal is trusted origin and tamper evidence.

Full breakdown with real-world context →

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Move the signing private key into a non-exportable hardware security module or managed key service.

Option A is correct because moving the private key into a non-exportable hardware security module (HSM) or managed key service ensures the key material never resides on the build servers in a form that can be extracted. Even if a build server is compromised, the attacker cannot steal the private key to sign malicious firmware. This directly addresses the risk of key exposure from server compromise while preserving the ability to sign trusted releases through secure API calls to the HSM.

Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Move the signing private key into a non-exportable hardware security module or managed key service.
Why this is correct
Keeping the signing key in an HSM or managed key service prevents attackers from copying it off the server. If the build host is compromised, the attacker still cannot easily extract the private key. That preserves trusted signing while materially reducing the chance of key theft and unauthorized firmware signing.
Clue confirmation
The clue word "best" in the question point toward this answer.
Related concept
Read the scenario before looking for a memorised answer.
✓
Use separate signing keys for each product line or release environment to limit blast radius.
Why this is correct
Separate keys reduce the impact of a compromise because one stolen key cannot sign every product or environment. If a single build path is abused, the attacker is constrained to a smaller trust boundary. This is a strong key-management control when operationally feasible.
Clue confirmation
The clue word "best" in the question point toward this answer.
Related concept
Read the scenario before looking for a memorised answer.
✗
Encrypt the build server disks with full-disk encryption so the private key stays protected.
Why it's wrong here
Full-disk encryption protects data at rest, but it does not stop an attacker who has already compromised the running server. Once the system is booted and unlocked, the key can still be accessed by malware or an interactive intruder. It reduces theft risk, not signing-key exposure during operation.
✗
Store the private key in a read-only artifact repository so all build agents can access it.
Why it's wrong here
Putting the private key in a repository makes distribution easier, but it increases exposure dramatically. Read-only access does not matter if an attacker can clone or exfiltrate the repository contents. A private signing key should be tightly protected, not broadly shared.
✗
Replace the signing process with file hashes and checksums to verify release integrity.
Why it's wrong here
Hashes and checksums can show that a file changed, but they do not prove authenticity or source. An attacker who can replace the firmware can also replace the hash value. Digital signatures are needed when the goal is trusted origin and tamper evidence.

Common exam traps

Common exam trap: answer the scenario, not the keyword

CompTIA often tests the misconception that full-disk encryption (Option C) is sufficient to protect keys in use, when in reality it only protects data at rest and does nothing to prevent key extraction from a compromised running system.

Trap categories for this question

Command / output trap
Hashes and checksums can show that a file changed, but they do not prove authenticity or source. An attacker who can replace the firmware can also replace the hash value. Digital signatures are needed when the goal is trusted origin and tamper evidence.

Detailed technical explanation

How to think about this question

Hardware security modules (HSMs) generate and store private keys in tamper-resistant hardware, exposing only a signing interface via PKCS#11 or similar APIs. The private key never leaves the HSM, even during signing operations, so server compromise cannot extract it. In real-world scenarios, organizations like Microsoft and Google use HSMs for code signing to prevent supply-chain attacks, as seen in the 2020 SolarWinds breach where stolen signing keys allowed attackers to distribute trojanized updates.

KKey Concepts to Remember

Read the scenario before looking for a memorised answer.
Find the constraint that changes the correct option.
Eliminate answers that are true in general but not in this case.

TExam Day Tips

Watch for words such as best, first, most likely and least administrative effort.
Review why wrong options are wrong, not only why the correct option is correct.

Key takeaway

Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.

Real-world example

How this comes up in practice

A developer is choosing between AES-256 (symmetric) and RSA-2048 (asymmetric) for encrypting a large file that will be sent to a partner. Symmetric encryption is fast but requires key exchange; asymmetric is slower but solves the key distribution problem. A hybrid approach — encrypt the file with AES, encrypt the AES key with RSA — is standard. Questions like this test whether you understand when each approach applies.

What to study next

Got this wrong? Here's your next step.

Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.

Related SY0-701 practice-question pages

Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.

General Security Concepts practice questions

Practise SY0-701 questions linked to General Security Concepts.

Threats, Vulnerabilities, and Mitigations practice questions

Practise SY0-701 questions linked to Threats, Vulnerabilities, and Mitigations.

Security Architecture practice questions

Practise SY0-701 questions linked to Security Architecture.

Security Operations practice questions

Practise SY0-701 questions linked to Security Operations.

Security Program Management and Oversight practice questions

Practise SY0-701 questions linked to Security Program Management and Oversight.

Security+ social engineering questions

Practise SY0-701 questions linked to Security+ social engineering questions.

Security+ cryptography practice questions

Practise SY0-701 questions linked to Security+ cryptography.

Security+ IAM questions

Practise SY0-701 questions linked to Security+ IAM questions.

Security+ risk management questions

Practise SY0-701 questions linked to Security+ risk management questions.

Security+ incident response questions

Practise SY0-701 questions linked to Security+ incident response questions.

Security+ malware questions

Practise SY0-701 questions linked to Security+ malware questions.

Security+ vulnerability management questions

Practise SY0-701 questions linked to Security+ vulnerability management questions.

Practice this exam

Start a free SY0-701 practice session

Short sessions build daily habit. Longer sessions build exam-day stamina. Try a timed session to simulate real conditions.

10 questions 20 questions 30 questions 50 questions Timed 30

SY0-701 practice-test guide →Study guide →Browse all practice tests

FAQ

Questions learners often ask

What does this SY0-701 question test?

General Security Concepts — This question tests General Security Concepts — Read the scenario before looking for a memorised answer..

What is the correct answer to this question?

The correct answer is: Move the signing private key into a non-exportable hardware security module or managed key service. — Option A is correct because moving the private key into a non-exportable hardware security module (HSM) or managed key service ensures the key material never resides on the build servers in a form that can be extracted. Even if a build server is compromised, the attacker cannot steal the private key to sign malicious firmware. This directly addresses the risk of key exposure from server compromise while preserving the ability to sign trusted releases through secure API calls to the HSM.

What should I do if I get this SY0-701 question wrong?

Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.

Are there clue words in this question I should notice?

Yes — watch for: "best". Signals that multiple options may be partially correct. Choose the option that most directly solves the exact problem described, not the one that sounds most complete.

What is the key concept behind this question?

Read the scenario before looking for a memorised answer.

About these practice questions

Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

Keep practising

Question Discussion

Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.

Loading comments…

This SY0-701 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SY0-701 exam.