Security Planning And Engineering practice questions

Set the application tier inbound rule to allow TCP 8080 from 0.0.0.0/0.

Why it fails: Allowing traffic from 0.0.0.0/0 violates the principle of least privilege by exposing the application tier to the entire internet rather than restricting access solely to the web tier. This configuration is tempting because it is the standard approach for public-facing services, such as a web server intended to serve global users via HTTP or HTTPS. In such public scenarios, permitting unrestricted inbound traffic is a functional necessity, but it remains a security failure when applied to internal tiers requiring strictly controlled, private communication.

Use an IP-based rule in the application tier Security Group referencing the private IP of the web tier instances.

Why it fails: Hardcoding private IP addresses fails because AWS instances are ephemeral; when instances scale or restart, their IP addresses change, rendering static rules obsolete and causing connectivity outages. This approach is tempting for legacy on-premises environments where network infrastructure remains static and IP-based access control lists are the primary mechanism for traffic filtering. In such traditional data centres, referencing specific IP addresses provides granular control, but in dynamic cloud architectures, security groups should instead reference the security group ID to maintain persistent, identity-based access.

Set the application tier inbound rule to allow TCP 8080 from the CIDR block of the VPC.

Why it fails: Allowing the whole VPC CIDR on port 8080 permits any VPC resource, not just the web tier, so it fails least privilege and Defence in Depth. It is tempting because VPC-scoped rules are easy to manage, but the correct approach references the web tier's security group as the source, restricting traffic to that tier alone.

Redirect all logs to a local write-only file system on each server.

Why it fails: Relying on local write-only file systems isolates security events directly on the target hosts, creating a severe single point of failure where a compromised administrator or host-level rootkit can manipulate or delete audit trails without detection. This approach is tempting because it satisfies basic compliance frameworks demanding tamper-resistance via write-once-read-many (WORM) constraints and prevents accidental local deletion by routine users. It represents a valid mitigation strategy exclusively within isolated, air-gapped environments lacking network connectivity to a centralised Security Information and Event Management (SIEM) architecture.

Disable unnecessary services to reduce the attack surface.

Why it fails: Hardening is a valid security practice, but it does not satisfy the requirement for audit logging.

Require manual review of system event logs by administrators weekly.

Why it fails: Manual processes are prone to error and do not meet the timeliness requirements for monitoring.

Use a shared secret between the IdP and SP.

Why it fails: A shared secret between the Identity Provider and Service Provider utilises symmetric cryptography (such as HMAC), which requires both entities to possess the identical key. This fails in SAML 2.0 architectures because any party holding the key can forge assertions, destroying non-repudiation between distinct administrative domains. Symmetric keys are tempting because they are commonly used for token validation in protocols like OAuth or OpenID Connect with confidential clients. They would be the correct choice within a closed ecosystem under a single trust authority where the token issuer and consumer are the exact same administrative entity, rather than federated partners requiring asymmetric digital signatures.

Use HTTPS with TLS 1.3 for transport.

Why it fails: Transport layer security protects data in transit against interception and eavesdropping between the browser and identity provider, making it tempting because administrators rely on it for secure web communications. However, relying solely on TLS fails to prevent SAML assertion tampering because it terminates at each endpoint, leaving the XML payload vulnerable to intermediate manipulation once decrypted. XML digital signatures and encryption protect the actual assertion payload end-to-end, whereas transport encryption merely secures the communication channel itself.

The Service Provider must encrypt the assertion.

Why it fails: Encryption protects the confidentiality of SAML assertions from eavesdroppers during transit over insecure channels, whereas the preservation of integrity against tampering specifically requires a digital signature. This option is tempting because encryption involves cryptographic keys and security mechanisms, making it a common point of confusion for those conflating secrecy with integrity. Encrypting the assertion would indeed be the correct choice if the objective were to prevent unauthorized viewing of sensitive attributes contained within the payload by intermediary networks, but it does not inherently guarantee that the assertion has not been maliciously altered.

Use a single global admin account for all tenants.

Why it fails: Consolidating access under a single global administrator account violates multi-tenancy principles because it completely eliminates tenant-level boundaries, granting any compromised credential or rogue administrator unchecked access across every isolated database and tenant space. Administrators often default to a shared global account during early development phases to simplify broad infrastructure management and streamline cross-tenant deployment scripts. In single-tenant legacy applications or centralized enterprise utilities where a solitary administrative trust domain is strictly required, a global administrative scope is the appropriate choice for managing overarching infrastructure.

Rely on application-level filtering.

Why it fails: Application-level filtering relies on software logic, such as `WHERE tenant_id = current_tenant` clauses in database queries, to segregate data within a shared schema. This approach fails in multi-tenant cloud architectures because a single coding defect, SQL injection vulnerability, or misconfigured API parameter bypasses the filter entirely, exposing cross-tenant data. Developers are often tempted to use this method because it simplifies database provisioning and reduces infrastructure costs by avoiding dedicated storage per tenant. It is a valid and efficient design pattern only within single-tenant applications requiring logical partitioning for internal business units, where security isolation is not a regulatory or architectural mandate.

Use a shared database with a common schema for all tenants.

Why it fails: Relying on a shared database schema with row-level security creates catastrophic multi-tenant vulnerability by depending entirely on application-layer query filters and database logic to segregate data, which fails catastrophically if an access control flaw or SQL injection emerges. This pooled architecture is tempting because it minimises resource overhead, simplifies database administration, and lowers hosting costs. It represents the correct choice for cost-constrained software-as-a-service applications with low-risk data where strict cryptographic or physical separation is unnecessary and resource pooling dictates operational viability.

Enable 'Block Public Access' and ACLs.

Why it fails: Enabling ACLs facilitates granular object-level permissions, which contradicts the requirement to enforce a unified bucket-wide restriction against public access. While this configuration is tempting because it provides legacy access control mechanisms for individual objects, it fails to address the VPC-specific connectivity requirement. You would use ACLs only when you need to grant specific permissions to individual objects within a bucket that requires non-standard access patterns, rather than establishing a network-perimeter boundary defined by a VPC endpoint policy.

Create an IAM role for every user in the VPC.

Why it fails: Managing individual IAM roles for every user creates an unmanageable administrative burden that fails to address the bucket-level network perimeter requirement. While this approach provides granular identity-based access control for specific users, it ignores the necessary S3 bucket policy condition that restricts traffic based on the VPC endpoint or source IP. This mechanism is intended for scenarios requiring fine-grained permission sets for distinct human or service identities, such as integrating with Microsoft Entra ID for federated authentication across diverse cloud environments.

Use an S3 Pre-signed URL.

Why it fails: Pre-signed URLs grant time-limited access to specific objects for unauthenticated users, failing to enforce the requirement for persistent, VPC-bound network perimeter security. While this mechanism effectively delegates temporary retrieval permissions to third parties without requiring them to possess IAM credentials, it bypasses the network-level access controls mandated by the scenario. It is intended for scenarios requiring granular, ad-hoc object sharing rather than establishing a permanent, secure connection between a private VPC and an S3 bucket via VPC endpoints.

Storing data only in the local cache.

Why it fails: Relying solely on local cache fails to provide the persistent, centralised encryption and integrity verification required for high-impact systems, as cache is volatile and lacks the robust access control enforcement mandated by NIST SP 800-53. This approach is often confused with performance optimisation strategies, where caching is utilised to reduce latency for frequently accessed data. While caching improves throughput in transient operational scenarios, it does not constitute a comprehensive data-at-rest protection strategy for long-term storage security.

Disabling all audit logging.

Why it fails: Disabling audit logging directly violates the NIST SP 800-53 requirement for continuous monitoring and accountability, which is mandatory for high-impact systems to ensure forensic traceability of data access. While administrators occasionally disable logging to minimise performance overhead or reduce storage consumption in non-production environments where audit trails are not a regulatory concern, this action creates a critical security gap. In a high-impact system, such an omission prevents the detection of unauthorised data exfiltration or tampering, rendering the system non-compliant with federal security standards.

Using cleartext storage for performance.

Why it fails: Cleartext storage violates the fundamental NIST SP 800-53 requirement for cryptographic protection of data at rest, which mandates confidentiality controls to prevent unauthorised access to sensitive information on physical media. While omitting encryption reduces CPU overhead and latency, thereby enhancing raw input/output performance for high-throughput transactional systems, this approach is only acceptable in environments where the data is non-sensitive or protected by alternative physical security measures. Relying on cleartext in a high-impact system exposes data to direct compromise should the underlying storage medium be accessed.

Physical.

Why it fails: Physical is a family, not a primary category in this context.

Financial.

Why it fails: Budgets and monetary resource allocations belong to business administration rather than information security governance, making monetary metrics irrelevant to the technical taxonomies defined in NIST SP 800-53. This distracts candidates because risk management frameworks routinely quantify financial impact during cost-benefit analyses and capital planning exercises. Such economic evaluations would be the correct choice when justifying security investments or calculating the return on mitigation strategies to executive leadership, rather than classifying technical safeguard types.

Ignoring error logs.

Why it fails: Ignoring error logs prevents administrators from identifying early warning signs of hardware degradation, transaction bottlenecks, or underlying software bugs that threaten database uptime. Conversely, this practice is sometimes utilised in high-throughput development environments during stress testing to prevent storage exhaustion caused by excessive verbosity, or when dealing with known, non-critical warning messages that have been triaged and documented, allowing engineers to focus on active incident response without distraction.

Running the database on a single server.

Why it fails: Relying on a single server introduces a critical single point of failure, meaning any hardware fault, operating system crash, or routine maintenance will cause an immediate outage that violates high availability requirements. This configuration is typically utilised in isolated development or testing environments where minimal cost and simplified local administration take precedence over operational continuity. In those non-production scenarios, avoiding the complexity of clustering or replication makes single-server deployment the ideal choice.

The history of the company logo.

Why it fails: Corporate branding elements and graphical assets serve aesthetic and marketing functions to establish visual identity across public-facing materials, meaning they possess zero technical utility during a live security breach or containment procedure. While a comprehensive disaster recovery binder or public relations crisis playbook might occasionally reference brand guidelines to ensure consistent messaging when issuing external breach notifications to stakeholders, historical artwork has no functional role in technical containment, forensic data collection, or system restoration workflows.

The CEO's personal home phone number.

Why it fails: Including the Chief Executive Officer's personal home phone number fails because an Incident Response plan requires structured operational and technical escalation paths—such as designated technical leads, forensic teams, and defined notification frameworks—rather than ad-hoc executive contact details that bypass established triage procedures. This item is tempting because high-profile security events demand executive notification, making personal reach-out details appear necessary for governance oversight. It would be the correct choice within a strategic crisis communication framework or executive escalation policy designed for catastrophic enterprise-wide events requiring immediate C-suite authorisation.

Use AWS Trusted Advisor to identify unused IAM credentials.

Why it fails: AWS Trusted Advisor provides passive reporting on security hygiene rather than enforcing active access restrictions, failing to meet the automated enforcement requirement of AC-6. While it effectively identifies stale credentials or over-privileged entities to assist with periodic access reviews and compliance auditing, it lacks the capability to programmatically restrict permissions. Administrators rely on this tool for visibility during manual remediation workflows, but it cannot dynamically modify IAM policies or deny access requests in real-time to maintain least privilege.

Enable AWS CloudTrail organization-level logging.

Why it fails: CloudTrail logging functions as an audit mechanism for monitoring API activity rather than an enforcement engine for access control policies. While it provides visibility into user actions, it does not restrict permissions or automate the principle of least privilege. This option is tempting because it satisfies AC-2 and AU-2 controls related to accountability and auditing, making it the correct choice when the requirement focuses on forensic analysis or detecting unauthorized configuration changes within an AWS environment.

Implement AWS Config rules for S3 bucket public access blocks.

Why it fails: While this enforces security, it targets data storage access rather than general least privilege for user accounts.

Configure Microsoft Defender for Cloud to trigger an alert on insecure storage.

Why it fails: Triggering a security alert fails this scenario because it merely detects non-compliant configurations after deployment rather than actively preventing or remediating them at the point of creation, which violates the strict enforcement mandate. This approach is tempting because Microsoft Defender for Cloud provides continuous monitoring and posture management to visibility-focused security teams. It would be the correct choice when the operational goal is to audit existing resources and alert administrators to vulnerabilities rather than enforce immediate, blocking compliance guardrails.

Set up a Logic App to delete non-compliant storage accounts.

Why it fails: While functional, it is not the standard architectural approach for policy enforcement compared to Azure Policy.

Use Azure Blueprint to deploy a hardened ARM template.

Why it fails: Azure Blueprints operates as a declarative mechanism for orchestrating the initial deployment of resource templates, role assignments, and policies across subscriptions, yet it lacks continuous evaluation capabilities to remediate non-compliant configurations introduced post-deployment. This approach is tempting because it bundles governance artefacts and Azure Resource Manager templates into a single version-controlled package, making it the correct choice for bootstrapping fully provisioned, greenfield subscription environments that require strict initial compliance baselines upon creation.

Denial of Service

Why it fails: Lack of mutual TLS exposes a communication path to eavesdropping and interception, violating confidentiality and integrity rather than availability, which rules out disruption of service mechanisms. This option is tempting because resource exhaustion or flooding attacks can occasionally manifest as severed communication channels or disrupted service availability. However, encryption and authentication failures specifically compromise data transit security, whereas Denial of Service addresses resource throttling, bandwidth consumption, or application crashes that prevent legitimate users from accessing services.

Spoofing

Why it fails: Mutual TLS provides cryptographic verification of both client and server identities, satisfying the authentication axis of the STRIDE methodology. Without mutual TLS securing the service-to-service communication path, an adversary can intercept traffic or impersonate legitimate endpoints, directly enabling identity spoofing. Because the architecture fails to validate participating entities cryptographically, the vulnerability undermines the fundamental trust boundary required to verify who is communicating, making Spoofing the accurate classification for this omission.

Elevation of Privilege

Why it fails: Lack of mutual TLS represents an absence of cryptographic verification and payload protection over the network, which maps directly to Spoofing and Information Disclosure rather than authorising actions beyond a user's current rights. Elevation of Privilege is tempting because unauthenticated network paths often precede lateral movement where an attacker assumes a higher role. It would be the correct choice if a compromised service process exploited improper access controls, local privilege bugs, or insecure direct object references to execute administrative functions locally or via an API without adequate role authorisation.

NIST SP 800-53, Security and Privacy Controls for Information Systems and Organizations

Why it fails: NIST SP 800-53 provides a comprehensive catalog of security and privacy controls, but it is not the DoD-specific overlay that tailors those controls for systems processing CUI. For DoD systems, the ISSEP must apply the DoD implementation of NIST SP 800-171, which is CNSSI 1253 or the DoD Cloud Computing SRG depending on the environment. Using SP 800-53 alone would miss DoD-specific parameters and assumptions.

NIST SP 800-171, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations

Why it fails: NIST SP 800-171 is the baseline for protecting CUI in nonfederal systems, but for a DoD system, the ISSEP must use the DoD-specific implementation. The DoD has issued its own overlay and assessment procedures that tailor SP 800-171 for DoD systems. Using SP 800-171 directly would omit DoD-specific requirements and assessment guidance.

CNSSI 1253, Security Categorization and Control Selection for National Security Systems

Why it fails: CNSSI 1253 applies to National Security Systems (NSS), not to all DoD systems processing CUI. While it provides control overlays and guidance, it is specifically for systems that handle classified or national security information. A system processing CUI that is not an NSS would not use CNSSI 1253 as its primary control selection document; it would use the DoD CUI overlay.

A shared storage area network (SAN) volume mounted read-only by both enclaves

Why it fails: A shared SAN volume, even when mounted read-only, creates a bidirectional storage channel and allows the lower enclave to be influenced by data written by the higher enclave through metadata and side channels. It does not enforce a release policy and violates the requirement for a controlled, policy-mediated information flow between the two enclaves.

TLS 1.3 mutual authentication between a client in each enclave and a shared broker

Why it fails: Mutual TLS authenticates the endpoints and encrypts the channel, but it does not evaluate the content or enforce an information flow policy. Both enclaves can still exchange arbitrary data through the broker, and a compromised endpoint could release data that the policy would prohibit, so TLS alone does not satisfy the cross-domain requirement.

A demilitarized zone (DMZ) built from general-purpose servers with host-based intrusion prevention systems

Why it fails: A DMZ of general-purpose servers with host-based IPS provides defense in depth but does not enforce a deterministic information flow policy. The host operating systems and applications can be subverted, and there is no guarantee that only approved data types cross the boundary, so this design does not meet the strict cross-domain flow requirement.

Encryption of data at rest in the cloud provider's storage

Why it fails: While the organization may be responsible for encrypting its own data, the cloud provider often offers encryption at rest as a service. In IaaS, the organization must configure encryption for its volumes and storage. However, the physical storage encryption may be provider-managed. The question asks for responsibilities that remain with the organization; encryption of data at rest is a shared responsibility, but the provider often provides the underlying encryption. The organization must ensure it is enabled and keys are managed. However, patch management and network security group configuration are clearly organizational. This option is less definitive as a sole organizational responsibility because the provider may handle the encryption mechanism.

Management of the hypervisor

Why it fails: Management of the hypervisor is a cloud provider responsibility in IaaS. The provider controls the virtualization layer and ensures its security. The organization does not have access to the hypervisor. NIST SP 800-171 controls related to the hypervisor are inherited from the provider. Therefore, this is not an organizational responsibility.

Physical security of the data center

Why it fails: Physical security of the data center is the responsibility of the cloud provider under IaaS. The provider secures the facilities, hardware, and infrastructure. The organization does not control physical access. NIST SP 800-171 requirements for physical protection are inherited from the provider. Therefore, this is not an organizational responsibility in IaaS.

Establish and maintain a security awareness and training program.

Why it fails: Security awareness and training (3.2.1) is an important administrative control, but it does not directly protect CUI at rest or in transit. It addresses the human element, whereas the question asks for requirements most directly related to technical protection of data at rest and in transit. Therefore, it is not the best choice.

Encrypt CUI on mobile devices and mobile computing platforms.

Why it fails: While encryption of CUI on mobile devices is a requirement in NIST SP 800-171 (3.1.19), it is specific to mobile devices and not the most directly related to protecting CUI at rest and in transit in a cloud-hosted system. The question asks for requirements most directly related to protecting CUI at rest and in transit generally, which are covered by other controls.

Control and manage the use of social media and networking sites.

Why it fails: Controlling social media use is not a specific NIST SP 800-171 requirement and is not directly related to protecting CUI at rest or in transit. While it may be part of an acceptable use policy, it does not address the technical safeguards needed for data protection. Thus, it is not a correct choice.

Use parameterized queries for all database access within each service.

Why it fails: Parameterized queries are effective for preventing SQL injection within a service's database interactions, but they do not address other injection types such as XML injection, LDAP injection, or command injection that can occur at service boundaries. The question asks for a design approach that mitigates injection across service boundaries, so a broader solution is needed.

Require each service to implement its own input validation using a common library.

Why it fails: Requiring each service to implement its own input validation using a common library can lead to inconsistencies and gaps, especially if services are developed by different teams or if the library is not uniformly applied. While it is good practice, it does not provide the centralized enforcement and consistency that an API gateway offers, making it less effective for cross-service injection mitigation.

Encrypt all service-to-service communication using TLS 1.3.

Why it fails: TLS 1.3 encryption protects data in transit from eavesdropping and tampering, but it does not prevent injection attacks because the malicious payload is encrypted and then decrypted at the service, where it can still be executed. Encryption is a confidentiality and integrity control, not an input validation control, so it does not mitigate injection risks.

The POA&M is created after authorization and only includes weaknesses that were not remediated before the authorization decision.

Why it fails: The POA&M is not created after authorization; it is developed and maintained throughout the RMF process. While it may include weaknesses that remain at the time of authorization, it also tracks those identified earlier. Waiting until after authorization would delay remediation and obscure the risk picture for the authorizing official, so this statement is incorrect.

The POA&M is created during the Assess step and documents all identified vulnerabilities for remediation.

Why it fails: The POA&M is not created solely during the Assess step; it is initiated earlier and updated throughout the RMF. While it documents weaknesses, its primary purpose is not just to list vulnerabilities but to track planned remediation actions, milestones, and resources. The Assess step produces assessment results that inform the POA&M, but the POA&M itself is a living document that begins before assessment.

The POA&M is developed during the Select step and identifies controls that cannot be implemented.

Why it fails: The POA&M is not developed during the Select step. The Select step focuses on choosing controls and tailoring them. The POA&M is typically initiated during the Implement step or earlier, as weaknesses are identified, and it documents how and when those weaknesses will be addressed. It is not limited to controls that cannot be implemented; it covers any deficiencies found.

Expose the Root CA via a restricted management port in the firewall.

Why it fails: Exposing a Root Certificate Authority through a restricted firewall management port violates the core security requirement to keep the root completely air-gapped, leaving the private key vulnerable to remote network exploitation. This approach is tempting because firewall rule sets and remote administration ports are standard mechanisms for managing networked servers and facilitating automated certificate enrolment workflows. In less sensitive environments requiring frequent certificate issuance without an offline hierarchy, remote management ports permit administrators to process subordinate requests without physically transporting media.

Configure a secure VPN tunnel between the Subordinate CA and the Root CA to exchange the CSR.

Why it fails: A VPN tunnel still requires the Root CA to be online and reachable, defeating the offline requirement; the CSR must be moved by removable media with manual signing. VPN transport suits distributed CAs that must communicate continuously, not an air-gapped root whose private key must never touch a network.

Use an HSM to automatically sign the request from the Subordinate CA.

Why it fails: Automating the signing process via a Hardware Security Module exposes the Root Certificate Authority to network connectivity, violating the strict offline isolation required for highly classified Public Key Infrastructure hierarchies. While this approach is tempting because Hardware Security Modules securely store private keys and streamline certificate issuance for high-availability environments, it would only be the correct choice for an online intermediate or subordinate CA where automated operational efficiency outweighs the need for absolute air-gapped protection.

Client Credentials Flow.

Why it fails: Native mobile applications cannot securely store client secrets, making the Client Credentials flow unsuitable because it requires the client to authenticate using a secret known only to the application. This flow is intended for machine-to-machine communication where a backend service acts on its own behalf without user interaction. In scenarios such as a daemon process or a scheduled task authenticating against Microsoft Entra ID, this flow provides the necessary service-level authorisation, but it lacks the user context required for mobile application access.

Resource Owner Password Credentials Flow.

Why it fails: Resource Owner Password Credentials requires the native app to handle the user's raw password, exposing credentials to the client and precluding MFA or consent. Authorisation Code with PKCE keeps credentials at the authorisation server. ROPC suits trusted first-party legacy migrations only, not mobile clients.

Implicit Flow.

Why it fails: The Implicit Flow exposes access tokens directly within the URI fragment, creating significant interception risks for mobile applications that lack secure browser isolation. While this flow was historically designed for browser-based single-page applications to avoid cross-origin resource sharing limitations, it is now deprecated by current OAuth 2.1 best practices. Organisations using Microsoft Entra ID should instead utilise the Authorisation Code Flow with PKCE, which binds the token exchange to a cryptographically secure proof-of-possession mechanism, ensuring tokens remain protected from malicious interception.