Provisioning networking and identity, and the order that matters

Why this matters

Compute is the visible half of provisioning and the easy half. The network a workload sits in and the identity it runs as are what determine whether it can reach anything, whether anything can reach it, and what it is permitted to do.

Order is the theme. Cloud resources have dependencies, and building them in the wrong sequence produces failures that look like faults but are really scheduling problems — an instance that launches before its role exists and can never fetch its configuration, a certificate that cannot validate because DNS does not resolve yet.

This lesson closes the deployment domain by putting the pieces in sequence and insisting that the result is verified against the specification rather than assumed.

The lesson

The dependency order: network, then identity, then compute, then data

Build in this order, and understand why each step depends on the last.

1. Network. The virtual network, subnets across zones, route tables, gateways, endpoints and security groups. Nothing can be placed before there is somewhere to place it, and the address range decision (objective 1.3) is effectively permanent.
2. Identity. Roles, policies and service accounts. These must exist before the compute that assumes them, because a workload's ability to do anything is attached at launch.
3. Security and shared services. Key management, secret stores, logging destinations, certificates. Compute expects these to be there on first boot.
4. Compute. Instances, containers, functions — placed in the network, assuming the identity, using the keys and secrets.
5. Data. Databases, storage, caches. Often placed before compute in practice, which is fine as long as the network and identity exist first. Data services are the longest-lived layer and should be in a stack with a small blast radius.
6. Traffic. Load balancers, DNS records, certificates in use. Last, because pointing traffic at something that is not ready is how a deployment becomes an outage.

Declarative tooling works most of this out from resource references, which is one of its main advantages. What it cannot infer are implicit dependencies — an instance whose boot script expects a secret to exist, where nothing in the template connects the two. Those must be declared explicitly, and an intermittent failure that "works on the second apply" is almost always an undeclared implicit dependency.

The same order applies across stacks, which is why dependencies must point one way (objective 2.2): network and identity stacks are foundations, application stacks consume them.

Service accounts and instance roles, so a deployed workload needs no stored key

This is the most important security idea in the deployment domain.

A workload usually needs to call the provider's APIs — read a secret, write to object storage, publish a metric. The wrong way is to create a user, generate a long-lived access key, and put it in configuration. That key then sits in a file, in an image, in a repository, or in an environment variable, and it does not expire.

The right way is a role or service account attached to the resource. The platform supplies short-lived credentials automatically through the metadata service; the SDK picks them up without configuration; they rotate on their own; and there is no key to leak because none exists.

Every compute form has its version: an instance profile or role attached at launch, a managed identity, a workload identity for a container's service account, an execution role for a function.

Rules that follow:

• Never create a long-lived access key for a workload. If a scenario describes credentials in a configuration file, the answer is a role.
• One role per workload, scoped to what that workload needs. A shared role used by everything is least privilege in name only.
• The role is attached at creation and is part of the launch template.
• Protect the metadata service. Anything that can make the instance issue an HTTP request on its behalf can potentially read its credentials — the server-side request forgery path. Use the hardened, session-authenticated version of the metadata service where the provider offers one. This is a specific, examinable control.

The equivalent for people is federation (objective 4.2): humans authenticate against a directory and assume roles, rather than holding permanent keys. The principle is identical — short-lived credentials obtained through identity, not long-lived secrets stored somewhere.

DNS records, certificates and load balancers as part of provisioning, not afterthoughts

Traffic-facing components are frequently treated as manual finishing touches and then become the fragile, undocumented part of the environment.

Load balancers. Provisioned with a listener, a certificate, target groups and a health check. Two points worth carrying: the health check must test the application, for the same reason as in the previous lesson; and the scheme — internet-facing or internal — is a creation-time decision that is awkward to change.

Certificates. Use the provider's managed certificate service where possible: issuance and renewal are automatic, and an expired certificate is one of the most common self-inflicted outages there is. Where a certificate must be imported, its expiry becomes something you must monitor, and it belongs on a calendar, not in somebody's memory. Validation is usually by DNS record, which is why DNS must exist first.

DNS. Records belong in code with everything else. Three practical points:

• Alias-style records pointing at a load balancer follow it if its address changes; a hard-coded address record does not.
• Health-check-aware DNS can fail traffic over between regions, which is part of the disaster-recovery answer in objective 3.2.
• TTLs are a deployment property, per objective 2.3 — set them low before a change, raise them after.

A test environment built without these has not actually been tested, because certificate and DNS behaviour is exactly where deployments fail.

Bootstrapping configuration at first boot, and keeping secrets out of the template

Bootstrapping is how a generic image becomes a specific working instance. There are three broad approaches and they combine:

• Bake it into the image. Fastest boot, most consistent, and requires an image pipeline to keep current. Best for anything that changes slowly.
• Configure at boot via user data or a configuration-management tool. Flexible, slower, and a failure here produces an instance that exists and does not work.
• Fetch at boot. Retrieve configuration and secrets from a parameter store or secret store using the instance's identity. Best for anything that must be current or must not be stored.

The rule about secrets is absolute and worth repeating because it is tested in several forms: secrets do not go in templates, in images, in user data, in repositories, or in environment variables set from any of those. They go in a secret store, and the workload fetches them at run time using its own identity.

The reasons stack up: templates are in source control and visible to everyone with repository access; images are distributable and their layers are immutable (objective 1.4); user data is readable from inside the instance; state files hold values in plain text (objective 2.2). Every one of those is a place a secret placed in a template ends up.

Get the failure behaviour right too. An instance that cannot fetch its configuration should fail its health check rather than start in a broken state — that way the scaling group replaces it and no traffic reaches it, instead of a half-configured instance serving errors.

Verifying a provisioned environment against the specification it was built from

Provisioning is not finished when the apply succeeds. An apply reports that the platform accepted the requests, not that the environment is correct.

Verify in layers:

1. Structural. Do the resources exist, in the right places, with the right properties? The plan being empty on a second run is a good first signal (objective 2.2).
2. Policy. Does it meet the baseline? Encryption on, logging enabled, no public exposure, required tags present, no over-broad roles. Run the posture check now rather than waiting for the sweep in objective 6.5.
3. Connectivity. Can the things that should reach each other do so, and can the things that should not, not? The second half is the one people skip, and it is where a misconfigured security group hides.
4. Functional. A smoke test of the actual application path, end to end, including through the load balancer and using the real hostname and certificate.
5. Recovery. Can it be destroyed and rebuilt from the same code? For anything important this is the strongest test, and it validates the disaster-recovery claim in objective 3.2 at the same time.

Automate these as a suite that runs after every environment build. That turns the environment into something with a pass/fail state rather than something somebody once looked at — and it is what lets you rebuild with confidence, which is the whole promise of infrastructure as code.

What to take into the exam

• Build network → identity → security services → compute → data → traffic. Undeclared implicit dependencies are what cause "works on the second apply".
• Attach a role, never store a long-lived key. If a scenario shows credentials in a config file, the answer is an instance role or service account.
• Protect the metadata service — it is the SSRF path to a workload's credentials.
• Managed certificates renew themselves; imported ones become your expiry problem. Certificate validation usually needs DNS first.
• Secrets never go in templates, images, user data, repos or state. Fetch at run time by identity.
• An instance that cannot get its configuration should fail its health check, not serve errors.
• An apply succeeding is not verification. Check structure, policy, connectivity (including what must not connect), function, and rebuild.