Cloud Foundations & Identity

Why This Phase Exists

Every failed AWS project I have reviewed as a Solutions Architect traces back to the same root causes: the team did not understand the infrastructure model they were building on, or they got identity wrong from the start. Not "a little wrong." Fundamentally wrong. Overprivileged root credentials stored in application code. Resources deployed into default VPCs with no isolation strategy. Accounts structured as an afterthought rather than a security boundary.

This phase exists because the decisions you make here are permanent in their consequences. You can refactor application code in a sprint. You cannot easily undo an identity architecture that 47 microservices now depend on. You cannot retroactively fix a billing structure that mixes production and development workloads in the same account. The cost of getting foundations wrong is not measured in hours of rework. It is measured in security incidents, compliance failures, and architectural debt that compounds with every service you add.

Cloud foundations and identity are not introductory topics you leave behind. They are the substrate every other phase builds on. Treat them accordingly.

What You Will Master

By the end of Phase 1, you will be able to:

• Articulate the NIST cloud computing definition and map its five characteristics to specific AWS service behaviors
• Evaluate AWS Regions against four selection criteria (compliance, latency, service availability, cost) and defend your choice to a customer
• Structure an AWS account with billing alerts, root user lockdown, and appropriate support plan selection
• Write IAM policy documents from scratch using the Principal-Action-Resource-Condition model
• Design a role-based access strategy using STS, federation, and cross-account trust relationships
• Explain the shared responsibility model with precision, including where the boundary shifts between IaaS, PaaS, and SaaS

These are not theoretical competencies. Each maps directly to decisions you will make in production environments.

Modules in This Phase

The Progressive Path

These five modules are not sequential chapters in a textbook. They are architectural layers, and each one exists because the previous layer created a requirement.

Module 01 establishes the mental model: cloud computing is a set of contractual properties (on-demand, broad network access, resource pooling, rapid elasticity, measured service). Once you internalize these properties, Module 02 becomes inevitable. If resources are pooled and elastic, they must live somewhere physical. That "somewhere" is the Global Infrastructure, and your choice of Region determines your latency, compliance posture, and available services.

Module 03 answers the next question: now that you know where AWS lives, how do you get your own space within it? The account is your billing boundary, your security perimeter, and your blast radius. The root user is the most powerful credential in existence for that account. Locking it down is your first real security decision.

Modules 04 and 05 build the identity layer on top of that account. Module 04 gives you the building blocks: users, groups, and policies. Module 05 shows you why those building blocks are often insufficient for production architectures and introduces roles, temporary credentials, and federation as the mechanisms that actually scale. By the end, you understand that long-lived credentials are a liability, and roles with STS are how professionals operate.

Services You Will Command

AWS Cloud Computing Models

Cloud computing is not "someone else's computer." That reductive framing misses the point entirely. Cloud computing is a consumption model defined by five measurable characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. The NIST definition matters because it gives you a framework to evaluate whether a service is truly "cloud" or just hosted infrastructure with a web portal.

As a Solutions Architect, you care about the service models (IaaS, PaaS, SaaS) because they define your operational boundary. When you choose EC2, you own the OS patches. When you choose Lambda, you do not. When you choose RDS, you own the schema but not the engine upgrades. These boundaries shift your team's responsibilities and directly impact your staffing, compliance obligations, and operational costs.

You will learn to evaluate deployment models (public, private, hybrid, community) against customer requirements. A federal customer with FedRAMP obligations has different deployment constraints than a startup optimizing for speed. The shared responsibility model is the contractual expression of these boundaries, and you will learn to draw that line precisely for every service category.

AWS Global Infrastructure

The Global Infrastructure is not a data center list. It is a topology that dictates your architecture's performance, resilience, and legal compliance. A Region is a cluster of isolated data centers (Availability Zones). An AZ is one or more discrete data centers with redundant power, networking, and cooling. Edge Locations are CDN nodes. Local Zones and Wavelength Zones extend compute closer to end users and 5G networks, respectively.

Why does a Solutions Architect obsess over this? Because Region selection is a constraint that propagates through every decision afterward. Choose a Region without a required service, and you are building workarounds on day one. Choose a Region far from your users, and no amount of application optimization fixes the latency. Choose a Region that does not meet your data residency requirements, and you have a compliance finding before you deploy a single resource.

You will learn to evaluate Regions against the four selection criteria, understand how inter-AZ networking works (synchronous replication, low-latency links), and recognize when Edge Locations, Local Zones, or Wavelength Zones solve problems that Regions alone cannot.

AWS Account Structure

Your AWS account is simultaneously a billing container, an IAM namespace, a resource boundary, and a security perimeter. The root user has unrestricted access to everything in that account: every service, every resource, every configuration. There is no IAM policy that can restrict it. This makes root user security your single most important operational concern on day one.

As a Solutions Architect, you care about account structure because it determines your blast radius. A compromised credential in a single-account architecture can reach production databases, development environments, billing configuration, and IAM itself. Multi-account strategies (which you will study in depth during Phase 8 with AWS Organizations) start with understanding what a single account contains and why its boundaries matter.

You will learn to configure billing alerts, understand Free Tier mechanics, evaluate support plan tiers against organizational needs, and implement root user lockdown (MFA, no access keys, minimal usage). These are not administrative tasks. They are architectural decisions with security and financial consequences.

AWS IAM: Users, Groups & Policies

IAM is the authorization layer for every API call in AWS. Every request, whether from the console, CLI, SDK, or another AWS service, is evaluated against IAM policies. A policy document is a JSON structure that specifies who (Principal) can do what (Action) to which resources (Resource) under what conditions (Condition). Understanding this four-part model is fundamental to operating in AWS.

The distinction between managed policies and inline policies is not cosmetic. Managed policies are reusable, versionable, and auditable. Inline policies are tightly coupled to a single identity and cannot be shared. Your choice between them affects your ability to audit permissions at scale, respond to security incidents quickly, and maintain consistent access patterns across teams.

Least privilege is the principle that every identity should have exactly the permissions required to perform its function and nothing more. In practice, achieving least privilege requires iterative refinement: start restrictive, observe access denied errors, expand permissions surgically. You will learn to write policies that express this intent precisely, using resource-level permissions and conditions rather than broad wildcards.

AWS IAM: Roles, STS & Federation

IAM Roles solve the fundamental problem with long-lived credentials: they exist permanently, can be leaked, and are difficult to rotate without downtime. A role has no password and no access keys. Instead, it provides temporary credentials through the Security Token Service (STS) that expire automatically. When an EC2 instance needs to read from S3, it assumes a role. When a Lambda function needs to write to DynamoDB, it assumes a role. When a human administrator needs cross-account access, they assume a role.

Federation extends this model beyond AWS-native identities. Your organization's existing identity provider (Active Directory, Okta, Azure AD) becomes the source of truth for authentication, and IAM roles provide the authorization. IAM Identity Center (formerly AWS SSO) is the modern implementation of this pattern, providing centralized access management across multiple AWS accounts with your corporate directory as the identity source.

Cross-account access is where roles become architecturally essential. In a multi-account organization, services in Account A need to access resources in Account B. Trust policies on roles define which principals from which accounts can assume them. This trust relationship model is the mechanism that makes multi-account architectures functional rather than isolated silos.

AWS Organizations (Preview)

AWS Organizations appears in full during Phase 8, but its conceptual foundation belongs here. Organizations is the service that manages multiple AWS accounts as a single entity. It provides consolidated billing, hierarchical account grouping through Organizational Units (OUs), and centralized policy application through Service Control Policies (SCPs).

You need this preview because the account and identity concepts you master in Phase 1 operate differently at organizational scale. An SCP can restrict what the root user of a member account can do. A permission boundary set at the OU level overrides anything configured within the account. Understanding that these controls exist shapes how you think about single-account identity design from the beginning.

The mental model to carry forward: a single account's IAM is necessary but insufficient for enterprise governance. Organizations provides the layer above it. Everything you learn in Modules 03 through 05 is the foundation that Organizations builds upon.

Architecture Context

Phase 1 is referenced by every subsequent phase in this program. Here is how the dependency chain works:

Phase 2 (Compute & Networking) requires your understanding of Regions, AZs, and account structure. Every EC2 instance launches into a specific AZ. Every VPC exists within a specific Region. IAM roles from Module 05 attach to every compute resource as instance profiles.

Phase 3 (Storage & Databases) uses IAM policies extensively. S3 bucket policies are IAM policy documents. DynamoDB access control uses the same Principal-Action-Resource-Condition model. Cross-account S3 access uses the role trust relationships from Module 05.

Phase 4 (Application Services) builds on STS and temporary credentials. Lambda execution roles, API Gateway authorizers, and Step Functions all depend on the role-based access patterns you establish here.

Phase 5 (Containers & Serverless) requires task execution roles (ECS), pod identity (EKS), and service-linked roles. Without Module 05, container orchestration permissions are incomprehensible.

Phase 8 (Governance & Multi-Account) takes the single-account identity model from this phase and extends it to organizational scale with SCPs, permission boundaries, and delegated administration.

If you do not command the material in Phase 1, every subsequent phase will feel like fighting the platform rather than building on it.

Phase Exam

The Phase 1 assessment validates your mastery of cloud foundations and identity concepts:

• 30 multiple-choice questions covering all five modules
• 50-minute time limit
• 70% pass threshold (21/30 correct required)
• Questions test architectural reasoning, not rote memorization
• Expect scenario-based questions: "A customer requires data residency in Frankfurt and needs DynamoDB. What is your Region recommendation and why?"
• Policy document interpretation questions will present JSON and ask you to identify what access is granted or denied
• At least 5 questions will require you to identify the correct IAM mechanism (user vs. group vs. role vs. federation) for a given scenario

You must pass this exam before proceeding to Phase 2. The concepts assessed here are prerequisites, not suggestions.