Hard Difficulty Questions

Deploying VLANs to separate cardholder data from other traffic

Why wrong: VLANs provide segmentation but are less dynamic and granular than microsegmentation.

Using network access control (NAC) to enforce endpoint compliance

Why wrong: NAC controls access but does not provide the necessary segmentation for PCI DSS scope reduction.

Placing all systems that process cardholder data in a DMZ

Why wrong: DMZ is for external-facing systems, not appropriate for all cardholder data environments.

Role-based authentication only

Why wrong: Role-based is acceptable, but identity-based is more specific and required for Level 3; but the question asks for TWO features, and role-based alone is not enough.

Ability to export keys in plaintext

Why wrong: Exporting plaintext keys would violate the security policy.

Tamper resistance with automatic zeroization

Why wrong: Tamper resistance with zeroization is a Level 4 requirement.

Disable SELinux entirely

Why wrong: Disabling SELinux removes all protections, which is insecure.

Restart the httpd service

Why wrong: Restarting does not change SELinux policy; the denial will persist.

Change the SELinux enforcing mode to permissive

Why wrong: Permissive mode disables enforcement but is a temporary workaround, not a proper resolution.

Remove the trust entirely and use individual local accounts

Why wrong: This would break the access requirement and is not a security-architecture decision.

Configure the trust to use forest-wide authentication instead of selective

Why wrong: Forest-wide authentication grants broader access, increasing risk.

Enable SID filtering on both forest trusts

Why wrong: SID filtering prevents elevation of privilege but does not limit which accounts can authenticate; selective authentication is more granular.

Disable root login inside the container by modifying /etc/passwd

Why wrong: Disabling root login does not prevent the container process from running as root; the process still has root privileges.

Use a read-only root filesystem for the container

Why wrong: A read-only filesystem limits writes but does not reduce privileges; the container still runs as root.

Enable SELinux or AppArmor on the host

Why wrong: These are mandatory access control mechanisms that can confine a process, but they do not directly address the root privilege issue; combining with non-root user is better.

It is based on the AES algorithm

Why wrong: ChaCha20 is not related to AES; it is a different design.

It requires padding to achieve correct block sizes

Why wrong: Stream ciphers do not require padding.

It is a block cipher

Why wrong: ChaCha20 is not a block cipher; it operates on 64-byte blocks but is a stream cipher.

Restore systems from clean backups

Why wrong: Restoration is part of recovery, not eradication.

Conduct a lessons learned meeting

Why wrong: Lessons learned is the final phase, not eradication.

Using signature-based intrusion detection systems (IDS) to match known attack patterns.

Why wrong: Signature-based detection fails against zero-day exploits and custom malware used by APTs.

Deploying honeypots to attract and analyze attacker behavior.

Why wrong: Honeypots can be useful but are not a primary detection technique; they are more for research and deception.

The firmware is not encrypted

Why wrong: Signing ensures integrity and authenticity; encryption is not required for firmware updates.

The signature algorithm is obsolete

Why wrong: RSA itself is not obsolete; it is the key length that is the issue.

The signing key is not rotated

Why wrong: Key rotation is a best practice but not the primary concern; the weak key length is more urgent.

Run antivirus scans on the disk image.

Why wrong: Antivirus may not detect advanced rootkits and the OS could be compromised.

Compare registry snapshots before and after infection.

Why wrong: Rootkits can hide registry keys, and the registry may be compromised.

Analyze network packet captures for C2 traffic.

Why wrong: Network analysis may not directly reveal kernel-mode rootkits.

Manual review of compliance reports quarterly

Why wrong: Quarterly manual review is not continuous.

Deploying a Security Information and Event Management (SIEM) system

Why wrong: SIEM is for security monitoring, not specifically compliance monitoring.

Annual external audits

Why wrong: Annual audits are periodic, not continuous.

Extend the session token expiration time to reduce the frequency of re-authentication

Why wrong: Longer token lifetimes increase the window for token theft and misuse.

Replace token-based authentication with certificate-based authentication and revoke certificates based on device posture

Why wrong: Replacing token-based authentication with certificate-based authentication does not address the specific problem of session tokens being revoked after a short idle timeout, because certificates themselves do not manage session persistence—they are a credential for initial authentication, not a mechanism to extend token lifetime or adjust idle session policies. This option is tempting because certificate-based authentication can enforce device posture checks at each access request, which aligns with zero-trust continuous verification; it would be the correct choice if the goal were to tie access to real-time device health rather than to resolve frequent re-authentication caused by an overly aggressive idle timeout.

Reduce the number of authentication factors required for re-authentication

Why wrong: Reducing factors weakens security and violates zero-trust principles.

Replace the TLS encryption with IPsec VPNs and use a third-party key management appliance in each region

Why wrong: Unnecessary complexity; TLS is sufficient and IPsec may increase latency.

Move all applications to a single region to simplify key management and use a single shared load balancer

Why wrong: Eliminates disaster recovery and increases risk of regional failure.

Use client-side encryption with keys stored in the application code and disable the health checks entirely

Why wrong: Storing keys in code is insecure; disabling health checks may cause availability issues.

Right to unlimited data storage

Why wrong: No such right; storage must be limited to purpose.

Right to data monetization

Why wrong: No such right exists under GDPR.

Signature-based detection using file hashes

Why wrong: Ransomware variants change hashes frequently, so signatures are less effective.

Allowlisting of trusted applications

Why wrong: Allowlisting would prevent unknown executables but may not stop script-based ransomware.

Network traffic analysis to detect C2 communication

Why wrong: C2 detection is useful but not specific to the encryption behavior.

The agency no longer needs to conduct any risk assessments

Why wrong: Agency retains responsibility

The CSP guarantees 100% security

Why wrong: No guarantee

The system automatically complies with all international regulations

Why wrong: Only FedRAMP

The token is not encrypted

Why wrong: JWT payload is base64-encoded, not encrypted, but that is intended; the shared key is the bigger risk.

The token does not include audience claim

Why wrong: Missing audience claim is a concern but less critical than shared keys.

Token expiration is not set

Why wrong: While expiration is important, the shared key issue is more severe.

Performance overhead of the custom algorithm

Why wrong: While performance may be a concern, the security principle prioritizes using vetted algorithms over custom ones.

Insufficient key length used in the algorithm

Why wrong: Key length could be insufficient, but the root issue is the algorithm itself, not the key length.

Incompatibility with modern browsers

Why wrong: Browser compatibility is irrelevant; custom algorithms are not used in standard TLS.

Inline proxy

Why wrong: Inline proxies require traffic interception and may not decrypt without client certificates.

Forward proxy

Why wrong: Requires client configuration and traffic redirection.

Reverse proxy

Why wrong: Requires DNS changes and traffic routing.

Runtime Application Self-Protection (RASP)

Why wrong: RASP protects applications at runtime but does not identify library vulnerabilities pre-deployment.

Static Application Security Testing (SAST)

Why wrong: SAST analyzes source code for security flaws but does not focus on open-source library vulnerabilities.

Dynamic Application Security Testing (DAST)

Why wrong: DAST tests running applications from the outside; it does not analyze library dependencies.