Cloud Foundations

AWS, Microsoft Azure and Google Cloud provide computing services that you configure and use through consoles, APIs and automation. This guide compares architectural behavior. It does not assume a certification or prior experience.

Start With One Application

Imagine a photo-sharing application. A person uploads a photo, adds a caption, and later views it. The architecture has six decisions:

These are requirements, not a claim that every application needs the same products. The architecture atlas draws a logical request flow and three provider-specific implementations. They are alternatives, not a requirement to deploy to all three clouds.

What You Still Manage

A managed service reduces some operational work; it does not remove responsibility for data, access or configuration. In SaaS, customers still control user access, data handling and available application settings. IaaS generally also leaves the guest operating system and application stack to the customer. The exact division depends on the service. AWS shared responsibility, Azure shared responsibility, Google shared responsibility.

Vocabulary for the Next Chapter

Treat pricing, quotas and service availability as design inputs to check, not constants to memorize. A cheaper storage rate may be outweighed by retrieval or transfer costs. A replicated database can still replicate an accidental deletion.

Learn the Provider Boundaries

An AWS account, an Azure subscription and a Google project are useful starting points for resource administration, but they are not interchangeable billing and identity systems. Resource models explain those differences before the service catalogue.

Choose a Reading Route

• New to cloud: resource models, identity, then networking.
• Already know one provider: use the decoder and architecture atlas to test which assumptions transfer.
• Studying for an exam: use the exam map to find official objectives.

Market-share estimates and adoption surveys are not architecture requirements. Earlier research notes retain their historical context; they are not evidence that a provider is the best choice for this application.

Resource Ownership, Identity and Geography

Three questions need three answers: who administers a resource, where it runs, and which identity can access it. Billing is a related fourth question. Drawing all four as one nested hierarchy teaches the wrong model.

Administrative Ownership

The arrows in this drawing mean administrative parentage. They are not network connections. Optional intermediate groups are labelled. Regions and zones do not belong in this tree.

Sources: AWS Organizations, AWS billing, Azure resource scopes, Google hierarchy.

Network Membership and Location

An AWS VPC is regional and its subnets each occupy one Availability Zone. An Azure VNet and its subnets are regional. A Google VPC is global and its subnets are regional. A Google project owns network resources; it does not own geographic regions. A VPC does not own a zone. AWS subnets, Azure VNets, Google VPCs.

A global network can connect regional resources; it does not make those resources global or resilient to regional failure. Routing, firewall rules and authorization still apply.

Grouping and Deletion

Sources: AWS resource groups, AWS OUs, Azure deletion, Google folders, Google projects.

Failure Domains Are Not Guarantees

An Azure availability set separates fault and update domains within a datacenter; it is not a multi-zone design. To tolerate a zone outage, place enough capacity in other zones and ensure clients, data and dependencies can fail over. A single VM in a zone remains a single VM. Azure availability sets.

AWS AZ names can map differently across accounts. Use AZ IDs to align physical locations when sharing resources. Do not replace “can differ” with “always differ.” AWS AZ IDs.

Quotas and Names

Nesting depth, project-creation quotas and resource-name rules are service-specific. Check current limits when designing an organization. S3 general-purpose bucket names, for example, are unique within an AWS partition; not every S3 bucket type has identical naming rules. AWS Organizations quotas, Azure management groups, S3 naming.

Identity and Access

Goal: explain who can act, what they can do, and where the permission applies. Start with cloud foundations if these terms are new.

An identity represents a person or a workload. Authentication establishes that identity; authorization decides whether its request is permitted. A principal is the identity making a request. A scope is the resource or collection to which a grant applies.

Same Word, Different Object

The nearest translation runs the other way from the name: an Azure or Google role is closest to an AWS managed policy, and an AWS role is closest to a service principal or service account. The categories match; the trust and credential mechanisms do not. AWS · Azure · Google

Directory Administration Is Not Workload Access

For Azure, Global Administrator does not itself grant access to virtual machines. An elevated administrator receives User Access Administrator at root scope and can assign the needed resource roles. For Google, Organization Administrator manages organization IAM; it is not unrestricted access to all workloads. Keep recovery administration separate from routine work. AWS workforce access, Azure elevation, Google separation of duties.

How to Evaluate an AWS Request

First identify the principal, resource, account relationship, action, and applicable policies. Identity and resource policies can grant access; boundaries and organization policies constrain it. An applicable explicit deny overrides an allow. The interaction depends on context, so a single six-step “every layer must allow” rule is misleading. AWS evaluation logic.

Worked decision: an identity grant constrained by a boundary

Assume an IAM user requests s3:PutObject. Its identity policy allows that action, but its permissions boundary allows only s3:GetObject. There is no resource-policy grant and no other policy grants or restrictions in this example. Denied: the identity grant is limited by the boundary. Adding another identity allow does not expand the boundary.

Worked decision: a same-account resource grant

Assume an S3 bucket policy grants s3:GetObject directly to an IAM user's ARN in the same account. The user's identity policy and boundary omit that action, but neither explicitly denies it. No other applicable control restricts the request. Allowed: this kind of direct resource grant is not limited by those implicit denies. Naming a role ARN instead changes the analysis. AWS boundary and principal rules.

These are deliberately bounded examples, not advice to use IAM users for application credentials. For real requests also consider cross-account access, session policies, organization controls, resource-specific settings, conditions, and explicit denies.

Inherited Grants in Azure and Google Cloud

Assigning a smaller role at a child resource does not subtract a grant inherited from its parent. An Azure Reader assignment on a resource group does not reduce a subscription-level Contributor grant. In Google Cloud, a project-level Viewer grant does not reduce inherited Editor access. Deny controls and conditions can restrict effective access; changing an allow grant alone is not the same operation. Configuration governance (Azure Policy or Google Organization Policy) answers a separate question from who may perform an operation. Azure access model, Google resource hierarchy, Google deny policies.

Give the Application an Identity

An Azure system-assigned managed identity follows the resource lifecycle; a user-assigned identity is independent and can be shared. A Google service account is both an identity and a resource: permission to attach or impersonate it differs from the permissions it exercises. Prefer attached identities or federation to distributing long-lived keys, where the workload supports them. AWS instance profiles, Azure managed identities, Google service accounts.

Check Your Understanding

A photo service needs to create objects in one bucket. Does giving it an organization-wide administrator role solve the problem well?

Answer and reasoning:

It may grant sufficient access, but it grants far more than the task needs. Give the workload an identity and an object-creation permission at the appropriate resource scope. Check whether it also needs to read, overwrite, or delete objects before adding those permissions. A role's name is not evidence that its permissions fit the task.

Networking: Reachability Is Not Authorization

A successful request needs name resolution, a route, permitted traffic, a listening service and application authorization. A private address alone establishes none of the other four.

Network and Subnet Scope

AWS VPCs and Azure VNets are regional. Google VPC networks are global. AWS subnets are zonal; Azure and Google subnets are regional. Defaults depend on account or project creation and organization policies, so inspect the actual network instead of assuming a default exists. Network and location drawing.

Traffic Filtering

A new AWS security group has no inbound rules, while a default security group allows inbound traffic from members of that group. Default and custom network ACLs also have different initial rules. In Azure, custom NSG rules have higher precedence than built-in defaults. In Google, a deny takes precedence over an allow at the same priority; omitted targets mean all instances in the network, while supported selectors include network tags and service accounts. AWS security groups, AWS ACLs, Azure NSGs, Google firewall rules.

To block an address while broad AWS security-group allows remain, select a suitable deny-capable control. An ACL is one option; a network firewall or application-layer rule may better match the traffic and inspection requirement. A stateless ACL needs explicit return-path rules.

Outbound Access

For IPv4 internet access, choose an explicit egress path and inspect routes and firewall rules. AWS has both zonal and regional NAT gateways. Regional automatic mode can expand across workload zones, but expansion is not instantaneous and regional NAT does not support private NAT. Azure NAT Gateway behavior depends on SKU and configuration. Google Cloud NAT provides translation through distributed networking rather than a NAT VM in the packet path. AWS regional NAT, Azure NAT, Google Cloud NAT.

A NAT gateway is not a way to accept unsolicited inbound requests. Public IPs, proxies and load balancers have separate purposes. IPv6 egress has different design options.

Connecting Networks

Ordinary VPC/VNet peerings are not transit routers. A-to-B and B-to-C peering alone does not create A-to-C reachability. Address overlap and route exchange restrictions vary by provider and address type. Use a supported transit design for a hub network. AWS peering, Azure peering, Google peering.

Direct Connect, ExpressRoute and Cloud Interconnect provide private connectivity options; private connectivity is not a universal promise of encryption. Verify encryption, routing, redundancy and failure behavior for the selected connection.

Accessing Managed Services Privately

Sources: AWS gateway endpoints, AWS PrivateLink, Azure service endpoints, Azure private endpoints, Google private access, Google PSC.

Creating a private endpoint does not universally disable the service's public endpoint, grant data access, or solve DNS. The managed service remains outside the consumer subnet; the endpoint is the network entry point, not the service itself.

Load Balancing and DNS

These are functional comparisons, not identical implementations. CloudFront is also a CDN; Global Accelerator is a TCP/UDP service, not a layer-7 header-routing engine. DNS steering does not proxy the connection or migrate established sessions. Proxy failover also does not promise that an existing connection survives an origin failure. AWS global acceleration, Azure Traffic Manager, Azure Gateway Load Balancer, Google DNS routing, Google load balancing.

Cloud Architecture Atlas

These are conceptual and logical architecture drawings for learning. They are not deployment plans, a security certification, or a claim that a provider guarantees an application's recovery time. Each view answers one question; read its assumptions before adapting it.

For network placement and recovery decisions, continue to the three deployment reference architectures. They connect ingress, private application access, database availability and operational responsibilities.

How to Read These Architectures

Follow the labelled arrows, then check which network and failure boundaries they cross.

Ownership views omit geographic containment. Network views keep managed services outside the consumer subnet. Application views show logical service relationships, not hidden provider infrastructure. Full-size SVGs remain readable when opened separately; the web guide also allows horizontal scrolling without shrinking labels on a phone. Text descriptions accompany each view.

One Application, Three Implementations

A user uploads a photo through an authenticated HTTPS endpoint. Application code checks ownership and content, stores photo bytes in object storage, then stores an object key and caption in a database. The workload uses its own identity for data operations; the user's identity is a separate authorization concern.

These examples intentionally omit CDN delivery, upload acceleration, private networking and multi-region recovery. The database and object writes are not one transaction: use idempotent requests and a recovery/cleanup strategy for partial failures. For large files, consider a short-lived signed upload URL rather than sending the whole file through application code.

AWS

API Gateway invokes Lambda; the Lambda execution role grants the required S3 and DynamoDB operations. Configure the API's authentication/authorization and object-access controls. Do not place these regional managed service boxes inside a VPC unless a selected integration actually requires it. API Gateway integration, Lambda execution role, S3, DynamoDB.

Azure

An HTTP-triggered Function is the application endpoint. A managed identity can access Blob Storage and a supported Cosmos DB API using appropriate data-plane roles. Choose a Functions hosting plan and configure end-user authentication; a function access key alone is not a user identity or ownership check. The logical subscription boundary is not a VNet boundary. HTTP functions, Functions identity, Blob authorization, Cosmos DB data roles.

Google Cloud

Cloud Run executes the application with a service account. Grant that account the required Cloud Storage and Firestore permissions. Define who may invoke the service and how the application identifies and authorizes its users. The drawing does not imply that the managed services live inside a consumer VPC. Cloud Run service identity, Cloud Storage access, Firestore server access.

Resource Ownership and Network Geography

Arrows represent administrative parentage. AWS OUs and Google folders are optional; the Azure view is within one directory and includes optional intermediate management groups. This does not draw the separate identity or billing associations. Resource groups cover resource-group scope, not every Azure resource type. Resource models and sources.

A subnet belongs to a virtual network but has its own location rule. AWS subnets are zonal; Azure and Google subnets are regional. A global Google network does not make a regional VM or database global. Scope sources.

Identity and Permission Decisions

The first row shows successful AWS role assumption followed by a resource request. The second shows a principal receiving a role at a scope in Azure or Google. Inherited grants remain subject to applicable conditions and deny controls. Identity explanation and sources.

In A, an identity grant cannot exceed the permissions boundary. In B, a same-account bucket policy directly names an IAM user; identity/boundary omissions alone do not block that grant. Assume no explicit deny or other restriction. Changing the principal type or account relationship changes the evaluation. AWS boundaries.

Firewall Placement and Private Access

The view compares native controls, not all available firewall products. Azure traffic must pass both NSGs when both subnet and interface NSGs apply. Google selectors apply rules to VM interfaces. Networking details and sources.

The endpoint is in the consumer network; the supported managed service is outside it. Hybrid access additionally requires DNS and routing. Private connectivity neither grants data permissions nor universally disables public access. Endpoint details and sources.

Database Replication and Recovery

The DB instance pattern has an unreadable standby. The DB cluster has two readable failover targets and semisynchronous replication; it is distinct from Aurora. An ordinary read replica is not automatic source failover. Engine, version, region and replica lag matter. RDS DB clusters, RDS DB instances, RDS replicas.

This example is specifically an RDS Multi-AZ DB instance. Promotion and DNS changes do not preserve existing database sessions; applications need reconnection and safe retry behavior. The same-region standby is not a complete response to a regional outage or accidental deletion. RDS failover.

Shared Responsibility

Customers retain data and access responsibilities even with SaaS. This is a responsibility summary, not a network diagram or an exhaustive contract matrix. Foundations and sources.

Before Using a Drawing for a Real System

Document the selected regions, service tiers, traffic volumes, trust model, RTO/RPO, backup retention and tested failure modes. Add monitoring, deployment and rollback behavior, cost estimates and operational ownership. Validate supported integrations against current provider documentation rather than inferring them from two boxes connected by a line.

Design a Resilient Web Application

A service comparison helps you find names. An architecture explains how requests reach your application, who can access its data, and what happens when a component fails. These three reference designs serve the same requirement: an internet-facing application with private application/data access and resilience to a zone failure within one region.

Start with the simpler photo applications if you are learning cloud basics. Use these deployment views when network placement and recovery become requirements. They are illustrative designs, not tested deployments or a promise of an availability target. Groups labelled “resources in” or “VMs in” a zone identify the depicted resources that share a failure location. A VPC or subnet does not own an availability zone.

Choose the Operating Model First

These are design choices, not claims that a cloud only supports that operating model. AWS and Google also offer managed application runtimes; Azure also offers VM scale sets. Start with the simplest service that meets the workload's constraints, then add infrastructure for a specific requirement. Compare managed and self-managed responsibilities.

AWS: Private Compute Across Two Zones

1. DNS resolves the public ALB address; clients connect with HTTPS. Associate a WAF policy with the ALB and configure its TLS certificate. DNS is name resolution, not an inline traffic hop.
2. The ALB forwards requests to healthy EC2 targets. Use public ALB subnets in two zones and private application subnets. One Auto Scaling group spans the zones; the diagram's boxes represent pools, not a requirement for exactly two instances.
3. Both application pools connect to the same RDS writer endpoint using encrypted database connections. This example selects a Multi-AZ DB instance with a non-readable standby. The synchronous replication arrow is provider-managed, not application dual-writing.

Allow only the application's port from the ALB security group to the application group, and only the database port from the application group to the database group. Also permit required health checks. Use workload roles for AWS API access. Database authentication remains a separate choice; a VM's IAM role alone does not grant SQL permissions. Define outbound routes and endpoints for updates and dependencies; those paths are omitted from this request view.

Failure behavior: health checks remove unhealthy targets; the application must reconnect when RDS fails over. Keep enough capacity in the surviving zone rather than assuming new capacity appears immediately. A same-region standby does not protect against every data error or regional outage.

Sources: ALB subnet and zone requirements, load-balancer routing, RDS instance replication, RDS failover and DNS.

Azure: Two Different Private Paths

1. Clients reach the public Application Gateway over HTTPS.
2. The zone-redundant WAF_v2 gateway evaluates traffic and uses private DNS to resolve its backend.
3. An App Service private endpoint provides the inbound path to the web app. Disable App Service public access explicitly.
4. App Service uses a different, delegated integration subnet for outbound connections.
5. Private DNS resolves the SQL hostname to a SQL private endpoint.
6. Private Link connects that endpoint to Azure SQL Database. Disable the SQL public endpoint and configure database permissions for the application's managed identity.

This drawing separates app and SQL private endpoints into two subnets for clarity and policy control. Microsoft’s baseline shares a private-endpoint subnet; splitting it is a design choice, not a Private Link requirement. The delegated integration and gateway subnets remain separate.

Choose supported App Service and SQL tiers, explicitly enable zone redundancy, and size for surviving capacity. The managed application and database are drawn outside the consumer VNet; private endpoints do not move these services into your subnet. The design omits Key Vault, logging paths and administrative access for readability; define them before implementation.

Failure behavior: zone redundancy must exist in every required tier. Application retries must tolerate interrupted database connections. The inbound private endpoint cannot replace outbound VNet integration.

Sources: Microsoft's App Service baseline and network flows, Azure SQL availability and tier support.

Google Cloud: Global Front Door, Regional Dependencies

1. Clients reach the global external Application Load Balancer over HTTPS. Attach a Cloud Armor policy to the appropriate backend service.
2. A regional managed instance group distributes application VMs across selected zones. Its subnet is regional even though the VPC network is global. Configure firewall rules for the selected load-balancer proxy and health-check sources; do not expose VM public IPs.
3. Application VMs use the database's private address with encrypted connections and database authentication. Workload service accounts govern permitted Google API calls separately.
4. This design chooses private services access: allocate an address range and establish the private connection used by Cloud SQL. Cloud SQL remains outside the consumer VPC. Private Service Connect is a different option and is not the path illustrated here.

Choose a Cloud SQL HA configuration in the same region, disable its public IP and configure backups and point-in-time recovery. Separate application health checks, load-balancer health checks and autohealing decisions so a slow dependency does not trigger needless replacement.

Failure behavior: reserve capacity across the selected zones and reconnect after database failover. A global load-balancer address does not make the regional VM group or Cloud SQL instance survive a regional outage. Cloud SQL's HA standby is not a read-scaling endpoint.

Sources: regional instance groups, Cloud Armor and firewall integration, global web-service ingress, Cloud SQL private IP connections, Cloud SQL HA behavior.

Turn the Drawing Into an Operational Design

The following are review questions for all three designs. The team must choose and test the answers for its workload; the boxes alone do not supply them.

For regional recovery, design a second-region data strategy, traffic switching and operational runbook explicitly. Choose the write model and acceptable replication lag before drawing a second region. More replicas alone do not solve conflicting writes or accidental deletion.

What Each Design Gives Up

An architecture that lists only what it provides is a brochure. All three vendors publish a review framework and expect a design to be defensible against it: AWS names six pillars (operational excellence, security, reliability, performance efficiency, cost optimization and sustainability), with equivalents from Azure and Google.

These three designs share a requirement, so they share their trade-offs. Each line is a deliberate choice, not an oversight.

If a requirement makes one of these unacceptable, change the design rather than the diagram. Measure the bottleneck before adding replicas or regions. A dependency, failed deployment or untested restore can dominate recovery even when compute spans several zones.

Three Things to Explain Back

• Why does a private endpoint still need both DNS and data permissions?
• Which dependency would stop this application if its entire region became unavailable?
• How would you prove that a backup can meet the business's recovery-time target?

A useful answer follows the request through every dependency and names the test that would prove recovery. Continue with failure and identity practice.

Databases: Read Scaling and Surviving Failure

Goal: choose a database deployment based on what must keep working. Prerequisite: cloud foundations. A database stores structured information that the application needs to query or change, such as the owner and caption of a photo.

Three Different Questions

• Availability: can the application recover when a machine or zone fails?
• Read scaling: can reporting queries run somewhere other than the writer?
• Recovery: can we restore data after a mistake, deletion, or larger outage?

A replica is a copy. That word alone tells you neither whether clients can read it nor whether it can become the writer automatically. Replication also copies many mistakes; it is not a substitute for backups and a tested restore procedure.

Read the Deployment Type

The other two clouds draw the same distinction with different names:

Sources: RDS deployment types, RDS read replicas, Azure local and zone redundancy, Azure geo-replication, Cloud SQL MySQL HA.

Before and After a Zone Failure

The drawing illustrates a primary/standby pattern, not every database deployment. The application must reconnect and retry safely during failover. A region-wide outage needs a separate recovery plan. Do not label a single-region standby diagram “disaster recovery” without defining the disaster.

Work Through a Decision

Your photo application's database uses an RDS Multi-AZ DB instance. A slow reporting query must move away from the primary. Can it run on the existing standby?

Answer and reasoning:

No. That standby does not serve reads. Evaluate a read replica, a different deployment such as a supported Multi-AZ DB cluster, or a separate analytics path. Keep the availability requirement while deciding how much replication lag reporting can tolerate. “Multi-AZ is never readable” is also wrong: the DB cluster deployment has readable standbys.

Change one constraint: the database must keep writes available after a zone failure. Adding an ordinary asynchronous read replica alone is not enough to claim automatic failover. Specify how failover happens, how clients reconnect, and what data-loss window is acceptable.

The word means something else here

16 terms the three clouds use differently. 7 of them name a different kind of thing rather than the same thing behaving differently, which is why a service comparison table cannot hold them.

No term matches. Show all terms

Service equivalents

38 mappings across 6 domains, 14 of them graded serious. Each row states how far the equivalence can be trusted, and what differs when it cannot.

• Compute and Containers7 mappings, 0 graded serious
• Databases and Analytics6 mappings, 1 graded serious
• Resource Hierarchy and Scoping6 mappings, 5 graded serious
• Identity and Access6 mappings, 4 graded serious
• Networking8 mappings, 2 graded serious
• Storage5 mappings, 2 graded serious

Compute and Containers

7 mappings, 0 of them graded serious. Each row states how far the equivalence can be trusted; open a note to see what actually differs.

Nothing on this page matches. Show all entries

Databases and Analytics

6 mappings, 1 of them graded serious. Each row states how far the equivalence can be trusted; open a note to see what actually differs.

Nothing on this page matches. Show all entries

Resource Hierarchy and Scoping

6 mappings, 5 of them graded serious. Each row states how far the equivalence can be trusted; open a note to see what actually differs.

Nothing on this page matches. Show all entries

Identity and Access

6 mappings, 4 of them graded serious. Each row states how far the equivalence can be trusted; open a note to see what actually differs.

Nothing on this page matches. Show all entries

Networking

8 mappings, 2 of them graded serious. Each row states how far the equivalence can be trusted; open a note to see what actually differs.

Nothing on this page matches. Show all entries

Storage

5 mappings, 2 of them graded serious. Each row states how far the equivalence can be trusted; open a note to see what actually differs.

Nothing on this page matches. Show all entries

Which exam, and what it costs

18 current exams and 3 retired ones, each linked to the vendor's own page. An exam retiring and a product retiring are separate events; only the exam is tracked here.

AWS

Azure

Google Cloud

Retired

Listed rather than deleted, because course material for them is still on sale.

Practice Architectural Decisions

For each scenario, state the constraint, choose an option, and explain what changes when the constraint changes. These are learning exercises, not real exam questions or a score predictor.

An Unreadable Standby

An RDS Multi-AZ DB instance serves a photo application. Reporting queries need to move off the writer. Can they use the existing standby?

Answer: no. That deployment's standby is not a client read endpoint. Evaluate a read replica or a supported DB cluster configuration. Preserve the application's availability requirement. A Multi-AZ DB cluster has readable standbys, so “all Multi-AZ standbys are unreadable” is wrong. Deployment modes and sources.

A Private Address That Does Not Work

An on-premises client resolves an Azure service hostname to its public address, even after a private endpoint was created. Does adding a broader RBAC grant fix the network path?

Answer: no. Inspect DNS resolution and forwarding, routes, endpoint approval and traffic controls. Authorization matters after reachability is established. Creating the endpoint alone does not guarantee public access is disabled. Private access.

A Smaller Role Does Not Remove Access

A principal inherits a broad Azure or Google allow grant. You assign a narrower role on a child resource. Have you reduced the inherited permission?

Answer: no. The child allow grant does not subtract the parent grant. Change the relevant assignment or evaluate applicable deny and condition controls. Check other grants before concluding what the principal can do. Identity.

One Region Is Not a Recovery Plan

A web application has two instances in different zones but one unreplicated database. Is the application now resilient to every zone failure?

Answer: no. The database remains a dependency that can prevent useful service. Define the failure scope, data-loss objective and recovery time, then examine every dependency. Multi-zone resilience also does not establish recovery after a region-wide outage. Architecture assumptions.

One Product Name Can Hide a New Operating Mode

A design review claims that every AWS NAT gateway requires its own public subnet and one customer-managed gateway per Availability Zone. Is the statement current?

Answer: it describes the zonal public NAT pattern, not every mode. Regional NAT gateways support different placement and expansion behavior. Their mode restrictions and expansion delay still matter. NAT modes and sources.

Import the Optional Flashcards

Download the tab-separated deck. In Anki, import it with fields mapped to front, back and tags. Comparison answers include the grade, caveat and sources so a card does not teach a false equivalence. Provider links establish where to investigate; they do not replace reading the applicable conditions.

You can also practise without an account or flashcard application: cover the answer paragraph, write a justification, and check it against the linked chapter and primary sources. Revisit an answer when its source or required service configuration changes.