Summary
A cloud account, subscription, project, tenant, region, resource, workload, API, route, function, container, virtual machine, object store, database, and workload identity each describe part of an application. None alone proves a reachable service or anonymous access.
Learning objectives and prerequisites
Use basic cloud, DNS, API, and identity terminology. Classify a path as confirmed publicly accessible, publicly reachable with authentication, exposed through an intermediary, private-only validated, intended private but unvalidated, conflicting evidence, or insufficient evidence.
Why this matters
A public IP does not prove anonymous access. DNS does not prove reachability. A private endpoint does not prove every public path is disabled. A gateway, CDN, reverse proxy, or load balancer may expose a backend indirectly. A security-group rule does not prove application-layer accessibility, and authentication does not eliminate authorization risk.
Core concepts and distinctions
Separate resource existence, a deployed service, a published endpoint, publicly addressable, publicly reachable, anonymously accessible, authenticated access, intended public service, unintended exposure, applicable vulnerability, exploitable condition, and confirmed compromise. Control-plane inventory and runtime behavior are different evidence sources; missing inventory or scanner records do not mean safe or absent.
Guided workflow
- Identify account, application, service, component, owner, and business purpose.
- Map endpoints, routes, bindings, DNS, certificates, gateways, proxies, CDNs, and load balancers.
- Review public and private addressing, ingress, egress, security groups, ACLs, cloud firewalls, authentication, anonymous routes, and management interfaces.
- Review service-to-service and lateral paths, compare intended architecture with observed evidence, record gaps, assign bounded confidence, and define the next validation evidence.
Fictional worked example
A fictional retail application uses a CDN, API gateway, web application, internal API, object bucket, managed database, workload identity, administration endpoint, private connection, stale DNS record, and incomplete flow logging. The CDN path is public; the internal API is exposed through an intermediary; the administration endpoint needs identity and VPN evidence; storage policy needs separate review. Incomplete flows leave the service-to-service path uncertain rather than harmless.
Decision exercise
Classify each fictional component as public, authenticated public, intermediary-only, private validated, conflicting, or insufficient evidence. Record the evidence, missing evidence, security implication, and next validation action.
Knowledge checks and answer explanations
- Does a public IP prove anonymous access? No; application, gateway, and identity controls may still require authentication.
- Does DNS prove reachability? No; it identifies a name, not an effective end-to-end path.
- Does a private endpoint prove all public paths are disabled? No; review gateways, proxies, and alternate interfaces.
- Does authentication prove authorization? No; the effective resource permission needs separate validation.
Common misconceptions
Inventory absence proves no resource, scanner failure proves no path, internal exposure is immaterial, or public addressing proves compromise.
Practical takeaway
Record intended and observed path, intermediaries, authentication, enforcement evidence, telemetry gaps, confidence, owner, and the next validation question.
Related content
Cloud Public-Exposure Review, Vulnerability Applicability, Investigation Evidence Quality, DNS Lookup, Product Exposure Note, and Curated CVEs.
Limitations
This lesson cannot prove complete asset inventory, reachability, exposure, exploitability, compromise, or authorization in a real environment.
Last reviewed: Unknown. Recheck local evidence before acting.