Customer-to-cloud connectivity, service integration and continuous authorization

Why this matters

This lesson covers how your estate joins the provider's, and the running theme is that every connection is a trust relationship, whether or not anybody described it that way when it was made.

Three kinds appear in the objective. Network connectivity joins your network to theirs. Service integration joins identities and services across the boundary — federation, workload identity, cross-account roles. And continuous authorization replaces a point-in-time approval to operate with an ongoing, evidence-driven one.

The exam angle is consistent: scenarios describe a connection built for a good reason that quietly became a path nobody reviews. The correct answers are usually about scoping the trust narrowly and making it observable, rather than about the transport technology — which is the distractor.

The lesson

Private connectivity options and what each removes from the threat model

Four ways to reach a provider, and what each actually changes.

The public internet with TLS. Traffic crosses the internet, protected by transport encryption and authenticated by certificate. Confidentiality and integrity are protected; the existence and volume of the connection are visible, availability depends on the internet path, and the service endpoint is reachable from everywhere, so it depends entirely on authentication and authorisation.

VPN over the internet. An encrypted tunnel between your network and a provider network. Adds network-level authentication and lets you treat the provider network as an extension of yours. Still rides the public internet, so it inherits its latency variance and availability, and it introduces a tunnel that becomes a dependency of everything using it.

Dedicated private connectivity. A private circuit from your network to the provider. Removes internet exposure of the path and gives predictable latency and bandwidth. It does not encrypt by default — a frequently tested point, and the reason a private circuit is usually still run with encryption over it, because "private" means not shared routing, not confidential.

Private service endpoints. A provider service is given an address inside your own virtual network, so traffic to it never traverses the internet even logically. This is the one that changes the threat model most, because it removes the public endpoint from the equation entirely — combined with a policy that the service accepts traffic only through the private endpoint, data exfiltration to a different tenant's instance of the same service becomes impossible rather than merely unlikely.

The examinable point in that last sentence generalises. The interesting threat in a mature cloud estate is not an outsider reaching in; it is an insider or a compromised workload writing data to an attacker's account in the same provider, which looks like ordinary service traffic. Private endpoints plus egress restriction address that, and no amount of transport encryption does.

A note on ordering that scenarios reward: choose connectivity from the requirement — bandwidth and latency predictability, exposure reduction, regulatory constraint on the path — and remember that encryption is an orthogonal decision applied on top of any of them.

Service integration: identity federation, workload identity and cross-account trust

The higher-value integrations are about identity, not network.

Identity federation. Your identity provider authenticates users and asserts identity and attributes to the cloud provider, which maps them to roles. This is strictly better than local accounts in the provider: one joiners-movers-leavers process, one place to enforce multi-factor authentication, one audit of who has access. Two things to check in a scenario: whether the trust is scoped, so that the assertion can only assume the intended roles; and whether leaver processing actually revokes — a federated session already issued survives until it expires, which is why session lifetime is a security parameter rather than a convenience one.

Workload identity. A workload — a pipeline, a function, a container — authenticates to the provider using a short-lived token bound to what it is, rather than a static key. This is the single most valuable integration pattern in the objective, because static credentials are the most commonly stolen thing in cloud estates and workload identity removes them entirely. The trust condition is the control: it must be scoped to a specific repository, branch, cluster or service account, because a condition that accepts any workload from a given issuer accepts an attacker's workload too.

Cross-account roles. One account assumes a role in another. Correct when scoped by a trust policy naming the exact principal, and usually paired with an external identifier when a third party is involved, to prevent a confused deputy — where your supplier is tricked into using their access to your account on someone else's behalf.

The failure mode common to all three is scope. Every one of them is easy to make work with a broad trust condition and hard to make work with a narrow one, so estates accumulate broad ones. When a scenario describes an integration compromise, the question is nearly always which condition should have been narrower.

Two further integrations worth naming because they are frequently ungoverned: third-party applications holding delegated access to your tenancy, from lesson thirteen; and provider-to-provider integrations in multi-cloud estates, which create trust paths between two environments that each believe they are the boundary.

Continuous authorization as an alternative to a point-in-time approval

Traditional authorisation to operate is a formal decision, made once, that a system may run: assess, document, approve, and revisit in one to three years. Its weakness is obvious in an estate that changes daily — the assessment describes a system that no longer exists, and the intervening period is unmonitored by design.

Continuous authorization keeps the same decision and changes its cadence: the authorising authority relies on a continuous stream of control evidence, so the authorisation reflects the system's current state rather than its state at assessment. It is the same shift lesson six described for compliance evidence, applied to the approval itself.

What it requires, and each item is a scenario's missing piece:

• Controls expressed as machine-evaluable tests, with a defined frequency — the same requirement as continuous compliance.
• Automated evidence collection feeding a current view.
• Defined thresholds at which authorisation is suspended or reduced, agreed in advance. Without these, "continuous" produces a dashboard and no decision.
• A change process that feeds in, so a significant architectural change triggers reassessment rather than flowing through unnoticed.

What it is not: an excuse to skip the initial assessment, which establishes the control baseline everything afterwards is measured against. Nor is it fully automatable — the judgement about whether residual risk remains acceptable belongs to a person, and the evidence is what makes their judgement current.

The benefit worth stating in a business case: the authorisation becomes evidence-based rather than belief-based, and the gap between "we were compliant at assessment" and "we are compliant now" closes from years to hours.

Machine-readable evidence feeding an authorization decision automatically

The mechanism underneath continuous authorization, and it is worth being concrete because it is what distinguishes the idea from a slogan.

Evidence is machine-readable when a control's state can be queried programmatically and compared against a stated expectation:

• Configuration from the provider's recorder and assessment rules.
• Identity from the identity provider — group membership, authentication policy, privileged account inventory, access review completion.
• Vulnerability and patch state from the scanning platform, scoped by the asset inventory.
• Pipeline evidence — that every deployment came from a reviewed, signed build, which is lesson fourteen's output consumed as an assurance signal.
• Log pipeline health, because evidence of monitoring requires evidence that monitoring is receiving data.
• Supplier signals, where a provider publishes machine-readable attestation or status.

Three design properties decide whether the collection is trustworthy, and all three are examinable:

• Provenance. Evidence must be collected by an identity the assessed team cannot alter, or the assessed party is producing their own evidence. This is a separation-of-duties requirement and it is the one most often overlooked.
• Completeness. Evidence covering 80% of the estate supports a conclusion about 80% of the estate. The coverage figure belongs next to the result, for the reason lesson five gave about inventories.
• Freshness. Every piece of evidence needs an age, and evidence older than its control's test frequency is not evidence — it is history. A system that silently reuses stale evidence reports a healthy state indefinitely after collection breaks, which is the failure scenario to recognise.

The professional framing: evidence collection is itself a system with availability, integrity and access requirements, and it should be monitored the way any other production dependency is.

The integration that quietly becomes a trust relationship nobody reviews

The closing idea of the objective, and it is the one worth carrying.

Integrations are created in response to a need, by people focused on making something work, and they are almost never retired. Over a few years an estate accumulates: a supplier's role with permissions granted for a migration that finished; a third-party application holding a delegated token granted by an individual; a cross-account trust for a subsidiary that was divested; a service account created for a proof of concept that became production; a VPN to a partner whose contract ended.

Each was reasonable when created. Collectively they are a set of paths into the estate that no architecture diagram shows and no review covers, and they share three properties that make them dangerous: they are long-lived, they are broadly scoped because narrow scoping was harder on the day, and they are unowned, because the person who requested them has moved on.

The governance answer is unglamorous and it is the answer scenarios want:

• Every integration is an asset in the inventory from lesson five, with an owner, a purpose, a scope and an expiry.
• Expiry forces review, and review either renews with justification or removes — the same mechanism as the exception register from lesson one.
• Enumerate from the platform, not from the record, because the record is the thing that is incomplete. Trust policies, federated applications, consent grants, cross-account roles and long-lived keys can all be listed by API, and the difference from the record is the finding.
• Prefer short-lived by construction. Workload identity and short session lifetimes mean a forgotten integration expires by itself, which is the only control in this list that does not depend on anybody remembering.

That last point is the architectural version of the whole lesson: design so the default outcome of neglect is revocation rather than persistence.