CCNA Security Planning And Engineering Questions

Isolating the asset from the network perimeter neutralises active remote attack vectors and prevents unauthorised data exfiltration during the shutdown phase, satisfying the decommissioning constraint of mitigating residual exposure before physical handling. Concurrently, updating the configuration management database (CMDB) and asset inventory ensures the logical boundary is properly recorded, eliminating orphaned DNS entries or stale routing tables that could otherwise serve as entry points for threat actors targeting unmonitored endpoints.

Identifying and categorising system vulnerabilities through STRIDE directly informs the architectural phase where mitigating controls must be implemented. Designing effective security countermeasures satisfies the essential factor of remediation, ensuring that once threats such as spoofing or elevation of privilege are modelled, appropriate defensive mechanisms like cryptographic validation and principle-of-least-privilege access controls are engineered into the system topology to neutralise those specific attack vectors.

Hardware security modules (HSMs) provide tamper-resistant storage and cryptographic processing for CA private keys, while smart cards store end-entity private keys in a secure, portable hardware token. This strategy protects keys throughout their lifecycle, from generation to destruction, and is a best practice for PKI key management. Thus, it is the correct recommendation.

A data diode uses hardware to enforce one-way data transfer, typically via an optical transmitter with no receiver on the return path. This physically prevents any data from flowing back to the high side, eliminating covert channels through the CDS itself. It is the most robust architectural approach for guaranteeing unidirectional flow between security domains of different classifications.

Providing an overarching Information Security Management System (ISMS), ISO/IEC 27001 establishes the mandatory governance framework required to manage payment cardholder data securely. For an ISSEP designing a secure payment processing system, this standard satisfies the stringent regulatory compliance constraint inherent in handling financial transactions by enforcing systematic risk assessment and continuous control monitoring. Its risk treatment processes directly validate the implementation of cryptographic controls and access governance necessary to protect sensitive authorization workflows against evolving threats.

RBAC with mutually exclusive roles enforces separation of duties by preventing a single user from holding conflicting roles, while granular permissions support least privilege by granting only the access needed for each role. This architectural control directly addresses the requirement to restrict privileges and prevent conflicts of interest within the system.

Following the Categorise step, the Risk Management Framework mandates the selection of security and privacy controls to address the identified risk profile. This sequence satisfies the constraint of the RMF lifecycle, which dictates that baseline controls must be tailored based on the system's impact level before implementation. By selecting appropriate controls, organisations ensure that security measures align with the specific sensitivity of the data processed, a process often integrated into broader identity governance strategies managed through platforms like Microsoft Entra ID.

Access control lists on boundary routers filter traffic based on IP addresses, ports, and protocols, providing a first line of defense at the network perimeter. They can block unauthorized traffic and reduce the attack surface. This is a fundamental boundary defense control that complements other perimeter defenses.

The correct approach is to leverage the cloud provider's FedRAMP authorization to inherit controls, then assess the remaining controls and authorize the organization's system. This aligns with the RMF and the concept of inheritance. The organization retains authorization authority for its system. It must document inherited controls and assess those it implements. This approach avoids duplication and ensures accountability.

Network topology diagrams visually map the physical and logical interconnections between system components, satisfying the fundamental security architecture documentation requirement for comprehensive asset visibility and boundary definition. By delineating trust zones, perimeter defenses, and data flow paths, these schematics enable security professionals to evaluate attack surfaces, implement effective segmentation, and verify compliance with defense-in-depth principles. This granular structural insight ensures that potential vulnerabilities at network junctions are accurately identified and mitigated during risk assessments.

HMAC (Hash-based Message Authentication Code) satisfies the stem requirement for data integrity during migration by combining a cryptographic hash function with a secret shared key. Unlike standard hashing algorithms that merely verify data hasn't been altered passively, an HMAC provides data origin authentication alongside integrity. This prevents malicious interception or tampering of the data stream in transit, making it the superior cryptographic method for validating that transferred files arrive in their exact original state.

A data diode or equivalent hardware enforces a physical one-way transfer, making it impossible for data to flow from the lower classification back to the higher, or for unintended leakage from higher to lower through bidirectional channels. This is the most critical principle for a cross-domain solution that must prevent data leakage; content filtering is secondary to the physical guarantee of unidirectionality.

Enforcing strict access control policies satisfies the ISO 27001 requirement for secure system engineering by implementing Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) mechanisms directly at the storage layer. This technical enforcement ensures that cryptographic keys and underlying data at rest remain inaccessible to unauthorized principals, thereby directly addressing the confidentiality constraint mandated for sensitive repositories.

Native mobile applications cannot securely maintain client secrets because attackers can easily decompile binaries to extract embedded credentials. The Authorization Code Flow combined with Proof Key for Code Exchange (PKCE) successfully satisfies this critical public client constraint by replacing the static client secret with a dynamically generated cryptographic code verifier and challenge. This mechanism prevents interception attacks on the authorization code without requiring pre-registered confidential credentials, making it the industry standard for securing OAuth 2.0 implementations on mobile devices.

This option is correct because NIST SP 800-171 requirement 3.13.1 specifically mandates monitoring, controlling, and protecting communications at external and key internal boundaries. It also requires implementing subnetworks for publicly accessible system components that are physically or logically separated from internal networks. Establishing controlled interfaces at all boundaries ensures that traffic is filtered, inspected, and restricted to authorized services, directly addressing the boundary protection requirement.

Centralising logs in a read-only security account satisfies the NIST SP 800-61 requirement for evidence integrity by preventing malicious tampering or deletion by compromised workloads. In a cloud environment, attackers with elevated permissions frequently target local log repositories to erase their footprint. Enforcing write-once, read-many permissions across an isolated, cross-account architecture ensures that forensic artefacts remain unaltered and legally defensible for subsequent investigation, directly fulfilling the constraint for reliable event data preservation.

Continuous file integrity monitoring with cryptographic hashing detects unauthorised modification by comparing current hashes against a trusted baseline, directly satisfying the stem's data integrity requirement. Unlike access controls or encryption, which address confidentiality or authorisation, FIM provides verifiable evidence that stored database files remain unaltered, making it the most reliable integrity mechanism.

Separation of duties ensures that no single individual has control over all aspects of a critical function, preventing fraud and reducing the impact of a compromised account. For a classified command-and-control system, it enforces checks and balances across administrative and operational roles, which is essential for resilience and is a core security engineering principle.

Threat modelling is a foundational mechanism within a secure software development lifecycle that addresses the explicit constraint of identifying and mitigating architectural design flaws before code is even written. By systematically evaluating system topology, trust boundaries, and data flows using structured frameworks like STRIDE, development teams can proactively uncover vulnerabilities and surface logic gaps early. This proactive analysis directly satisfies the requirement for security integration across the entire development continuum, significantly reducing the cost and effort of remediation compared to addressing defects post-deployment.

Following the NIST Risk Management Framework (RMF) lifecycle precisely satisfies the strict operational constraint for production environments by ensuring vulnerabilities are systematically discovered through identification, contextualised via risk assessment before changes are applied, subsequently remediated, and finally validated through verification to prevent service disruption.

The SSP documents the system boundary, security categorization, the controls selected from NIST SP 800-53 Rev. 5, and the implementation status of each control. It is the foundational artifact that the authorizing official uses during Step 6 (Authorize) to make a risk-based authorization decision, and it is continually updated as the system evolves through the RMF lifecycle.

Physical air-gapping completely severs all network pathways to satisfy the strict physical separation constraint, ensuring zero external attack vectors exist for the sensitive research data. Concurrently, hardware-level encryption managed via dedicated Hardware Security Modules (HSMs) enforces logical separation by offloading cryptographic operations and root-key storage to tamper-resistant silicon. This dual-layer approach provides mathematical and environmental isolation, guaranteeing that even physical hardware compromise fails to yield unencrypted data.

The shared responsibility model delineates which security controls are managed by the cloud service provider and which are the organization's responsibility. This is critical for the RMF because it affects the control inheritance and the evidence needed for authorization. The ISSEP must document this split to ensure all controls are accounted for and assessed appropriately.

Maintaining the Root Certification Authority in an offline state directly satisfies the security constraint to protect the most sensitive trust anchor of the Public Key Infrastructure from network-borne threats. Transporting the Certificate Signing Request via removable, air-gapped media ensures that the Root private key never touches a networked environment, completely eliminating remote attack vectors. Once signed locally by the isolated Root CA, the resulting certificate is securely transferred back via the same physical mechanism to issue the subordinate credential.

The Plan of Action and Milestones (POA&M) serves as the formal repository for tracking security weaknesses discovered throughout the Risk Management Framework assessment phase. By documenting specific remediation tasks, resource requirements, and scheduled completion dates, it satisfies the requirement for a structured management mechanism to mitigate identified vulnerabilities. This document ensures accountability by providing a transparent audit trail for security officials to monitor the progress of risk reduction efforts until each identified vulnerability is officially resolved or formally accepted by the authorizing official.

Threat modeling with a structured methodology like STRIDE systematically identifies threats based on data flows, trust boundaries, and adversary goals. It produces security requirements and design mitigations early, which is exactly what the ISSEP needs to integrate security into the early SDLC phases and ensure the architecture addresses identified threats before coding begins.

Pre-commit hooks execute locally on the developer's workstation before the git commit process completes, effectively intercepting sensitive data before it reaches the remote repository. By utilising regular expression patterns to identify credentials, this mechanism satisfies the constraint of preventing accidental exposure at the earliest possible stage of the development lifecycle. This proactive approach ensures that secrets never enter the version control history, thereby mitigating the risk of unauthorised access that could otherwise necessitate complex remediation or integration with services like Microsoft Entra ID.

The Prepare step is intended to ensure the organization is ready to execute the RMF. It includes activities such as establishing a risk management strategy, identifying key roles, and conducting organization-level risk assessments. This step sets the stage for the subsequent steps. It is not about assessing controls or authorizing systems, but about preparation.

This option is correct because NIST SP 800-37 Rev. 2 explicitly requires a gap analysis when considering reuse of an authorization package. The ISSEP must compare the existing system's security controls with the new system's requirements, identify any gaps, and update the security plan to address them. This ensures that the reused controls are appropriate and effective for the new system's environment of operation and risk profile, maintaining the integrity of the authorization decision.

Enforcing encryption at the provider level satisfies the constraint of ensuring all VM snapshots are secured by mandating compliance at the infrastructure layer. By configuring a platform-wide policy, you eliminate the risk of human error or manual oversight that occurs with per-resource settings. This centralised control mechanism guarantees that every snapshot created within the environment inherits encryption properties automatically, providing a consistent security posture that aligns with organisational governance requirements regardless of individual user actions or specific workload configurations.

NIST SP 800-53, Security and Privacy Controls for Information Systems and Organizations, provides a comprehensive catalog of security and privacy controls that are applicable to all U.S. federal information systems except those related to national security. It is the foundational control catalog used by the RMF and is directly applicable to this DoD system for control selection and specification.

Security-Enhanced Linux (SELinux) implements Mandatory Access Control (MAC) to enforce granular security policies on system objects, including memory segments and IPC mechanisms. By applying Type Enforcement, it restricts processes to specific domains, ensuring that even if a process is compromised, it cannot access memory space outside its defined security context. This mechanism effectively addresses the requirement to prevent unauthorised inter-process communication by overriding standard discretionary permissions and enforcing a strict, least-privilege policy across the entire Linux kernel environment.

Enabling specific SQL injection and cross-site scripting inspection modules directly addresses the OWASP Injection category by implementing signature-based pattern matching and heuristic analysis at the application layer. These WAF policies intercept malicious payloads within HTTP requests, sanitising input before it reaches the backend database or client browser. By enforcing strict input validation and normalisation rules, the WAF effectively neutralises command injection attempts, satisfying the requirement to mitigate the primary risks associated with untrusted data execution within the web application environment.

TEMPEST countermeasures reduce or block compromising emanations that an attacker outside the equipment can capture. A shielded enclosure with filtered power and signal lines contains the emissions and prevents them from propagating into the shared space, which directly addresses the physical-access emanation threat described in the scenario.

Tailoring baseline controls directly addresses the high-compliance constraint by ensuring that security measures align with the unique risk profile and operational requirements of the system. Rather than applying a rigid, one-size-fits-all framework, this process involves modifying security parameters to mitigate specific threats while maintaining regulatory adherence. By customising the implementation to the mission-critical environment, organisations ensure that controls are both effective and proportionate, thereby satisfying rigorous audit requirements without imposing unnecessary technical overhead on the system architecture.

Cryptographic signatures provide non-repudiation and authenticity, ensuring the downloaded package originates from the trusted vendor and remains unaltered. By verifying the digital signature against the developer’s public key, the recipient confirms that the hash value has not been tampered with during transit. This mechanism satisfies the integrity constraint by establishing a mathematical link between the specific file content and the author’s private key, effectively detecting any unauthorised modifications or corruption that could compromise the software package.

SC-28 is correct because it directly addresses the confidentiality and integrity of information at rest. The control requires cryptographic protection of data at rest, such as encryption, to prevent unauthorized disclosure or modification. In a cloud environment, implementing SC-28 ensures that stored data is protected even if the underlying storage media is compromised. It is a foundational control for data at rest protection and is included in the FedRAMP Moderate baseline.

NIST SP 800-53B provides control baselines for low, moderate, and high-impact systems. For a moderate-impact system, the moderate baseline is the initial set of controls. The ISSEP uses this baseline as the starting point, then tailors it based on the organization's risk assessment and the system's specific needs. This aligns with the RMF Select step.

Envelope encryption satisfies the 'Data at Rest' requirement by decoupling the data encryption process from key management. By generating a unique Data Encryption Key (DEK) to encrypt the payload and subsequently wrapping that DEK with a Key Encryption Key (KEK), the architecture ensures that the plaintext DEK is never stored alongside the data. This hierarchical approach simplifies key rotation and minimises the exposure of sensitive material, allowing organisations to manage access via services like Microsoft Entra ID while maintaining robust cryptographic security for stored microservice assets.

The Policy Decision Point evaluates request context, including device health and location, against policy, then determines whether access should be granted. It is the NIST SP 800-207 component that renders the authorisation decision before the Policy Enforcement Point acts.

Keeping raw personally identifiable information (PII) within an on-premises database directly satisfies the strict data sovereignty constraint of the stem by ensuring that jurisdictional data boundaries are not crossed. Utilizing a Cloud Hardware Security Module (HSM) to manage and store encryption keys remotely enables the organisation to retain cryptographic control over the data. This hybrid approach satisfies the cloud utilisation requirement while guaranteeing that the cloud provider never possesses the unencrypted data, thereby maintaining compliance with local data residency laws.

Documenting system boundaries, security controls, and implementation details directly satisfies the architectural constraint of establishing a comprehensive baseline for risk management and authorisation. The System Security Plan serves as the foundational artefact required to formally define the operational scope, interconnection parameters, and technical safeguards deployed within the information system. By capturing these precise architectural specifications, stakeholders can accurately evaluate control efficacy and maintain compliance throughout the system lifecycle.

SAML 2.0 is designed for federated single sign-on across organizational boundaries and carries signed assertions containing authentication and attribute statements. Relying parties can validate the signature and consume the assertion to make authorization decisions without a real-time call back to the identity provider, which matches the stated requirements exactly.

Migrating to LDAPS directly resolves the vulnerability of the existing plaintext LDAP connection highlighted in the stem by encapsulating the directory traffic within a TLS tunnel. By operating over dedicated port 636, LDAPS provides confidentiality and integrity for server-to-server communications without requiring a fundamental redesign of the underlying directory schema. This aligns with ISC security principles by safeguarding sensitive authentication credentials and directory objects in transit against interception and tampering.

DFARS 252.204-7012 requires compliance with NIST SP 800-171 for CUI. A FedRAMP Moderate authorization provides a baseline, but you must map its controls to SP 800-171 and identify any gaps. Documenting how gaps are addressed ensures the cloud service meets the required security baseline and supports the System Security Plan and POA&M.

Deploying a dedicated Hardware Security Module (HSM) satisfies the critical cloud security constraint of strict key isolation and hardware-level protection. Cryptographic operations and master key material are strictly bounded within a physical, tamper-resistant cryptographic processor that meets stringent FIPS 140 compliance standards. This architectural approach prevents the cloud provider or external threat actors from accessing plaintext keys, as all cryptographic functions execute securely inside the dedicated boundary, directly mitigating multi-tenant data exposure risks inherent in shared cloud environments.

Service mesh frameworks such as Istio utilise mutual TLS (mTLS) combined with Kubernetes `AuthorizationPolicies` to enforce strict cryptographic identity verification and fine-grained, namespace-scoped access control between microservices. This capability directly satisfies the architectural constraint of enforcing the principle of Least Privilege at the service-to-service communication layer by restricting network traffic to explicitly authorised paths, thereby preventing lateral movement and unauthorized payload inspection within the cluster.

Configuring rate-limiting policies at the API gateway layer per user or per IP directly addresses the resource exhaustion constraint outlined in the scenario. This technical mechanism enforces strict consumption thresholds, preventing malicious actors or runaway clients from overwhelming backend services with excessive requests. By offloading request validation and throttling to the gateway, the system preserves downstream application integrity, maintains optimal availability, and mitigates denial-of-service vectors without burdening individual microservices.

PCRs store measurements of boot components, and remote attestation allows a challenger to verify these measurements against known-good values. This provides a hardware-rooted verification of boot integrity. By using PCRs and remote attestation, the system can prove that its boot process is unmodified, satisfying the requirement for measured boot and remote verification.

ABAC evaluates attributes of the subject, object, and environment to make access decisions. It can incorporate user role, clearance level, and time of day dynamically, and policies can be centrally managed and updated. This flexibility directly matches the requirement for multi-attribute, dynamic access control in a service-oriented architecture.

A security assessment evaluates whether the implemented controls are effective and produces the assessment report that the authorizing official uses to make a risk-based authorization decision. This activity directly generates the evidence needed for the authorization package, ensuring the system can be authorized to operate based on verified control effectiveness.

Centralising transport layer security (TLS) termination at the load balancer directly satisfies the high availability and security constraints by offloading computationally intensive cryptographic processing from backend application servers. This architectural pattern allows security teams to enforce consistent cipher suites, inspect incoming payloads for malicious patterns, and implement Web Application Firewall (WAF) filtering at a single entry point. Managing certificates centrally prevents expiration vulnerabilities across distributed nodes while ensuring seamless traffic distribution and continuous service availability.

A Common Criteria certificate issued after evaluation by an accredited laboratory provides independent verification that the module meets a published Protection Profile. This gives the program the assurance that cryptographic and security functions were tested against a recognized standard and that the security features are documented, which is exactly what the supply chain requirement demands.

Implementing `X-Frame-Options` with either the `DENY` or `SAMEORIGIN` directive directly satisfies the requirement to prevent clickjacking attacks against the internal web application. This HTTP response header instructs the browser to restrict whether the target resource can be rendered within a `<frame>`, `<iframe>`, `embed`, or `<object>` tag. By setting the value to `DENY`, the application completely prohibits any domain from framing its content, whereas `SAMEORIGIN` restricts framing exclusively to pages originating from the identical domain context, effectively neutralising UI-redressing threats.

The Assessment phase specifically satisfies the objective to verify that security controls are implemented correctly and operating as intended by conducting a comprehensive security assessment. This involves executing rigorous testing and evaluation procedures against defined baseline specifications to produce a security assessment report. By systematically gathering evidence on control efficacy, security professionals determine whether the safeguards meet the required organisational risk tolerance before authorising the system for operational use.

Authentication and authorization conditions form the core logical constraints necessary to satisfy the strict identification and privilege-scoping requirements mandated in a high-security access control policy. By defining cryptographic assertion checks and contextual least-privilege guardrails—such as device posture or risk-based conditional access evaluated by identity providers like Microsoft Entra ID—this element ensures that subjects must cryptographically prove their identity and dynamically validate their entitlement state prior to resource ingestion, directly fulfilling the rigorous verification constraint specified in the stem.

Ensuring that the cryptographic module actively appears on the NIST Cryptographic Module Validation Program (CMVP) validated list is essential because FIPS compliance relies strictly on formal certification status rather than vendor claims or self-assessments. This directly satisfies the constraint of verifying FIPS 140-2/-3 validated cryptography, as a module must undergo rigorous independent testing by an accredited NVLAP laboratory and receive formal NIST validation to legally and technically qualify as a certified implementation within regulated security architectures.

NIST SP 800-53 provides a comprehensive catalog of security and privacy controls for federal information systems and organizations. It includes guidance on tailoring controls through the application of scoping, parameterization, and supplemental guidance. For a cloud deployment, the ISSEP can use SP 800-53 to select and tailor controls based on the system's impact level and the cloud service model.

Integrating a hardware-based root of trust provides a secure foundation by anchoring cryptographic functions directly in tamper-resistant silicon, such as a Trusted Platform Module (TPM). This capability satisfies the NIST SP 800-160 Trustworthiness objective by ensuring that system boot integrity and cryptographic keys cannot be compromised by software-layer vulnerabilities. Establishing this immutable hardware baseline directly validates the operational reliability and resilience demanded by the standard's rigorous systems security engineering lifecycle.

The Authorising Official (AO) exercises ultimate accountability during the Authorization phase by reviewing the security package—comprising the security plan, assessment report, and plan of action and milestones—to determine if the residual risk falls within acceptable organisational tolerance levels. This directly satisfies the stem constraint requiring the identification of the primary goal of this specific NIST Risk Management Framework phase, which culminates in the formal, documented acceptance of risk before system deployment.

The Statement of Applicability directly satisfies the ISO 27001 requirement to justify the inclusion or exclusion of specific controls by mapping organizational risk treatment decisions against the Annex A control set. This mandatory artifact records which controls are selected to address identified risks, the justification for those choices, and whether the implemented controls are operational, thereby providing auditors with a transparent compliance baseline for the ISMS scope.

IPsec in tunnel mode with IKEv2 provides confidentiality, integrity, and mutual authentication through the use of ESP and AH, and IKEv2 supports strong authentication methods such as certificates. It is a standard for site-to-site and remote access VPNs, and meets the requirements for protecting sensitive data in transit. Therefore, it is the correct choice for this scenario.

The PDP evaluates each access request against policy, identity and contextual signals, then issues the allow, deny or modify decision that enforcement points act upon. This decision function is the core of Zero Trust's dynamic authorisation.

Identity-based authentication satisfies the core Zero Trust constraint of transitioning from implicit network perimeter trust to explicit verification. By leveraging directory services such as Microsoft Entra ID to cryptographically verify user credentials, multi-factor authentication, and device posture before granting access, the enterprise can continuously validate identities regardless of whether the request originates from inside or outside the corporate network, ensuring that access decisions are dynamically tied to verified contextual signals rather than location.

Segmenting the DMZ with a firewall that enforces least privilege ensures that only required traffic can reach the internal network. This limits the blast radius if the web server is compromised. The firewall acts as a control point, and rules should be as restrictive as possible. This design aligns with DoD and NIST guidance for DMZ architectures.

A cross-domain solution that includes a content filter and protocol break ensures that data is inspected and sanitized before crossing the boundary. The protocol break terminates the protocol on the low side and re-originates it on the high side, preventing protocol-based attacks. This directly meets the requirement to allow only authorized transfers and protect the high side.

A guard is a key component of a cross-domain solution that enforces security policies, sanitizes data, and validates formats to prevent leakage of sensitive information. It operates on a trusted path and applies rules that determine what data can pass between security domains, making it the appropriate architectural choice for this scenario.

NIST SP 800-137 provides guidance on developing and implementing an ISCM strategy, including defining metrics, establishing monitoring frequencies, and integrating automated tools to support ongoing authorization. It directly enables near real-time risk determination by aligning monitoring activities with organizational risk tolerance and the RMF steps.

The NIST Cryptographic Module Validation Program maintains the authoritative registry of FIPS 140-3 validated modules, listing each certificate, its validation level and tested operational environment. Checking this registry confirms whether the load balancer's TLS module actually holds the required physical security validation.

SAML 2.0 is an XML-based standard for exchanging authentication and authorization data between parties. In an SOA, SAML assertions can be used to convey the identity of the sender and their attributes, which services can then trust. Combined with WS-Security, SAML tokens can be embedded in SOAP messages to provide end-to-end identity verification and enable single sign-on across services.

Selecting security controls directly satisfies the requirement to identify safeguards based on the system’s determined impact level, as defined in NIST SP 800-53. During this phase, organisations map the categorisation results—Low, Moderate, or High—to a baseline of controls. This process ensures that the chosen security measures are proportional to the identified risk, allowing practitioners to tailor the baseline to specific operational needs while maintaining compliance with the overarching NIST RMF framework requirements for system protection.