Information Security Program practice questions

Reference architectures are the default; justified deviations go through a risk-assessed, documented exception process.

The pattern does not fit a real requirement, so neither forcing it nor waving the design through is sound. The manager assesses the proposed design's risk and puts it through the exception process, where the accountable owner accepts any residual risk on the record. Updating the reference architecture could follow if similar needs recur, but only after the design has been assessed.

1. Accept that a business requirement can justify deviating from a pattern.
2. Recognise that deviation needs a risk assessment before anyone decides.
3. Use the exception process so the decision and the owner are documented.
4. Consider changing the standard pattern only after the design is proven.

Exam tip: Deviation from an approved pattern = assess the risk, then a documented exception, not a free pass or a flat no.

Defense in depth: multiple, independent layers of control so no single failure exposes an asset.

The defining idea is redundancy across independent layers (network, host, application, data, people). Least privilege, separation of duties and fail-safe defaults are all design principles a security architecture uses, but each concerns how one control behaves, not how controls back each other up.

1. Find the key idea in the description: one control failing without exposure.
2. Match it to the principle about multiple layers.
3. Rule out principles that describe a single control.

Exam tip: No single control should stand between an attacker and the asset.

Defense in depth removes single points of failure by adding independent layers of control.

The real problem is architectural: one control protects highly sensitive data. Adding independent controls at the application and database layers means a failure of the firewall no longer exposes the data. Replacing the product or waiting for a patch fixes this flaw but keeps the single point of failure.

1. Look past the immediate flaw to the design weakness it reveals.
2. Ask which option still protects the data if the firewall fails again.
3. Choose independent layers rather than a better or patched single layer.

Exam tip: When one control is all that protects an asset, add a layer, not a better version of the same layer.

Zero trust (NIST SP 800-207): no implicit trust from network location; each access request is evaluated on identity, device and context.

NIST SP 800-207 describes zero trust as granting no implicit trust based on physical or network location, with authentication and authorization performed before each session to a resource. Network location, a single daily check and segment membership are all forms of implicit trust.

1. Recall the core zero trust principle: never trust by location.
2. Remove options that grant trust once and keep it.
3. Choose the per-request evaluation of identity, device and context.

Exam tip: Zero trust: decide every request on who, what device and what context, not where it comes from.

Strong authentication is not zero trust if a successful login grants broad network access; access must be decided per resource.

Multifactor authentication answers "who is this?", but the VPN then trusts the user everywhere on the internal network. That is location-based implicit trust and the reason ransomware spreads laterally. Zero trust replaces it with per-application access decisions. Stronger authenticators, monitoring and gateway resilience are all worthwhile but leave the trust model unchanged.

1. Separate what has been fixed (identity verification) from what has not (scope of access after login).
2. Check each option against the principle of no implicit trust by location.
3. Pick the gap that lets one compromised login reach everything.

Exam tip: MFA plus flat network access is still perimeter security; zero trust limits what each session can reach.

Security zones group systems by the sensitivity and criticality of what they process, so each zone gets a consistent level of protection.

A zone is a set of assets that share a security requirement. The requirement comes from the information's classification and the system's criticality, so that is the grouping that lets controls at the zone boundary match the risk. Ownership, location and platform are management conveniences that cut across sensitivity.

1. Ask what the zone boundary is meant to protect.
2. Link that to the value of the information inside it.
3. Choose classification and criticality over administrative groupings.

Exam tip: Zone by what the data is worth, not by who owns it or where it runs.