Source catalog
The textbook favors official specifications, official documentation, original papers, and primary engineering reports. Version-sensitive entries name the relevant release or access date.
Foundations Source Catalog
Research check date: July 20, 2026. The catalog favors standards, official documentation, original papers, and primary product records. “Rolling” means that the publisher can update the page without issuing a new stable edition; recheck rolling pages before implementation.
Cloud definitions and orientation
| Source | Status or date | Use in the manuscript | Currency note | |---|---|---|---| | NIST SP 800-145, *The NIST Definition of Cloud Computing* | Final, September 2011 | Five essential characteristics; IaaS, PaaS, SaaS; deployment arrangements | Durable classification, not a security certification or implementation guide | | NIST SP 800-146, *Cloud Computing Synopsis and Recommendations* | Final, May 2012 | Benefits, limitations, reliability, performance, and security qualifications | Product details are historical; principles remain useful | | Google Cloud Compute Engine: Regions and zones | Rolling | Regional and zonal placement | Zone inventory and machine availability change | | Microsoft Azure: Regions overview | Rolling | Regions, geographies, availability zones, data residency | Exact resiliency choices vary by region and product | | AWS GovCloud (US): What is AWS GovCloud (US)? | Rolling | Isolated government regions and shared responsibility | Compliance scope, endpoints, and product availability change | | AWS GovCloud (US): Using the regions | Rolling | Distinct us-gov-* names, endpoints, and partitions | Check the exact target partition | | Azure Government comparison | Rolling | Endpoint, feature, and configuration differences | Government and global feature parity changes | | Google Cloud Assured Workloads overview | Rolling; control-package names changed June 2025 | Regulated-workload guardrails and violation monitoring | A control package does not transfer customer compliance responsibility |
Historical primary records
| Source | Status or date | Use in the manuscript | Qualification | |---|---|---|---| | R. J. Creasy, *The Origin of the VM/370 Time-Sharing System* | IBM engineering paper, 1981 | CTSS influence, CP-40/CMS, design motives, operational lineage | Retrospective primary engineering account | | IBM z/VM history timeline | Official archive | VM/370 announcement date and linked artifacts | Timeline is a vendor-preserved selection | | Popek and Goldberg, “Formal Requirements for Virtualizable Third Generation Architectures” | *Communications of the ACM*, July 1974 | Formal virtual-machine monitor properties | Applies to its modeled architectures; modern mechanisms extend the setting | | AWS: Amazon S3 announcement | March 13, 2006 | Public object-storage landmark | Original claims do not describe current S3 scope | | AWS: Amazon EC2 beta announcement | August 24, 2006 | On-demand VM capacity and usage charging landmark | Beta scope, prices, and limits are historical | | Google: App Engine introduction | April 7, 2008 preview | Managed application-platform landmark and original quotas | Preview behavior is not current App Engine documentation | | Microsoft: Windows Azure announcement | October 27, 2008 technology preview | Azure platform landmark | Original branding and scope are historical |
Internet standards and measurement
| Source | Current role | Use in the manuscript | Important update or exception | |---|---|---|---| | RFC 9499, *DNS Terminology* | Best Current Practice 219, March 2024 | Current resolver, authoritative-server, zone, and answer terminology | Obsoletes RFC 8499; terminology guide, not a complete tutorial | | RFC 1034 and RFC 1035 | Foundational DNS architecture and format | Names, resource records, resolvers, caching | Both have many later updates; DNS uses more than one transport | | RFC 7766, *DNS Transport over TCP* | Standards Track | Correction to “DNS uses only UDP” | Encrypted DNS adds other transport arrangements | | RFC 4632, *CIDR* | Best Current Practice 122 | Prefix arithmetic, aggregation, longest match | Provider-reserved subnet addresses are separate product rules | | RFC 8200, *IPv6* | Internet Standard 86 | IPv6 base mechanism | RFC status page lists later updates | | RFC 9293, *TCP* | Internet Standard 7, August 2022 | Reliable ordered byte-stream mechanism | Obsoletes RFC 793 as the base TCP specification | | RFC 9000, *QUIC* | Proposed Standard | Secure multiplexed transport over UDP datagrams | Corrects the inference that every UDP-based application is unreliable | | RFC 9110, *HTTP Semantics* | Internet Standard 97, June 2022 | Version-independent HTTP meaning | Pair with RFC 9112, 9113, or 9114 for HTTP/1.1, HTTP/2, or HTTP/3 framing | | RFC 9846, *TLS 1.3* | Proposed Standard, July 2026 | Current TLS 1.3 handshake and record protection | Obsoletes RFC 8446 while retaining TLS 1.3 and backward compatibility | | RFC 5136, *Defining Network Capacity* | Informational | Capacity, available capacity, utilization, and interval terms | Definitions support measurement; the RFC does not promise achievable application throughput | | curl manual | Rolling official tool documentation | Cumulative timing fields and negotiated protocol evidence | Record curl -V; supported protocols depend on the build |
Current cloud networking documentation
| Source | Use | Version-sensitive point | |---|---|---| | AWS VPC and subnet basics | A VPC spans a region and an AWS subnet belongs to one Availability Zone | Reserved addresses, IPv6 options, and defaults change | | AWS subnet route tables | Destination/target routes and longest-prefix selection | Available targets change | | AWS security groups | Stateful interface-level allow rules | Multiple attached groups aggregate; exact managed features change | | Google Cloud VPC overview | Global VPC with regional subnets spanning zones | Scope differs from AWS and Azure terminology | | Google Cloud firewall rules | Stateful network-level allow and deny behavior enforced per instance | Hierarchical and policy features require current documentation | | Azure virtual-network FAQ | Regional virtual networks and zone-spanning subnets | Scope differs from AWS subnet placement | | Azure network security groups | Ordered stateful five-tuple rules | Existing tracked connections can outlive a rule removal |
Virtualization and containers
| Source | Status | Use | Currency note | |---|---|---|---| | Linux kernel KVM API | Rolling kernel documentation; stable ABI since Linux 2.6.22 | VM, vCPU, and virtual-device creation interfaces | Query KVM_CAP_* capabilities; do not infer from version alone | | Linux kernel cgroup v2 guide | Rolling kernel documentation | Hierarchical process organization, controllers, observable files | Match documentation to the installed kernel and cgroup mode | | OCI Image Specification | Standards Track; site showed November 2025 publication | Manifests, indexes, content descriptors, layers, configuration | Record the selected specification release for implementation | | Docker resource constraints | Rolling official documentation | Default lack of constraints and CPU/memory limit behavior | Kernel and cgroup support affect available controls | | Google Compute Engine overview | Rolling; last updated July 17, 2026 when checked | Current IaaS classification and KVM statement | Machine families, availability, and objectives change | | AWS nested virtualization | Rolling | Physical/Nitro, guest, and nested-guest layers | Supported types, processors, and regions change | | IBM z/VM 7.4 Control Program overview | Versioned product documentation | Virtual processor, storage, and device mapping | Applies to z/VM 7.4.0; select matching docs for other releases |
Source-use rules for later revisions
- Use RFC Editor status pages rather than an old RFC number from memory. The July 2026 replacement of RFC 8446 by RFC 9846 demonstrates why status checks matter.
- Record provider, product, region or partition, documentation date, and configuration for a version-sensitive claim.
- Treat launch announcements as evidence of what was announced, not evidence of current behavior.
- Treat provider configuration listings as management-plane evidence, not proof of end-to-end request completion.
- Preserve units, observation intervals, artifact producers, and untested alternatives with every empirical claim.
Part II Source Catalog
Research cutoff: July 20, 2026. The catalog records the authoritative sources used for Chapters 5–8. Official documentation is still versioned evidence rather than a permanent fact. Recheck every region, product, quota, price, compliance scope, endpoint, cryptographic validation, and policy behavior before a production or authorization decision.
Source-selection method
Provider documentation is authoritative for current provider behavior. NIST publications and FedRAMP material are primary government sources for the federal risk and authorization discussion. Provider compliance pages establish the provider's described offering and scope; they do not establish a customer's legal obligations or authorize a customer workload.
Each entry has one of two stability labels:
- Durable mechanism: the source supports a concept that changes slowly, although wording and implementation can evolve.
- Version-sensitive: the source describes current product inventory, defaults, limits, interfaces, assurance scope, or program procedure that must be checked again.
Chapter 5: AWS core platform and request path
Use: Defines Regions, Availability Zones, regional resources, and explicit replication responsibility. Stability: Durable geographic and isolation mechanism; Region and zone inventory is version-sensitive.
Use: Documents zone names, stable zone identifiers, and 2026 account-mapping qualifications. Stability: Version-sensitive because mappings, constrained zones, and inventory change.
Use: Supports the DNS alias-to-load-balancer request stage. Stability: Durable DNS mechanism with version-sensitive console and address-family details.
Use: Defines listeners, rules, target groups, registered targets, and multi-zone traffic distribution. Stability: Durable request mechanism; supported features are version-sensitive.
Use: Documents periodic checks, thresholds, target states, and fail-open behavior when all targets are unhealthy. Stability: Version-sensitive implementation documentation.
Use: Explains protocol, port, health, draining, algorithms, and routing-failover details. Stability: Version-sensitive product behavior.
Use: Establishes that each subnet has an associated route table and that a route maps a destination to a target. Stability: Durable routing mechanism.
Use: Defines minimum, desired, and maximum capacity, instance replacement, policies, and load-balancer integration. Stability: Durable capacity-control mechanism; current features are version-sensitive.
Use: Qualifies standby and failover behavior for the selected managed database topology. Stability: Version-sensitive because engines, deployment types, and behavior change.
Use: Identifies AWS-produced and customer-published measurements and the OpenTelemetry and classic metric paths documented in July 2026. Stability: Version-sensitive interface and limit documentation; measurement units and aggregation remain durable concepts.
Use: Connects capacity, failure management, quotas, recovery, and testing. Stability: Durable engineering guidance with periodically revised recommendations.
Chapter 6: Google Cloud and Azure comparison
Use: Defines organization, folder, project, product resource, parentage, and policy inheritance. Stability: Durable hierarchy with version-sensitive creation and eligibility details.
Use: Confirms projects as fundamental organizing entities and explains governance services. Stability: Durable organizational mechanism.
Use: Distinguishes global and regional, internal and external, proxy and passthrough, Layer 4 and Layer 7, and network tiers. Stability: Version-sensitive product portfolio.
Use: Supports the distinction between a global Google Cloud VPC network and regional subnets and products. Stability: Durable scope model with version-sensitive product examples.
Use: Identifies provider and customer security work across infrastructure, platform, software, and function offerings. Stability: Durable responsibility concept; provider program descriptions can evolve.
Use: Explains Azure resource management, resource groups, subscriptions, and management scopes. Stability: Durable hierarchy and deployment mechanism.
Use: Distinguishes Azure Front Door, Application Gateway, and Azure Load Balancer use cases. Stability: Version-sensitive product portfolio.
Use: Defines Azure geographies, regions, and zone concepts. Stability: Durable geographic mechanism with version-sensitive support lists.
Use: Demonstrates that limits attach to specific scopes and that some quotas require provider approval. Stability: Highly version-sensitive; never copy values into long-lived capacity assumptions.
Use: Distinguishes customer, shared, and Microsoft work across infrastructure, platform, and software offerings. Stability: Durable responsibility model with periodically revised product examples.
Chapter 7: identity, data, reliability, and cost
Use: Documents authentication, request context, allow unions, limiting intersections, and explicit denies. Stability: Durable policy mechanism; new policy types and special cases are version-sensitive.
Use: Provides concrete identity-policy, resource-policy, and explicit-deny examples. Stability: Durable worked mechanism subject to current IAM rules.
Use: Establishes current strong read-after-write behavior, atomic single-key updates, and the conditions around successful writes. Stability: Provider guarantee that must remain tied to current documentation.
Use: Separates durability, availability, versioning, Object Lock, and replication. Stability: Durable distinctions with version-sensitive classes and objectives.
Use: Identifies event fields, timestamp origin, optionality, regions, source addresses, user agents, and errors. Stability: Version-sensitive schema; the page currently documents event format versioning.
Use: Distinguishes management, data, network activity, and Insights events and their collection behavior. Stability: Version-sensitive event categories and defaults.
Use: Documents the current recent-management-event view and explains why absence from event history is not proof that other activity did not occur. Stability: Version-sensitive retention and interface behavior.
Use: Defines RTO and RPO and connects both objectives to business impact and testing. Stability: Durable recovery terminology.
Use: Separates data-plane and control-plane availability and recommends workload-specific objectives. Stability: Durable architecture guidance.
Use: Documents current cost views, estimates, and data freshness qualifications. Stability: Version-sensitive billing interface; no textbook number should replace a current invoice or price page.
Use: Confirms that customers select tiers, configure and verify backups, meet service-level-agreement conditions, and design resilient applications. Stability: Durable responsibility concept with version-sensitive product examples.
Chapter 8: AWS for government work
Use: Primary federal standard for categorizing information and information systems by potential confidentiality, integrity, and availability impact. Stability: Durable normative standard; check NIST for superseding publications or policy.
Use: Primary source for the Risk Management Framework lifecycle, assessment, authorization, and continuous monitoring. Stability: Durable normative guidance; check NIST for revisions.
Use: Primary security and privacy control catalog. The NIST page identifies later minor releases and supplemental material. Stability: Version-sensitive release; control concepts remain durable.
Use: Identifies the current statutory responsibilities of agencies and the limits of reusable provider authorization evidence. Stability: Version-sensitive legal and policy reference.
Use: Primary current guidance distinguishing reusable provider certification material from an agency information-system risk decision and ATO. Stability: Highly version-sensitive program procedure.
Use: Describes the agency authorization path and the need to define a cloud offering's authorization boundary. Stability: Version-sensitive program process.
Use: Documents AWS's intended workload categories, isolation, U.S.-citizen administration of the AWS boundary, FIPS endpoints, and customer access responsibility. Stability: Version-sensitive provider description.
Use: Documents credentials, endpoints, authentication separation, billing association, network isolation, and service differences. Stability: Version-sensitive implementation and account documentation.
Use: Documents current eligibility and separate-organization requirements. Stability: Highly version-sensitive eligibility and onboarding process.
Use: Establishes the one-to-one standard-account association and separate AWS Organizations structures. Stability: Version-sensitive account mechanism.
Use: Documents distinct credentials and current access methods and warns that cryptographic-library choices still matter. Stability: Version-sensitive access documentation.
Use: Documents the aws-us-gov partition string and Region codes. Stability: Durable naming mechanism, subject to current provider documentation.
Use: Documents current control-plane endpoints and FIPS 140-3 qualifications. Stability: Highly version-sensitive endpoint list.
Use: Product-by-product differences, availability, and export-controlled-content guidance. Stability: Highly version-sensitive catalog.
Use: Dated provider table for service status within the Moderate and High boundaries. The researched page reported a June 18, 2026 update. Stability: Highly version-sensitive compliance scope.
Use: Provider source for infrastructure responsibility and customer duties that vary by selected product. Stability: Durable responsibility division with version-sensitive examples.
Use: Primary source for active validation status, federal use, and the FIPS 140-2 to FIPS 140-3 transition. Stability: Highly version-sensitive validation and transition status.
Use: Primary clarification that validation of a module does not assure correct product use of the module. Stability: Durable qualification with version-sensitive program details.
Known research limitations
- Provider documentation states provider behavior and scope; independent assessors and agency officials still evaluate CivicPermit.
- Pricing examples in Chapter 7 are explicitly invented teaching assumptions. No example price should be used for procurement.
- Restricted FedRAMP authorization-package content was not accessed or reproduced. Chapter 8 teaches how to index approved evidence without claiming access to restricted material.
- Legal conclusions about PII, CUI, International Traffic in Arms Regulations, criminal justice information, tax information, defense impact levels, or agency-specific overlays depend on facts outside this textbook. The chapter names the decision process and relevant specialists instead of giving a legal guarantee.
Part III and IV sources
Containers and image execution
- Docker documentation is the current product reference for image builds, runtime inspection, storage, and networking. The manuscript separates Docker behavior from OCI standards.
- Open Container Initiative image specification and runtime specification are the primary interoperability specifications.
- Linux kernel control group v2 is the primary kernel documentation for cgroup accounting and control.
Kubernetes
- Kubernetes documentation supplies the current and versioned architecture, workload, networking, storage, security, and operations references. The current site exposed version 1.36 in July 2026; readers must select the version matching their cluster.
- Kubernetes API reference v1.36 supplies exact fields matching the current documentation version cited in July 2026.
- etcd documentation describes the consistent store commonly used by the Kubernetes control plane.
Network edge and protocols
- Cloudflare DNS documentation and CDN reference architecture supply current product behavior and architectural claims.
- RFC 1034, RFC 1035, RFC 9111, and RFC 4271 provide protocol foundations for DNS, HTTP caching, and Border Gateway Protocol routing.
Production practice and capstone
- OpenTelemetry specifications define telemetry data and application programming interfaces. Signal and language maturity remain version-sensitive.
- Google Site Reliability Engineering is a primary engineering report for service objectives, monitoring, error budgets, and incident practice.
- NIST Special Publications supply authoritative United States government guidance for controls and contingency planning. Applicability depends on the organization and authorization context.
- AWS Well-Architected, Google Cloud Architecture Framework, and Microsoft Azure Well-Architected Framework provide provider-specific architecture review material.