Finding and fixing misconfigurations

Why this matters

This is the last objective of the exam and a fair place to end, because misconfiguration is the single largest cause of real cloud incidents. Not exploits, not sophisticated attackers — storage left public, management ports open, permissions too broad, logging switched off.

It closes the loop on the whole course. Objective 2.2 put configuration in code; objective 4.1 scanned it; objective 4.2 constrained it with guardrails; objective 5.1 automated the response. This lesson is what to do when something is nevertheless wrong, and — more importantly — how to make the same thing impossible next time.

The theme is a progression: detect, then fix in code, then prevent. Fixing in the console is the weakest of the three and the one people default to.

The lesson

The recurring ones: public storage, open management ports, over-broad roles, disabled logging

The list is short and stable, and knowing it is most of the value.

Public storage. Buckets and containers readable or writable by anyone, usually created for convenience and never narrowed. Also: public snapshots, public machine images, and databases with a public endpoint and permissive rules. Providers now default to blocking public access, which has helped considerably — so check that the account-level block is actually on, and treat any exception as something to be justified.

Open management ports. SSH on 22 and RDP on 3389 open to 0.0.0.0/0. Scanned continuously, and the fix is objective 4.5's agent-based session access rather than a narrower range. Also worth watching: database ports, admin interfaces, and container or orchestrator APIs exposed to the internet.

Over-broad permissions. Wildcard actions, wildcard resources, permanent administrative access, roles with trust policies that anyone can satisfy, and service accounts with far more than they use. This is objective 4.2's least-privilege work, seen as a finding.

Logging disabled or incomplete. No audit trail, a trail not covering all regions, logs with short retention, logs the same administrators can delete. It is not exploitable by itself, and it removes your ability to investigate anything else — which is why it deserves a high severity despite looking passive.

Encryption not enabled where it could be, including on backups and snapshots.

No MFA on privileged identities, especially the root account.

Default credentials and default configurations left in place on deployed software.

Missing network segmentation — a flat virtual network or a flat cluster network (objective 4.3), where one compromise reaches everything.

Two things unite this list: every item is a configuration rather than a vulnerability, so a vulnerability scanner reports none of them; and every item is the customer's responsibility at every service model (objective 1.1), because configuration never crosses the shared-responsibility line.

Configuration baselines and automated posture checks that run continuously

A baseline is the documented correct configuration — encryption on, logging enabled, no public access, MFA required, approved regions only, required tags present. Derive it from a recognised benchmark rather than inventing one, so it is defensible to an auditor (objective 4.4) and maintained by someone else.

Posture management checks the live estate against that baseline continuously. It is cheap because it reads the platform's API rather than probing hosts, and continuous is the right cadence because configuration changes constantly.

Making it useful rather than noisy:

• Cover every account and every region. Misconfigurations hide in the accounts nobody watches, and this is the same coverage problem as objective 4.1.
• Prioritise by exposure, not by the tool's default severity. A public bucket holding public marketing images is not the same finding as one holding customer records, and data classification (objective 4.5) is what distinguishes them.
• Route findings to owners via tags, so they reach someone who can act.
• Track the trend, not the absolute count. A first scan always returns a large number; whether it is falling is the meaningful measure.
• Suppress deliberately. A documented, owned, time-bounded exception is fine (objective 4.1's accepted risk); an undocumented suppression is how a finding disappears.

Add change detection alongside: alert when a security group is opened, a policy broadened, logging disabled, or public access enabled. That catches the change at the moment it happens rather than at the next sweep, and it doubles as the security signal from objective 6.3.

Comparing running state against the template that was supposed to produce it

Posture checking asks "is this safe?" Drift detection asks a different and complementary question: "is this what we said?"

Both are needed. A resource can be perfectly safe and not match its definition, and it can match its definition and be unsafe.

The mechanics are from objective 2.2: run a plan on a schedule against every environment and alert on any non-empty result, because a non-empty plan when nobody changed the code means reality moved. Suppress genuinely benign attributes so the signal stays readable.

When drift is found, decide explicitly — revert it by applying, or adopt it by updating the code — and record which. What is not acceptable is leaving it undecided, because the next apply will decide for you at a moment you did not choose.

The related and important case is the unmanaged resource: something that exists and no template owns. It is invisible to drift detection precisely because nothing is watching for it. Find it by reconciling the platform's inventory against what your code manages; anything in the first and not the second is either an orphan (objective 3.1) or a resource created by hand. The tagging discipline makes this a filter rather than an investigation.

Fixing in code rather than in the console, so the fix survives the next apply

The most important practical point in the lesson.

A console fix on a resource managed by infrastructure as code is temporary. The next apply compares reality to the code, finds your fix, and reverts it. The misconfiguration returns, often weeks later, and nobody connects the two events.

The same is true one layer down: patching or reconfiguring a running instance in an autoscaling group is reverted by the next scaling event, because the new instance comes from the unchanged image (objectives 3.1 and 4.1).

So the rule: fix where the configuration comes from.

• Managed by a template → fix the template, review, apply.
• Built from an image → fix the image, rebuild, roll the fleet.
• Set by a policy → fix the policy.
• Created by hand → import it into code first (objective 2.2), then fix it.

There is a legitimate exception, and it needs stating because otherwise the rule is unusable in an emergency: for an active exposure, fix it immediately in the console, then fix the code the same day. Leaving customer data public for two hours while a pull request is reviewed is the wrong trade. What makes this acceptable is the second half — the console change is a stop-gap with a recorded follow-up, not the fix.

Track that follow-up explicitly. "Fixed in console, code change pending" is a state that must not become permanent, and an emergency console fix with no code change is the most common source of drift there is.

Guardrails that make the misconfiguration impossible rather than merely detected

The strongest control, and the right place to end the course.

Detection tells you something is wrong after it is wrong. Prevention stops it happening. In order of strength:

1. Organisation policies that deny absolutely (objective 4.2). Deny disabling logging, deny unapproved regions, deny public access, deny deleting audit trails — and these hold even for administrators, which is the property that makes them guardrails rather than settings.
2. Provider account-level blocks, such as the account-wide block on public storage access. One setting, whole class of failure removed.
3. Admission and policy engines that refuse non-compliant resources at creation — in the cluster (objective 4.3) or at the platform.
4. Pipeline policy scanning that fails the build on a non-compliant template (objectives 2.2 and 5.3). Caught before anything exists.
5. Standard modules with policy baked in (objective 2.2), so the compliant configuration is the default and the easy path.
6. Automated remediation — an event-triggered function that reverts the change immediately (objective 5.1). Not prevention, but a response measured in seconds rather than days. Use it carefully: automatic remediation that fires on a legitimate change is itself an incident, so start in alert-only mode.

The judgement to carry: a control that people bypass protects nothing (objective 5.3). Guardrails must leave a legitimate path — an exception process with an owner and a review date — or teams will find a way around them, and the way around is always less visible than the control.

And the closing thought for the exam and the job: the progression through this course has been from doing things by hand, to doing them in code, to preventing the wrong thing from being possible. Detection is the weakest of the three and the one most estates stop at. Knowing that — and knowing why the guardrail beats the scanner — is what CV0-004 is really asking for in this objective.

What to take into the exam

• The recurring set: public storage, open management ports, over-broad permissions, disabled logging, missing encryption, no MFA, defaults left in place, flat networks. All are configuration, so vulnerability scanners miss them, and all are the customer's responsibility at every service model.
• Posture management is continuous and benchmark-based; cover every account and region; prioritise by exposure and data classification; track the trend.
• Posture asks "is it safe?", drift asks "is it what we declared?" Both are needed, and an unmanaged resource is invisible to drift detection.
• A console fix on a managed resource is reverted by the next apply; patching an instance in a scaling group is reverted at the next scaling event. Fix where the configuration comes from.
• Emergency exception: fix the exposure now, fix the code the same day — and track the follow-up.
• Prevention beats detection: organisation-level denies, account-wide blocks, admission control, pipeline policy gates, policy-bearing standard modules, then automated remediation. A control that gets bypassed protects nothing, so leave a legitimate exception path.