Application And Data Protection practice questions

TraceEnable Off and ServerTokens Prod

Why it fails: TraceEnable and ServerTokens harden server information disclosure and HTTP methods, not CSP or clickjacking protection.

FileETag None and Options -Indexes

Why it fails: FileETag and Options -Indexes prevent information leakage and directory listing, not XSS or framing.

SecurityHeadersEngine On followed by SetFrameOptions DENY

Why it fails: SecurityHeadersEngine is not a valid directive in standard Apache httpd configuration.

ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';

Why it fails: This syntax configures cipher suites specifically for TLS 1.2 and earlier, not TLS 1.3.

ssl_prefer_server_ciphers off; combined with MD5

Why it fails: MD5 is cryptographically broken and never used in modern secure TLS configurations.

ssl_cipher_suites 'TLS_RSA_WITH_AES_128_CBC_SHA';

Why it fails: This is an insecure legacy cipher suite and is explicitly prohibited in TLS 1.3.

CREATE ENCRYPTED TABLE employee (ssn VARCHAR2(11)) STORAGE ENGINE INNODB_TDE;

Why it fails: INNODB_TDE is associated with MySQL/MariaDB, not Oracle Database.

CREATE TABLE employee (ssn VARCHAR2(11) ENCRYPT USING 'AES256' IDENTIFIED BY master_key);

Why it fails: 'IDENTIFIED BY master_key' is not valid syntax for Oracle column encryption.

ALTER DATABASE ENCRYPT COLUMN ssn WITH ALGORITHM = 'AES256';

Why it fails: Column encryption is defined at table creation or table alteration, not database scope.

Stored Cross-Site Scripting (Stored XSS)

Why it fails: Stored XSS involves saving malicious payloads permanently in a database or backend storage.

Server-Side Request Forgery (SSRF)

Why it fails: SSRF involves forcing the server-side application to make HTTP requests to an arbitrary internal or external destination.

Reflected Cross-Site Scripting (Reflected XSS)

Why it fails: Reflected XSS involves the server echoing malicious input immediately within an HTTP response.

Set crossContext="true" in the Host configuration

Why it fails: crossContext allows requests to dispatch between different web applications, which can increase security risks if misconfigured.

Set debug="9" and swallowOutput="false"

Why it fails: These parameters manage logging verbosity and stdout capturing, not directory traversal prevention.

Configure Enterprise Security Manager (ESM) connector bindings

Why it fails: There is no ESM connector setting in Tomcat server.xml.

S3 Master Symmetric Key with client-side PGP encryption keys

Why it fails: S3 Master Symmetric Key is not the AWS KMS nomenclature.

External Key Store (XKS) with static key material managed on-premise without rotation

Why it fails: External keys without rotation violate the requirement for automatic annual key rotation.

AWS Managed Key with manual rotation every 90 days via CLI

Why it fails: AWS Managed Keys have automated rotation managed entirely by AWS every 3 years, not customer-configurable annually.

Broken Authentication

Why it fails: Broken authentication involves session management and credential handling failures.

Server-Side Request Forgery (SSRF)

Why it fails: SSRF involves the server making requests to an unintended external or internal URL, not interpreting user input as code.

XML External Entities (XXE)

Why it fails: XXE evaluates malicious XML external entity references within XML documents.

Insecure Deserialization

Why it fails: Insecure deserialization involves untrusted data being deserialized by an application, often leading to remote code execution.

Max-Age=31536000

Why it fails: Max-Age sets cookie persistence lifespan, which does not protect against XSS.

Domain=example.com

Why it fails: Domain defines the hosts allowed to receive the cookie, unrelated to XSS protection.

SameSite=Strict or Lax

Why it fails: SameSite mitigates Cross-Site Request Forgery (CSRF), not XSS cookie theft.

Configure share permissions on the payroll share to grant Full Control to Domain Users and rely on the NTFS permissions to restrict access.

Why it fails: Share permissions act as a secondary gate that is evaluated together with NTFS permissions, and the most restrictive effective permission wins. Granting Domain Users Full Control at the share level does not loosen the NTFS restriction, but it fails the audit requirement because share-level access is not logged as granularly as NTFS access and does not document which users were explicitly denied. Share permissions alone cannot enforce department-level restrictions when broad group access is granted.

Enable access-based enumeration on the payroll share so that users without NTFS Read permission cannot see the folder in the share listing.

Why it fails: Access-based enumeration hides files and folders that a user does not have permission to access, which improves the user experience but does not enforce authorization. A Domain User who already knows the UNC path can still attempt to open the file, and if the NTFS permission allows read access, the file will open. This setting is a visibility control, not an access control, and it does not fulfill the policy or the auditing requirement.

Enable the Windows Firewall rule for File and Printer Sharing and configure an IPsec connection security rule requiring Kerberos authentication for all SMB traffic.

Why it fails: IPsec connection security rules authenticate and encrypt SMB traffic between hosts, but they do not restrict which domain users can read individual payroll files. A Domain User who successfully authenticates with Kerberos would still be able to open the payroll share if the share and NTFS permissions allow it. This control addresses transport security, not authorization, so it does not satisfy the requirement that only Payroll and the CFO may read the files.

Set allow_url_include to Off.

Why it fails: allow_url_include controls whether PHP can include remote files over HTTP or FTP, mitigating remote file inclusion attacks. It has no effect on local files with a .php extension inside an upload folder. An attacker who uploads a local webshell would still have it executed, so this directive does not address the scenario of preventing uploaded PHP files from running.

Set disable_functions to include exec, system, and shell_exec.

Why it fails: disable_functions blocks specific internal PHP functions from being called, but it does not prevent a file with a .php extension from being parsed and executed by the PHP engine. An attacker who uploads a PHP webshell could still use other functions or language constructs to run code, so this directive does not stop arbitrary PHP file execution in an upload directory.

Set open_basedir to restrict file access to the web root.

Why it fails: open_basedir limits which directories PHP scripts can read or write using filesystem functions, which helps contain a compromised script. However, it does not stop the PHP interpreter from executing a malicious .php file that was uploaded into an allowed directory. The uploaded code would still run, just with restricted file access, so this is not the control that disables execution.

McAfee DLP Prevent

Why it fails: DLP Prevent governs data in motion at network egress points such as email and web gateways, not local USB device access on the workstation. It is the correct component when the requirement is to block sensitive content leaving the network perimeter via those channels.

McAfee ePolicy Orchestrator (ePO) Relay Server

Why it fails: The ePO Relay Server only caches and distributes policy and content updates to agents; it performs no endpoint inspection and cannot intercept USB writes. It is the correct component when the requirement is to reduce WAN load by placing update repositories near remote endpoints.

McAfee DLP Discover

Why it fails: DLP Discover scans data at rest on file shares and repositories to locate stored sensitive content; it does not monitor live device I/O or block USB writes. It is the correct component when the requirement is to inventory and classify existing data stores rather than enforce endpoint rules.

Invoke the java.net.URLEncoder.encode() method on all parameters

Why it fails: URLEncoder encodes parameters for URL transmission, not SQL syntax, so the injection payload still reaches the query. It is tempting because encoding is a familiar injection defence, and would be correct when building query strings or redirect URLs from user-supplied values.

Wrap all input strings inside single quotes and strip out semicolon characters

Why it fails: Manual quoting and semicolon stripping cannot neutralise injection through numeric contexts, comment sequences or UNION payloads; the driver still concatenates attacker-controlled text into SQL. It is tempting because escaping special characters is a recognised hardening technique, but parameterised queries via PreparedStatement bind values as data, which is the actual fix.

Sanitize all input characters using HTML entity encoding before passing them to the database driver

Why it fails: HTML entity encoding targets browser-rendered markup, not SQL grammar, so characters such as a single quote pass through unchanged and the query structure remains injectable. It is tempting because output encoding is a genuine defence against cross-site scripting, but database interactions require parameterised queries using PreparedStatement placeholders instead.

Exact Data Matching (EDM)

Why it fails: EDM matches against a pre-indexed set of known data values, so it cannot recognise arbitrary credit card numbers by format and Luhn validation. It is tempting because EDM suits protecting specific customer records or employee data, but detecting generic card formats in outbound HTTP requires a regex-based detector with checksum logic.

Indexed Document Matching (IDM)

Why it fails: IDM fingerprints whole documents and matches their content, so it cannot validate individual credit card numbers against the Luhn checksum. It is tempting because IDM suits protecting proprietary documents shared internally, but detecting formatted card numbers in HTTP traffic requires a pattern-based detector with checksum validation.

Vector Machine Learning (VML)

Why it fails: Vector Machine Learning classifies documents by statistical similarity to trained examples, so it cannot evaluate the Luhn checksum or match fixed digit patterns such as 16-digit card numbers. It suits detecting conceptually related content, for example confidential project documents lacking a defined format, where pattern and checksum matching would fail.

uricontent

Why it fails: uricontent searches the normalised URI buffer but performs case-sensitive matching, so 'Admin_Login.php' would not trigger. It is the right choice when the URI string's case is fixed. Matching 'admin_login.php' regardless of case requires content with the nocase modifier.

depth

Why it fails: Depth limits how far into the payload content matching may extend from the offset, restricting the search window rather than matching a string anywhere in the URI. It is used to bound inspection to a fixed prefix. Case-insensitive matching of 'admin_login.php' requires the nocase modifier.

offset

Why it fails: The offset modifier sets where content matching begins relative to the payload start, so it cannot match a string appearing anywhere in the URI. It is used to skip known header bytes before searching. Case-insensitive matching of 'admin_login.php' anywhere in the URI requires the nocase modifier alongside content.

pg_encrypt_cluster utility

Why it fails: No such utility exists in PostgreSQL; TDE is not implemented through a cluster encryption command. It is tempting because the name sounds like a native administrative tool, but the correct mechanism is the pg_tde extension, which performs transparent encryption of data files.

PostgreSQL Enterprise TDE Daemon

Why it fails: No PostgreSQL Enterprise TDE Daemon exists; PostgreSQL ships no such background process. It is tempting because the name mimics enterprise database encryption services, but TDE in PostgreSQL is delivered through the pg_tde extension rather than a daemon.

pg_tde core extension module

Why it fails: pg_tde is not a core PostgreSQL module; it is a separately installed extension, and the question asks for the mechanism to configure. It is tempting because pg_tde genuinely provides transparent data encryption, making it the right answer when extensions are permitted rather than core-only features.

Computer Configuration -> Windows Settings -> Security Settings -> Account Policies -> BitLocker Settings

Why it fails: Computer Configuration → Windows Settings → Security Settings → Account Policies holds password, lockout and Kerberos policy; no BitLocker node exists there. BitLocker startup PIN and TPM settings live under Administrative Templates → Windows Components → BitLocker Drive Encryption → Operating System Drives. Account Policies would be the right path for configuring domain account lockout thresholds.

Computer Configuration -> Administrative Templates -> System -> Trusted Platform Module Services

Why it fails: Trusted Platform Module Services configures TPM hardware behaviour such as command blocking and clearing, not BitLocker's startup authentication. It tempts because the scenario mentions a TPM, yet the PIN requirement sits under Windows Components > BitLocker Drive Encryption > Operating System Drives, where the correct policy path leads.

User Configuration -> Administrative Templates -> Windows Components -> Encryption -> BitLocker

Why it fails: BitLocker policies live under Computer Configuration, not User Configuration, because drive encryption applies to the machine regardless of who logs on; the User branch holds no Encryption node. It tempts administrators who recall BitLocker settings appearing in user-facing wizards, but only computer-side policy enforces startup PIN requirements.

TCP handshake stateful inspection

Why it fails: TCP handshake stateful inspection validates connection establishment and packet sequencing at layer four; it never parses HTTP request bodies, so SQL injection patterns pass through unexamined. It is tempting because stateful inspection is a genuine WAF capability, but it would be correct for blocking malformed or spoofed TCP sessions, not application-layer payloads.

Behavioral anomaly machine learning baseline profiling

Why it fails: Behavioural anomaly machine learning builds a baseline of normal traffic and flags deviations, so a novel injection payload matching no signature may be missed and legitimate-but-unusual requests may be blocked. It is tempting because ML detects unknown attacks, but it would be correct for zero-day behaviour shifts, not known SQL injection signatures.

Data Loss Prevention (DLP) pattern matching

Why it fails: DLP pattern matching inspects outbound content for sensitive data such as card numbers leaving the organisation; it does not evaluate inbound request syntax for injection payloads. It is tempting because DLP also uses pattern matching, but it would be the correct choice for preventing data exfiltration, not for dropping SQL injection requests.

Sanitize all input parameters using DOMPurify before rendering them

Why it fails: DOMPurify sanitises HTML strings to neutralise XSS payloads before DOM insertion; it does not validate object keys, so __proto__ or constructor properties still reach the administrative function. It is tempting because output sanitisation is standard for reflected input, and DOMPurify would be correct had the finding been cross-site scripting.

Configure CORS headers with Access-Control-Allow-Origin set to specific domains

Why it fails: CORS headers govern which browser origins may read responses; they do not remove attacker-controlled properties merged into object prototypes. It is tempting because CORS misconfiguration is a common web finding and restricting Access-Control-Allow-Origin would be correct if the issue were unauthorised cross-origin data access rather than prototype pollution.

Implement parameterized SQL queries for all database interactions

Why it fails: Parameterised queries bind SQL statement values, which stops injection; they do not strip inherited properties from JavaScript objects, so prototype pollution persists. It is tempting because parameterisation is the standard remedy for database-driven injection flaws and would be correct if the tester had found unsanitised SQL concatenation rather than object prototype manipulation.

Run sp_configure 'enforce network encryption', 1; on the master instance

Why it fails: No such 'enforce network encryption' option exists in sp_configure; SQL Server encrypts replica traffic by requiring the availability group's database mirroring endpoint to use encryption. Tempting because it sounds like a global switch, it would be correct only if such a server-level setting genuinely existed.

Set the database compatibility level to 150 and enable Always Encrypted with secure enclaves

Why it fails: Compatibility level and Always Encrypted with secure enclaves protect column data from the database engine and client drivers; they do not encrypt the availability group's replica-to-replica transport. Tempting as a modern encryption feature, it would be correct only for client-side column encryption, not for securing the database mirroring endpoint.

Enable Transparent Data Encryption (TDE) on the primary replica database

Why it fails: TDE encrypts data and log files at rest on disk, leaving the wire protocol between replicas unencrypted. It is tempting because it is the headline SQL Server encryption feature, but it would be correct only for protecting data files and backups, not for encrypting the mirroring endpoint traffic the scenario requires.

sudo fdisk /dev/sdb1 --encrypt

Why it fails: fdisk partitions block devices and has no --encrypt flag; it cannot initialise LUKS metadata. LUKS headers are written by cryptsetup luksFormat. fdisk is the right tool earlier, for creating the /dev/sdb1 partition itself, which is why it appears plausible here.

sudo mkfs.ext4 -e encrypted /dev/sdb1

Why it fails: mkfs.ext4 creates a filesystem and its -e option only sets post-mount error behaviour, not encryption. Running it on a raw partition writes an unencrypted ext4 filesystem, defeating the requirement. mkfs is correct only after cryptsetup luksFormat and luksOpen have produced a mapped device.

sudo mount -o encrypt /dev/sdb1 /mnt/secure

Why it fails: mount has no encrypt option; encryption is established by cryptsetup luksFormat before any filesystem is mounted. The command fails outright. Mounting is a later step, correct only after the LUKS container is opened and mapped, so it is tempting as an intuitive 'encrypt this disk' instruction.