Chapters 6–11 Practice Exam
Time remaining
30:00
Part A — Multiple Choice (Questions 1–20)
Ch 6 · Zero Trust
Question 1 of 20
The Zero Trust principle of "never trust, always verify" means what for users who are already on the internal corporate network?
✅ C. Zero Trust eliminates implicit trust based on network location. Being "inside the network" grants nothing — every access request to every resource is evaluated as if the requester is untrusted. The perimeter model (A) is what Zero Trust replaces. Continuous verification evaluates identity, device health, context, and behavior on every request.
Ch 6 · Zero Trust
Question 2 of 20
In a Zero Trust architecture, a user's access request reaches a component that intercepts the request, consults the policy engine, and either forwards or blocks the request based on the policy engine's decision. What is this component called?
✅ B — Policy Enforcement Point (PEP). The PEP sits in the access path and enforces the decision. The Policy Decision Point (PDP) — also called the policy engine — is what DECIDES (allow/deny) based on rules, identity, device health, and context. The PEP intercepts traffic and acts on that decision. They are separate components: PDP = brain, PEP = muscle.
Ch 6 · Zero Trust
Question 3 of 20
An organization restructures its network so that the finance database can only communicate with the specific finance application server — no other system on the internal network can reach the database directly, even servers on the same IP subnet. What Zero Trust technique is this?
✅ C — Microsegmentation. Microsegmentation creates granular, workload-level segments — enforcing that only specifically authorized communication paths exist between specific systems, even within the same physical network. Traditional segmentation puts systems in VLANs; microsegmentation goes further — restricting specific flows at the individual workload level. This limits lateral movement if an attacker compromises any single system.
Ch 7 · Physical Security
Question 4 of 20
A data center entrance consists of two doors separated by a small enclosed chamber. Only one door can open at a time, and a security officer must verify identity before the second door unlocks. What is this physical security control called?
✅ B — Mantrap (airlock). A mantrap (also called an airlock) is a double-door entry system that prevents tailgating — only one person can pass through per authentication event, and both doors cannot be open simultaneously. It prevents an attacker from simply following an authorized person through a badge-controlled door. Bollards (C) stop vehicle-based attacks. Faraday cages (A) block electromagnetic signals.
Ch 7 · Physical Security
Question 5 of 20
A contractor badges into a secure building and holds the door open for the next person, who doesn't badge in and slips through behind them. What physical security attack has occurred?
✅ C — Tailgating (piggybacking). Tailgating is gaining unauthorized physical access by following an authorized person through a controlled entry point. It exploits social norms (holding the door is polite). Controls: security awareness training, mantrap, turnstiles that allow only one person per badge, and camera monitoring of entry points.
Ch 7 · Physical Security
Question 6 of 20
A parking lot has security cameras installed. A vehicle break-in occurs overnight, and the footage is used to identify and prosecute the suspect the following day. What type of control are the cameras acting as in this incident?
✅ C — Detective. The cameras did not prevent the break-in — it happened anyway. They detected it by capturing evidence that was later used to identify the attacker. Note: cameras serve DUAL roles — visible cameras also act as deterrents (discouraging attacks) BEFORE an incident. But in this scenario, after the incident, their function is detective. Exam tip: identify the function in context, not just the type of control.
Ch 8 · Deception & Disruption
Question 7 of 20
A security team deploys a system intentionally configured to appear vulnerable — it mimics an unpatched legacy server with fake sensitive files. No production work runs on it. Its sole purpose is to attract attackers and monitor their techniques. What is this system?
✅ B — Honeypot. A honeypot is a single decoy system designed to attract attackers while monitoring their activity. It has no legitimate production use — any interaction with it is inherently suspicious. A honeynet (C) is a network of multiple honeypots simulating a full environment. A canary file (D) is a specific fake document placed to detect if someone is accessing files they shouldn't.
Ch 8 · Deception & Disruption
Question 8 of 20
A security operations team discovers that several workstations are infected with malware that queries a specific domain for command-and-control instructions. The team redirects all DNS queries for that domain to an internal server they control, cutting off the malware's communication channel. What is this technique called?
✅ C — DNS sinkhole. A DNS sinkhole redirects DNS queries for malicious or known-bad domains to a controlled server (often returning a loopback or internal IP). This cuts off malware from its C2 infrastructure, disrupts botnet operations, and — if the sinkhole logs connections — identifies all infected hosts that queried the domain. DNS poisoning (A) is a malicious attack; a sinkhole is a defensive technique using the same DNS redirection mechanism.
Ch 8 · Deception & Disruption
Question 9 of 20
What is the key distinction between a honeypot and a honeynet?
✅ B. Scale and realism. A honeypot is one system. A honeynet connects multiple honeypots — fake workstations, servers, databases, routers — into a believable simulated network. Attackers who spend more time in a honeynet reveal more about their tools, techniques, and objectives. Both contain no real production data or legitimate services.
Ch 9 · Change Management
Question 10 of 20
A security engineer discovers a zero-day vulnerability being actively exploited in the wild. A vendor patch is available. The organization has a formal change management process requiring Change Advisory Board (CAB) approval, which normally takes two weeks. What change classification should this use?
✅ C — Emergency change. Change management processes have an emergency change track precisely for situations like active exploitation — where waiting for the normal CAB cycle creates unacceptable risk. Emergency changes use an expedited approval process (e.g., verbal approval from CISO + CAB chair, documented retroactively). Bypassing the process entirely (D) is an unauthorized change — different from an emergency change, and a process violation.
Ch 9 · Change Management
Question 11 of 20
What is the primary purpose of a Change Advisory Board (CAB)?
✅ C. The CAB brings together stakeholders from IT, security, business, and operations to evaluate changes. They assess risk (what could break?), impact (what systems are affected?), rollback feasibility (can we undo this?), and scheduling (when is lowest-impact?). The CAB's goal is controlled, informed change — not blocking change (A) or doing the testing itself (D).
Ch 9 · Change Management
Question 12 of 20
A change is deployed to production at 2:00 AM. By 2:30 AM, three critical business applications have failed and users are reporting errors. The operations team suspects the new change caused the failures. What should they do FIRST?
✅ B — Execute the rollback plan. When a change causes immediate production failures, the first priority is restoring service — roll back to the known-good state. Investigating root cause (A) takes time the business may not have. A rollback plan must be documented and tested BEFORE deployment — this is why rollback planning is a required part of the change management process. Investigate after services are restored.
Ch 10 · Technical Change Management
Question 13 of 20
A developer makes direct changes to a production web server's configuration files without using version control or submitting a change request. Three days later, an unexplained configuration difference causes intermittent application failures. No one can identify what changed or when. What is the root cause of this situation?
✅ C. This is "configuration drift" caused by undocumented changes outside the change management process. Version control provides: a history of every change, who made it, when, and why. Without it, troubleshooting requires guesswork. Technical change management mandates that ALL configuration changes go through version control and change management — "if it's not in source control, it doesn't exist."
Ch 10 · Technical Change Management
Question 14 of 20
What is a configuration baseline in the context of technical change management?
✅ B. A configuration baseline is the approved, documented "known-good" state of a system — OS version, patches applied, services enabled, security settings, network configuration. When monitoring tools detect deviation from the baseline (configuration drift), it triggers investigation. After a failure, the baseline is what you restore to. Baselines are captured after initial secure configuration and updated only through formal change management.
Ch 10 · Technical Change Management
Question 15 of 20
An organization applies security patches during monthly maintenance windows. Before each patch cycle, they test patches in a staging environment identical to production, take VM snapshots of production systems, and document rollback procedures. Which element specifically addresses the risk that a patch breaks a production application?
✅ B. Two complementary controls address patch-breaks-application risk: (1) staging environment testing catches incompatibilities before they reach production; (2) VM snapshots enable rapid rollback if a problem makes it to production despite testing. These are the technical change management controls that make patching safe — not the schedule (A) or maintenance window length (C), which are process controls.
Ch 11 · PKI
Question 16 of 20
What is the fundamental difference between a PKI hierarchical Certificate Authority model and the PGP Web of Trust model?
✅ B. PKI: a formal hierarchy where trusted CAs (Root → Intermediate → End-entity) verify identity before issuing certificates. Trust is rooted in the CAs that OS/browser vendors have vetted. Web of Trust (PGP/GPG): no central authority — users sign each other's keys based on personal verification. Trust is based on a web of individual endorsements ("I met Alice and verified her fingerprint"). Neither requires symmetric encryption (A) — both use asymmetric keys.
Ch 11 · PKI
Question 17 of 20
A company policy requires that all employee encryption keys be stored with a designated third party so that if an employee leaves or their key is lost, encrypted data can be recovered. What is this practice called?
✅ B — Key escrow. Key escrow is the practice of storing a copy of a private key with a trusted third party for recovery purposes. Common in enterprise environments — if an employee encrypts corporate data and then leaves, the company needs to recover that data. Key escrow is controversial in consumer contexts (government access debate). Key wrapping (C) is encrypting one key with another key for secure storage/transport — different concept.
Ch 11 · PKI
Question 18 of 20
An organization's PKI uses a Registration Authority (RA). What is the RA's role in certificate issuance?
✅ C. The RA handles identity verification — the vetting step — so the CA can focus on the cryptographic signing step. In large deployments, an RA can verify identity documentation, approve or reject CSRs, and pass approved requests to the CA. The CA still does the actual signing. Separating these roles allows geographic distribution of identity verification while maintaining a central signing authority.
Ch 6 · Zero Trust
Question 19 of 20
An employee authenticated successfully this morning from their normal corporate laptop in New York. Four hours later, an access request arrives from the same account — but from an IP address in Eastern Europe, using a device that isn't in the asset inventory. In a Zero Trust model, why would this trigger additional verification or denial?
✅ B. Zero Trust uses continuous, contextual evaluation — not one-time authentication. Signals that matter: is this a known managed device? Is the location plausible given prior activity? Is the behavior consistent with the user's normal patterns? An unknown device from a distant geography hours after a legitimate login is a classic impossible travel/credential compromise scenario. A Zero Trust system would challenge for MFA, quarantine the session, or alert SIEM even though the account already authenticated.
Ch 11 · PKI
Question 20 of 20
What makes a Root CA certificate fundamentally unique compared to every other certificate in a PKI hierarchy?
✅ B. A Root CA is self-signed — it vouches for itself, which would normally be meaningless. It gains trust because OS and browser vendors manually vet and pre-install Root CA certificates into the trusted root store (a curated list). When your browser trusts DigiCert, it's because Microsoft, Apple, Mozilla, and Google have reviewed DigiCert's practices and included their root cert. Every other cert in the chain derives trust from this anchor. Root CAs are typically kept offline precisely because their compromise would be catastrophic.
Part B — Scenario Questions (unscored — self-assess)
Ch 6–8 · Scenario
Scenario Question A
A financial institution runs a classic perimeter-based network — one big flat internal network protected by a single border firewall. Their IT director argues: "Once a user is past the firewall, they're already authenticated — we don't need to verify them again internally." Last quarter, an attacker who compromised a single workstation moved laterally across the entire internal network undetected for 47 days. Using Zero Trust principles and deception technologies, describe the specific architectural and detection changes that would have limited this attack.
Zero Trust architecture changes that would have limited the attack:
Eliminate implicit internal trust: Passing the perimeter firewall grants nothing. Every internal access request — even from a corporate-joined device on the internal VLAN — must be authenticated and authorized. The compromised workstation should have triggered anomalies immediately when it started probing internal resources it never normally accesses.
Microsegmentation: Divide the flat network into workload-level segments. The finance database can only communicate with the finance application server. An HR workstation cannot initiate connections to engineering servers. Even if an attacker controls a workstation, lateral movement to other segments requires re-authentication and explicit authorization. The 47-day dwell time is possible only in a flat network where east-west traffic is unrestricted.
Continuous contextual verification: Zero Trust policy engines evaluate device health (is this endpoint compliant? any anomalous process activity?), user behavior (is this account accessing resources it never previously accessed?), and time/location anomalies. Unusual access patterns should have triggered additional verification or a security alert within hours, not 47 days.
Deception technology additions:
• Honeypots: Deploy decoy systems — a fake server labeled "payroll-db01" or "domain-controller-backup" that has no legitimate business reason for any employee to access. The first connection attempt from the compromised workstation to a honeypot would immediately alert the SOC — no false positives (legitimate users never touch honeypots).
• Canary tokens: Plant fake credential files, fake database connection strings, and fake API keys in locations where an attacker doing reconnaissance would find them. Accessing or using any of these tokens triggers an immediate alert.
• DNS sinkhole: If the malware on the workstation tried to call home to a C2 domain, a DNS sinkhole would have blocked the callback and identified the infected host immediately.
Combined effect: Microsegmentation limits where the attacker can go. Honeypots guarantee detection the moment the attacker begins internal reconnaissance. Zero Trust continuous verification flags anomalous behavior. The 47-day dwell time collapses to hours or days.
Eliminate implicit internal trust: Passing the perimeter firewall grants nothing. Every internal access request — even from a corporate-joined device on the internal VLAN — must be authenticated and authorized. The compromised workstation should have triggered anomalies immediately when it started probing internal resources it never normally accesses.
Microsegmentation: Divide the flat network into workload-level segments. The finance database can only communicate with the finance application server. An HR workstation cannot initiate connections to engineering servers. Even if an attacker controls a workstation, lateral movement to other segments requires re-authentication and explicit authorization. The 47-day dwell time is possible only in a flat network where east-west traffic is unrestricted.
Continuous contextual verification: Zero Trust policy engines evaluate device health (is this endpoint compliant? any anomalous process activity?), user behavior (is this account accessing resources it never previously accessed?), and time/location anomalies. Unusual access patterns should have triggered additional verification or a security alert within hours, not 47 days.
Deception technology additions:
• Honeypots: Deploy decoy systems — a fake server labeled "payroll-db01" or "domain-controller-backup" that has no legitimate business reason for any employee to access. The first connection attempt from the compromised workstation to a honeypot would immediately alert the SOC — no false positives (legitimate users never touch honeypots).
• Canary tokens: Plant fake credential files, fake database connection strings, and fake API keys in locations where an attacker doing reconnaissance would find them. Accessing or using any of these tokens triggers an immediate alert.
• DNS sinkhole: If the malware on the workstation tried to call home to a C2 domain, a DNS sinkhole would have blocked the callback and identified the infected host immediately.
Combined effect: Microsegmentation limits where the attacker can go. Honeypots guarantee detection the moment the attacker begins internal reconnaissance. Zero Trust continuous verification flags anomalous behavior. The 47-day dwell time collapses to hours or days.
Ch 9–11 · Scenario
Scenario Question B
A software startup has no formal change management process — developers push code directly to production, there are no scheduled maintenance windows, and rollback procedures are not documented. Last month, an undocumented configuration change caused 6 hours of downtime. They also have no PKI: all internal services use self-signed certificates, and encryption keys are stored as plaintext in configuration files on application servers. Design the minimum viable change management and key management improvements this company should implement.
Minimum viable change management improvements:
1. Version control for all configuration: Every configuration file, infrastructure-as-code template, and deployment script must live in a version control system (Git). No direct production edits. All changes are commits with author, timestamp, and message. "If it's not in source control, it doesn't exist." This alone would have solved the 6-hour downtime — the undocumented change would have been visible in the commit history.
2. Change approval workflow: All production changes go through a pull request or change ticket. Minimum: one peer review and one manager/team lead approval before merge. For infrastructure changes, a lightweight CAB (the team lead + one senior engineer) reviews before deployment. Emergency changes require verbal approval from the CTO, documented retroactively.
3. Staging environment: Production changes are deployed to staging first. Staging mirrors production configuration. If staging breaks, production is not touched. This catches 80% of change-related failures before they affect customers.
4. Rollback procedure for every change: Before deploying any change, document: "If this breaks, here is exactly how we roll back." For application deployments: tag the previous release, know the one-command rollback. For infrastructure: VM snapshots or infrastructure-as-code to redeploy previous state. The rollback plan must be tested, not assumed.
5. Maintenance windows: Schedule changes during low-traffic periods. Have on-call coverage during the window to catch and execute rollbacks immediately.
Key management improvements:
1. Eliminate plaintext keys in config files immediately: Plaintext keys in config files are a critical vulnerability — anyone who reads the file gets the keys. Minimum viable fix: use environment variables + a secrets manager (HashiCorp Vault, AWS Secrets Manager, or similar). Application retrieves the key at runtime from the secrets manager — the key is never in a file on disk.
2. Key rotation: Once keys are in a secrets manager, implement automated rotation. Application secrets should rotate at least quarterly; critical keys more frequently. The secrets manager handles rotation without application downtime.
3. Internal PKI for self-signed certificate problem: Deploy a simple internal CA (Smallstep, HashiCorp Vault PKI, or Windows Certificate Services). Distribute the internal Root CA certificate to all company devices. Internal services get CA-signed certificates instead of self-signed. Browser warnings disappear. Certificates have short lifetimes (90 days) and auto-renew. This is a single afternoon of setup for a small company, with substantial security improvement.
4. Audit and access control: Only specific service accounts should be able to retrieve specific secrets. No single developer should have access to all production keys. Log all secret access in the secrets manager — any unusual access pattern is immediately visible.
1. Version control for all configuration: Every configuration file, infrastructure-as-code template, and deployment script must live in a version control system (Git). No direct production edits. All changes are commits with author, timestamp, and message. "If it's not in source control, it doesn't exist." This alone would have solved the 6-hour downtime — the undocumented change would have been visible in the commit history.
2. Change approval workflow: All production changes go through a pull request or change ticket. Minimum: one peer review and one manager/team lead approval before merge. For infrastructure changes, a lightweight CAB (the team lead + one senior engineer) reviews before deployment. Emergency changes require verbal approval from the CTO, documented retroactively.
3. Staging environment: Production changes are deployed to staging first. Staging mirrors production configuration. If staging breaks, production is not touched. This catches 80% of change-related failures before they affect customers.
4. Rollback procedure for every change: Before deploying any change, document: "If this breaks, here is exactly how we roll back." For application deployments: tag the previous release, know the one-command rollback. For infrastructure: VM snapshots or infrastructure-as-code to redeploy previous state. The rollback plan must be tested, not assumed.
5. Maintenance windows: Schedule changes during low-traffic periods. Have on-call coverage during the window to catch and execute rollbacks immediately.
Key management improvements:
1. Eliminate plaintext keys in config files immediately: Plaintext keys in config files are a critical vulnerability — anyone who reads the file gets the keys. Minimum viable fix: use environment variables + a secrets manager (HashiCorp Vault, AWS Secrets Manager, or similar). Application retrieves the key at runtime from the secrets manager — the key is never in a file on disk.
2. Key rotation: Once keys are in a secrets manager, implement automated rotation. Application secrets should rotate at least quarterly; critical keys more frequently. The secrets manager handles rotation without application downtime.
3. Internal PKI for self-signed certificate problem: Deploy a simple internal CA (Smallstep, HashiCorp Vault PKI, or Windows Certificate Services). Distribute the internal Root CA certificate to all company devices. Internal services get CA-signed certificates instead of self-signed. Browser warnings disappear. Certificates have short lifetimes (90 days) and auto-renew. This is a single afternoon of setup for a small company, with substantial security improvement.
4. Audit and access control: Only specific service accounts should be able to retrieve specific secrets. No single developer should have access to all production keys. Log all secret access in the secrets manager — any unusual access pattern is immediately visible.