Choosing proactive, detective and preventative controls in the cloud

Why this matters

CompTIA name three control strategies in this objective, and the reason they appear as a set is that cloud changes the economics between them. On-premises, prevention is expensive and detection is comparatively cheap: you buy an appliance, you place it, you maintain it. In cloud, prevention is often a policy statement that costs nothing to run, because the platform itself can refuse the action.

That inversion is what scenarios test. A question describing a recurring misconfiguration and offering better monitoring, a stricter review process, or a guardrail is usually rewarding the guardrail — not because detection is bad, but because in this environment the preventative option is cheaper and stronger, which is rarely true elsewhere.

The second idea is proportionality. Stacking all three strategies on everything produces an estate nobody can change, and CAS-005 consistently rewards the answer that matches control strength to risk rather than the answer that maximises control.

The lesson

The three strategies stated as questions a design has to answer

Strip the vocabulary back to what each strategy actually commits you to.

Preventative — can this happen at all? The control refuses the action. A policy denying public storage, a guardrail forbidding a region, an admission controller rejecting a privileged container, a network rule with no matching allow. The defining property is that the undesired state never exists, so there is nothing to detect, remediate, or explain to a regulator.

Detective — if it happens, will we know, and how fast? Configuration assessment, audit logs, alerting, anomaly detection. The defining property is that the undesired state exists for a period, and the control's value is measured by how short that period is.

Proactive — will we find this before it is built? Threat modelling, architecture review, code and infrastructure-as-code review, policy evaluation against a plan. The defining property is that the undesired state is prevented in a design, which is cheaper than preventing it at runtime and far cheaper than detecting it later.

Two more categories complete the standard vocabulary and appear as answer options: corrective controls restore the correct state after the fact (auto-remediation, restoring from backup), and deterrent controls discourage the behaviour (logging that people know about, banners, disciplinary policy).

The structural reason to hold all of these apart is that they fail differently. Preventative controls fail by blocking legitimate work, which generates pressure to weaken them. Detective controls fail silently — a rule that stopped matching looks exactly like an absence of events. Proactive controls fail by being skipped when a delivery date is at stake. A design that leans entirely on one strategy inherits its failure mode undiluted.

Guardrails and service control policies as preventative controls at scale

The cloud-specific preventative mechanism is a policy applied above the account, at the organisation or management-group level, that constrains what any principal in that account may do — regardless of the permissions granted inside it.

That last clause is the whole point and it is worth stating carefully. An account administrator with unrestricted permissions inside their account still cannot perform an action the organisation-level policy denies. So the guardrail is not an access control; it is a boundary on the account itself. This is the mechanism that answers "what stops a team with admin rights from making a mistake", which is otherwise unanswerable.

What guardrails are typically used for:

• Region restriction, which addresses both data residency and the forgotten regions problem from lesson sixteen in one line.
• Preventing public exposure of storage and other resources.
• Preventing the disabling of logging, which protects the detective layer from being switched off — a control protecting a control.
• Preventing deletion of security infrastructure, such as the assessment role or the log destination.
• Requiring encryption on resource creation.
• Restricting which services may be used at all, which is surface reduction from lesson ten applied at the account boundary.

Three design notes that scenarios probe. Guardrails apply to future and current actions, not existing state — a policy denying public storage does not make existing public storage private, so a guardrail deployment must be paired with a remediation sweep. They need an exception mechanism, usually a carved-out account or role, or they get disabled wholesale when a legitimate need arrives. And they must be tested, ideally by attempting the denied action, because a policy that does not do what its author believed is indistinguishable from protection until the day it matters.

Detective controls: configuration recorders, drift detection and continuous posture scoring

Detection in cloud is mostly about configuration state rather than about traffic, which is the inversion an on-premises background gets wrong.

Configuration recording. The platform records the configuration of every resource over time, which gives two things a log cannot: the ability to ask what the configuration was at a moment in the past, and the ability to alert on a change. Incident work depends heavily on the first — "was this open when the data was taken" is otherwise unanswerable.

Rule evaluation. Rules evaluate recorded configuration continuously and report resources out of compliance. The design points that matter: rules must cover every account and region (completeness is what fails first), the rule set must be version-controlled and reviewed like any other code, and each rule needs an owner to whom its failures are delivered.

Drift detection compares running state against the declared infrastructure-as-code. This catches the change made in the console that the code does not know about, and it is the pairing lesson fourteen promised: code review sees the declared state, drift detection sees the difference between declared and real.

Posture scoring aggregates all of this into a number. It is useful for trend and useless for action, and scenarios exploit the difference. A score improving while a specific critical exposure persists is exactly what an aggregate is designed to do. Score for the board report; alert on individual transitions for the people who fix things.

The recurring failure in this layer is worth naming: a detective control with no owner and no remediation path produces a stable number that gets read as normal. A weekly report of 340 findings that has said roughly 340 for a year is not detection, it is decoration.

Proactive work: threat modelling and architecture review before deployment

The proactive strategy is the material of lessons nine and ten, placed here as a deliberate choice rather than as a stage everyone skips.

What makes it work in a cloud delivery model, where deployments are frequent and a review board would become the bottleneck:

• Trigger on architectural change, not on every deployment. A new data flow, a new external integration, a new environment, a change of data classification or a new provider service warrant review. A version bump does not. Getting this trigger right is what makes the practice survivable.
• Automate the mechanical parts. Policy as code from lesson fourteen handles the rules that can be expressed as rules, leaving human review for the questions that need judgement — trust boundaries, blast radius, proportionality of authority.
• Produce a decision record, not a report. Options considered, constraint that discriminated, decision, accepted residual risk. Short enough that people write them, structured enough to be evidence later.
• Feed the output into the risk register, so an accepted design risk is visible alongside everything else rather than living in a document nobody re-reads.

The measure that makes this visible to management is the proportion of architectural changes that had a review before build — a single number, from lesson nine, that tells you whether the practice exists or is aspirational.

Balancing the three against cost and friction rather than stacking all of them

The closing judgement, and the one CAS-005 tests most often in this objective.

Every control has a cost beyond its price: preventative controls block legitimate work sometimes, detective controls produce volume that consumes analyst time, proactive controls consume delivery time. An estate with maximal controls everywhere is slow, expensive, and — the part people miss — less safe, because the friction generates workarounds: shadow accounts, disabled policies, exceptions granted in bulk, and shadow IT of the kind lesson thirteen described.

A defensible allocation uses the classification from lesson seven as the input:

Three principles behind that table, each of which a scenario may be testing:

• Prevent what is never legitimate, because a guardrail against something nobody needs generates no friction at all. Public storage in a restricted environment is the clean example.
• Detect what is sometimes legitimate, where a blanket block would be wrong and the signal matters.
• Review what is novel. Repeated patterns should be encoded as policy; human attention belongs on the things that have not been decided before.

And one closing point that connects the domain: the cheapest control in this whole table is the one from lesson ten — not building the thing at all. Surface that does not exist needs no strategy applied to it.