# AWS SysOps Administrator — Instructor Guide ## 200-SYSOPS 5.6 · Instructor Deck Overview This document is a delivery companion for the full course. It maps the narrative arc across all 15 modules, summarizes what each module covers, and offers practical tips for introducing content, managing pacing, and facilitating discussion. --- ## The Course Story: Example Corp. The entire course is framed around a single running scenario: **you are a systems administrator at Example Corp.**, a company transitioning from on-premises infrastructure to AWS. Leadership has tasked you with standardizing operations, and every module adds a new chapter to that story. The arc progresses naturally from **identity and visibility → deployment → operations → resilience → security → networking → storage → cost**. This is deliberate — each phase builds on the previous one. Students who miss the narrative thread tend to see the modules as isolated topic lists; students who follow it experience the course as a coherent operational journey. **Carry the scenario forward at every transition.** Open each module by briefly recapping where Example Corp. stands and what problem the CIO or manager has just surfaced. A one-sentence bridge ("Last module we got deployments consistent; today leadership found out they're scaling but hitting capacity limits") keeps engagement high and reduces cognitive load. --- ## Course Structure at a Glance | # | Module | Core Problem for Example Corp. | Primary Services | |---|--------|-------------------------------|-----------------| | 00 | Course Overview | Setup: lab access, guides, platform | AWS Builder Labs, eVantage Bookshelf | | 01 | Intro to Cloud Operations | What does running a cloud environment actually require? | Well-Architected Framework | | 02 | Access Management | Standardize who can do what across growing accounts | IAM, AWS Organizations, IAM Identity Center | | 03 | System Discovery | Inventory everything — we don't know what we have | AWS CLI, Systems Manager, AWS Config | | 04 | Deploy and Update Resources | New app rollout is inconsistent across divisions | Tags, Resource Groups, AMIs, CloudFormation | | 05 | Automate Resource Deployment | Manual deployments don't scale and can't be audited | CloudFormation, AWS CDK, Infrastructure Composer | | 06 | Manage Resources | Application is live; now we need to run it day-to-day | Systems Manager, Patch Manager, Parameter Store | | 07 | Configure Highly Available Systems | Traffic is growing and we can't afford downtime | Route 53, ELB (ALB / NLB / GLB) | | 08 | Automate Scaling | Traffic spikes are unpredictable and licenses are at risk | EC2 Auto Scaling, launch templates, scaling policies | | 09 | Monitor and Maintain System Health | Leadership wants data-driven visibility and automated alerts | CloudWatch, EventBridge, X-Ray, Health Dashboard | | 10 | Data Security and System Auditing | A department had a security incident; we need stronger controls | IAM Access Analyzer, permissions boundaries, GuardDuty, Security Hub | | 11 | Operating Secure Resilient Networks | Global users complain about latency; attacks are increasing | VPC security layers, CloudFront, WAF, ACM | | 12 | Mountable Storage | Storage costs are climbing; we need lifecycle discipline | Instance store, EBS, snapshots, AWS Backup | | 13 | Object Storage | Long-term and static data needs a cost-optimized home | S3, storage classes, lifecycle policies, S3 Glacier | | 14 | Cost Reporting, Alerts and Optimization | Executive team wants visibility and control over cloud spend | Billing & Cost Management, Cost Explorer, AWS Budgets | | 15 | Course Summary | What's next: certifications and continued learning | AWS Certified SysOps Administrator – Associate | --- ## Module-by-Module Delivery Notes ### Module 00 — Course Overview **Purpose:** Get students into the platform before content begins. - Walk through the two access paths (registration URL vs. direct eVantage Bookshelf login) side by side. Most support issues arise from students taking the wrong path and ending up without a license auto-applied. - Demo the Student View of the AWS Builder Labs dashboard yourself so students know where to click before they try it. - If any students are in a class without labs, have the Gilmore license codes ready before class starts — this process requires manual purchase and distribution. - Keep this module short. Students are in setup mode, not learning mode. Resolve access issues before advancing. --- ### Module 01 — Introduction to Cloud Operations **Purpose:** Establish the mental model for the entire course. This module introduces the six responsibilities of cloud operations — **deploy, monitor, fortify, sustain, secure, and optimize** — and maps them to the AWS Well-Architected Framework's six pillars. These two frameworks recur throughout the course; investing time here pays dividends in every subsequent module. **Opening framing:** Ask students what they currently do when a server needs to be patched at 2am, or how they know a deployment succeeded. This grounds the abstract framework in their lived experience before you introduce the AWS-specific vocabulary. **Critical thinking angles to raise:** - The six design principles (stop guessing capacity, test at production scale, automate, etc.) are not universally applicable. Ask: when would testing at production scale be too expensive or too risky? - The six pillars often create genuine trade-offs — performance efficiency and cost optimization frequently conflict. Frame early: there are no universally correct architectures, only appropriate trade-offs given context. - Game days simulate failures, but simulations don't capture the organizational chaos of a real incident. What do game days tell you that a real incident doesn't, and vice versa? **Tip:** The AWS Well-Architected Tool is a free resource students can use post-class to evaluate their own environments. Mentioning it here, and again in Module 14, reinforces its ongoing value. --- ### Module 02 — Access Management **Purpose:** Build a rigorous mental model of identity and authorization before students touch any resources. The module is structured around three concerns: **authentication** (who is this?), **authorization** (what can they do?), and **best practices** (how do you keep this secure over time?). Keep this structure visible — students often conflate authentication and authorization. **Opening framing:** Example Corp.'s CIO wants standardized access management. Before covering tools, ask: "What does 'standardized' mean in this context? Different teams have different needs — how do you achieve consistency without imposing a policy that breaks workflows?" **Key concepts to anchor:** - The **default-deny** model: every permission in IAM must be explicitly granted. Starting minimal and expanding is far more secure than starting broad and trying to restrict later. - **IAM users vs. roles:** Roles provide temporary credentials that expire automatically and eliminate the need to rotate access keys. AWS strongly recommends roles over long-lived IAM users for most use cases. Ask: when would you specifically *not* want to use a long-term access key? - **Federation:** The security posture of federated access depends entirely on the security posture of your identity provider. If the corporate directory is compromised, federated AWS access is also at risk. - **Permissions boundaries:** These solve a specific organizational problem — letting developers self-manage IAM roles without enabling privilege escalation. They are not a general security tool; they are a delegation mechanism. **Common misconception to address:** Students often believe that groups are principals in IAM policies. They are not. A group cannot be specified as a principal in a resource-based policy. Clarify early. --- ### Module 03 — System Discovery **Purpose:** Give students the tools to answer "what do we have, and is it configured correctly?" **Opening framing:** Unlike a physical data center, cloud resources can be created and destroyed by many different people at any time. Ask: "How would you inventory resources you didn't create and don't know exist?" **Key concepts to anchor:** - **Console vs. CLI vs. SDK:** All three call the same API. Changes in one are reflected in the others within seconds. Use CLI examples throughout the course to reinforce this — the console is a visual wrapper, not a separate system. - **`--dry-run`:** Validates permissions without making changes. Useful safety check before running operations against production. Not all commands support it — verify before relying on it. - **Session Manager vs. SSH:** Session Manager eliminates open inbound ports and SSH key management. The trade-off is a dependency on SSM Agent health and IAM policy correctness. Ask: what is your fallback if Session Manager is unavailable? - **AWS Config:** Records what exists and how it's configured, but doesn't automatically evaluate whether configurations are correct. Config rules provide that evaluation layer. Without rules, Config is a data store; with rules, it becomes a compliance monitoring system. **Tip:** The `--query` flag in the AWS CLI is worth demonstrating live. API responses are often verbose; filtering at the CLI level is far more efficient than parsing everything in a script. --- ### Module 04 — Deploy and Update Resources **Purpose:** Establish the foundations of repeatable, trackable deployments before introducing automation. **Opening framing:** Example Corp.'s last application rollout produced uneven results across divisions. Ask: "Is this a technical problem, a process problem, or both?" (Answer: usually both — tools help with the technical side, but organizational alignment is required for consistency.) **Key concepts to anchor:** - **Tags are only as good as their enforcement.** A tagging strategy without automated enforcement produces stale, inconsistent tag values that undermine cost reporting, automation, and access control simultaneously. IAM `aws:RequestTag` conditions and Organizations tag policies are the enforcement mechanisms — introduce them here, not as an afterthought. - **Tag naming is case-sensitive.** `Environment` and `environment` are different keys. This is easy to overlook and creates inconsistencies that are expensive to fix retroactively. - **Resource Groups** depend on tagging discipline. A group built on inconsistently applied tags produces an incomplete or misleading view. - **AMIs age.** An AMI created months ago may contain unpatched software. Ask: how do you know the AMI you're launching is current and trusted? **Tip:** The cross-functional tagging workshop framing is valuable to introduce here. Tag requirements that emerge from a single team tend to serve only that team. Pulling in finance, security, and operations stakeholders surfaces requirements that aren't visible from any single perspective. --- ### Module 05 — Automate Resource Deployment **Purpose:** Move from consistent deployments to automated, auditable deployments using infrastructure as code. **Opening framing:** Example Corp.'s manager now wants deployments automated. Manual processes don't scale, are error-prone, and leave no clear record of what was deployed and when. Ask: "What does it mean to 'automate a deployment'? What would you need to do to roll back a failed automated deployment in under 10 minutes?" **Key concepts to anchor:** - **CloudFormation as desired-state management:** A template describes what you want; a stack is the realization of that state. The key property is that resources in a stack are managed as a unit — created together, deleted together. This simplifies lifecycle management but creates risk if a stack deletion fails midway. - **Drift:** CloudFormation manages resources, but people can change those resources outside of CloudFormation. Drift detection identifies divergence — but it doesn't fix it. Resolving drift requires a judgment call about which state is correct: the template or the actual resource. - **Rollback behavior:** CloudFormation rolls back by default on failure, but some resources (S3 buckets with content, for example) may not be deletable, leaving a stack in a failed state. `DeletionPolicy: Retain` is the safety valve for these cases. - **Intrinsic functions and `Ref`:** The `Ref` function returns different identifiers for different resource types. It does not always return the ARN — verify what `Ref` returns for each resource type before using it in a context that expects a specific identifier format. **Infrastructure Composer tip:** Useful for template authoring and visualization, but the generated code should always be reviewed before deployment. Visual tools can obscure important configuration details. --- ### Module 06 — Manage Resources **Purpose:** Transition from deployment to ongoing operational management. **Opening framing:** Deployment is a one-time event; management is continuous. Ask: "What does it mean to 'manage' a running application? What tasks would you expect to perform daily, weekly, and monthly?" **Key concepts to anchor:** - **Systems Manager as a unified operational plane:** The breadth of Systems Manager (Patch Manager, Session Manager, Run Command, Parameter Store, Incident Manager, and more) can be overwhelming. The unifying model is: SSM Agent on each managed instance communicates with the Systems Manager service, enabling centralized management without requiring direct network access. - **Prerequisites matter:** Missing IAM instance profile, SSM Agent not running, or missing HTTPS egress to SSM endpoints are all silent failures — the instance simply doesn't appear as managed. Walk through the prerequisite checklist carefully. - **Default Host Management Configuration (DHMC):** Enables Systems Manager for all EC2 instances in an account with a single action. Ideal for environments with many instances, but note that it applies uniform settings — verify whether uniform management is appropriate for accounts with mixed workloads. **Tip:** Ask students which operational question they'd most want Systems Manager to answer for them. This surfaces what they actually care about and lets you prioritize which capability to demonstrate in depth. --- ### Module 07 — Configure Highly Available Systems **Purpose:** Design for resilience through load distribution and DNS-level traffic management. **Opening framing:** Example Corp.'s application is experiencing traffic growth. Ask: "What's the difference between scaling and high availability? Can you have one without the other?" **Key concepts to anchor:** - **Route 53 vs. ELB operate at different layers.** Route 53 routes traffic across Regions by directing DNS queries to different endpoints; ELB distributes traffic within a Region across multiple targets. Together they provide global traffic management and local fault tolerance — neither alone is sufficient. - **Health checks are not optional.** A load balancer without correctly configured health checks will route traffic to unhealthy targets. Ask: how do you distinguish between a slow target and an unavailable one in your health check configuration? - **Load balancer type selection:** ALB for HTTP/HTTPS and content-based routing; NLB for high-throughput TCP/UDP with static IP; GLB for integrating third-party appliances. Choosing the wrong type requires redeployment — make this decision based on both current needs and expected architectural evolution. - **NLB preserves source IP.** This matters for applications that need to know who is connecting. ALB does not — it inserts the original IP into `X-Forwarded-For` headers instead. --- ### Module 08 — Automate Scaling **Purpose:** Design systems that respond to load automatically, within operational and license constraints. **Opening framing:** The tax preparation analogy is worth using verbatim: provision for peak, pay for peak all year. Ask: "What does over-provisioning cost you in the cloud versus the operational complexity of automating scaling? When is fixed capacity the right choice?" **Key concepts to anchor:** - **Auto Scaling has two distinct capabilities:** fleet management (replacing unhealthy instances at a fixed desired count) and demand scaling (adjusting capacity based on load). Fleet management is always active, even at a fixed capacity setting. Students often conflate these two. - **Scaling components are independent:** launch template, Auto Scaling group, and scaling policies can each be updated separately. This separation of concerns allows AMI updates to be rolled out without changing scaling behavior. - **Metric selection matters.** CPU utilization is the most common scaling metric but not always the right one. A batch processing workload might scale on SQS queue depth; a web application might scale on request count or latency. Ask: what metric would you monitor for a workload that is CPU-bound versus one that is I/O-bound? - **License management during scale-out:** The module explicitly surfaces this constraint — automatic scaling can inadvertently exceed third-party license counts. This is a real operational consideration that students often overlook when designing auto-scaling policies. --- ### Module 09 — Monitor and Maintain System Health **Purpose:** Establish observability as a continuous operational practice, not a post-incident activity. **Opening framing:** Example Corp. wants data-driven visibility and automated alerting. Ask: "What alert would you want to receive *before* users reported a problem? What metric would trigger it?" **Key concepts to anchor:** - **CloudWatch's default coverage stops at the hypervisor.** Metrics like memory utilization and disk usage are not visible from the hypervisor — they require the CloudWatch agent or custom metric publishing. This gap surprises many operators who assume CloudWatch covers everything. - **Metrics, logs, alarms, dashboards, and events serve different purposes.** Metrics answer "how is it performing?"; logs answer "what happened?"; events answer "what changed?"; dashboards answer "what does it look like right now?"; alarms answer "when should I act?". Using all five components together creates a complete observability picture. - **Alert fatigue is a real risk.** Too many alarms that trigger too frequently train operators to ignore them. Alarm design should optimize for actionability — every alarm should require a response, and every response should have a defined procedure. - **X-Ray for distributed systems:** CloudWatch monitors infrastructure; X-Ray traces requests across distributed services. For microservices architectures, X-Ray answers questions that CloudWatch metrics alone cannot — specifically "which service in the call chain is causing this latency?" --- ### Module 10 — Data Security and System Auditing **Purpose:** Build detection, audit, and automated remediation capabilities in response to a realistic security incident scenario. **Opening framing:** A department at Example Corp. had a security incident. Ask: "What detection gap likely existed before the incident? Was the environment unmonitored, or was monitoring in place but not acted on? What's the difference — and what does it mean for the fix?" **Key concepts to anchor:** - **IAM Access Analyzer:** Answers "which of my resources is accessible from outside my account or organization?" using automated policy reasoning — analysis that would require significant manual effort to replicate. The 24-hour re-analysis cycle means it won't catch a configuration change made moments ago. - **Zone of trust:** The boundary that Access Analyzer uses to classify access as trusted or untrusted. Using an Organization as the zone of trust is usually more appropriate than a single account for multi-account environments — it reduces cross-account findings from intentional inter-account access. - **Access Analyzer findings require human triage.** If access is intentional, archive the finding. If not, modify the policy. The tool generates findings; it doesn't automatically determine whether access is legitimate. Regular review is required — findings should not accumulate unexamined. - **Permissions boundaries for safe delegation:** Allow developers to self-manage IAM roles without enabling privilege escalation. Without them, allowing developers to create roles is functionally the same as giving them administrator access. **Tip:** The scenario — "incident already happened, now we're hardening" — is realistic and resonates with experienced students. Use it to discuss what would have changed had these controls been in place before the incident. --- ### Module 11 — Operating Secure Resilient Networks **Purpose:** Apply defense-in-depth principles to VPC networking and extend the security perimeter to the edge. **Opening framing:** Users worldwide are experiencing latency, and attacks are increasing. These are not the same problem — but the solutions overlap. Ask: "Which AWS service addresses both simultaneously? How?" **Key concepts to anchor:** - **Four VPC security layers and their scope:** Route tables (subnet-level routing), network ACLs (subnet-level allow/deny), security groups (instance-level stateful filtering), host-based firewalls (OS-level last line of defense). Each has gaps that the others fill — defense in depth requires all layers to be active and correctly configured. - **Network ACLs are stateless; security groups are stateful.** This is a common source of subtle connectivity bugs. With security groups, allowing inbound traffic automatically allows the corresponding outbound response. With NACLs, you must explicitly allow both directions. - **CloudFront at the edge:** Reduces latency via caching at edge locations and integrates with WAF for attack filtering before traffic reaches the origin. Moving security controls to the edge reduces both attack surface and origin load. - **ACM certificate automation:** Eliminates the manual renewal process that causes outage-inducing certificate expiry. Managed renewal applies to ACM-issued certificates used with supported AWS services — self-managed certificates imported into ACM do not get auto-renewed. --- ### Module 12 — Mountable Storage **Purpose:** Match workload I/O requirements to the right block storage option and establish lifecycle discipline for cost management. **Opening framing:** Cloud storage costs are rising and leadership wants a plan. Ask: "What data does Example Corp. actually need instant access to? What could be archived? What would be unrecoverable if lost? These three questions determine your storage strategy." **Key concepts to anchor:** - **Instance store is ephemeral.** Data is lost when the instance stops, terminates, or fails. It is not appropriate for persistent data, but is ideal for distributed systems that replicate across instances, caching layers, or scratch space. - **NVMe vs. SATA interface:** Storage-optimized instance types with NVMe provide significantly higher IOPS and lower latency by connecting storage directly to the PCIe bus. For I/O-bound workloads, instance type selection has as much impact as storage volume type selection. - **Lifecycle management for EBS snapshots:** Snapshots without lifecycle policies accumulate indefinitely and become a cost problem over time. Amazon Data Lifecycle Manager automates snapshot creation and deletion — address this at design time, not when the bill arrives. --- ### Module 13 — Object Storage **Purpose:** Use Amazon S3 as the foundation for durable, cost-optimized long-term and shared data storage. **Opening framing:** This module shares its scenario with Module 12 but addresses a different data model. Ask: "What's the difference between data that changes frequently and data that is primarily read and shared? That distinction determines whether you want block storage or object storage." **Key concepts to anchor:** - **EBS vs. S3 is a data model choice, not just a performance choice.** EBS is for data undergoing frequent changes accessed by a running compute process. S3 is for data that is primarily read, downloaded, or shared — backups, logs, static content, and data lake assets. - **S3 durability is automatic.** S3 replicates data across multiple AZs within a Region without any action required. EBS does not — snapshots are required for cross-AZ durability. - **Block Public Access should be enabled by default.** Inadvertent public exposure of S3 data is one of the most common causes of cloud data breaches. Enabling Block Public Access at the account level provides a guardrail that is easier to selectively relax than to add after a breach has occurred. - **Storage class selection is the primary cost optimization lever for S3.** Intelligent-Tiering automates class transitions based on access patterns — useful when access frequency is unpredictable. For predictable patterns, manual lifecycle policies transitioning to Glacier classes can yield significant savings. --- ### Module 14 — Cost Reporting, Alerts and Optimization **Purpose:** Build the operational discipline to understand, control, and optimize cloud spend. **Opening framing:** Example Corp.'s executive team wants visibility and control over cloud costs. Ask: "Which of these three things does your organization do best: awareness of what you're spending, controls to prevent overspending, or optimization of what you're spending money on? Where are the biggest gaps?" **Key concepts to anchor:** - **Awareness → Control → Optimize is a maturity sequence.** Establishing awareness without controls gives visibility without action. Controls without optimization leads to spending within budget but at higher cost than necessary. Each phase builds on the previous — skipping phases produces incomplete outcomes. - **Billing access must be explicitly delegated.** By default, only the root user can view billing data. IAM users cannot access billing until the account owner activates IAM billing access and attaches appropriate policies. This is a common gap in multi-user accounts. - **Billing Dashboard vs. Cost Explorer vs. CUR:** These answer different questions at different granularity. Billing Dashboard and Invoice: "How much did we spend?" Cost Explorer: "Why did we spend that?" CUR: "What was charged, to which resource, when, and at which rate?" Use the right tool for the question. - **Reserved Instances and Savings Plans:** Commitment-based pricing models that can significantly reduce compute costs for predictable workloads. The risk is committing to capacity you won't fully use. The decision requires accurate usage forecasting — emphasize the importance of analyzing actual usage patterns before purchasing. **Tip:** The Well-Architected Tool (introduced in Module 01) includes a Cost Optimization pillar review. Bringing it back here closes the loop and reinforces the framework as a continuous operational tool, not just an introductory concept. --- ### Module 15 — Course Summary **Purpose:** Consolidate learning, map to the AWS certification pathway, and provide post-course resources. This is a short module. Its primary value is in the certification framing and the four-step exam preparation sequence: 1. Understand the exam format and question style 2. Fill knowledge gaps using targeted self-paced content on AWS Skill Builder 3. Get hands-on practice through AWS Builder Labs 4. Validate readiness through official practice exam questions **Key points to reinforce:** - AWS exams test **scenario-based judgment** — selecting the best option from several plausible choices — not factual recall of API names. Students who study only facts and not scenarios typically underperform. - The Official Practice Question Sets use the same authoring process as real exam questions. They are the closest proxy for assessing actual readiness. - Recertification is required every 3 years. AWS services evolve rapidly; a credential earned today reflects knowledge of the current AWS landscape, which will shift significantly over the next three years. **Further learning resources to share:** - [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html) - [How AWS Pricing Works](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/welcome.html) - [AWS What's New](https://aws.amazon.com/new/) - [AWS Security, Identity & Compliance Best Practices](https://aws.amazon.com/architecture/security-identity-compliance/) - [AWS VPC Connectivity Options](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) --- ## Cross-Cutting Themes These themes appear across multiple modules. Naming them explicitly at the start of the course, and calling them out when they recur, helps students build a coherent model rather than a collection of isolated facts. ### 1. The Default-Deny Mindset Starting in Module 02 (IAM) and running through Module 10 (auditing) and Module 11 (networking), the default-deny principle shapes every access control decision: everything is denied unless explicitly allowed. S3 Block Public Access, security group rules, IAM policies, and NACLs all instantiate this principle. Reinforce it whenever a new access control mechanism appears. ### 2. Automation Requires Discipline Automation reduces human error but introduces new failure modes: CloudFormation drift (Module 05), auto-scaling that exceeds license limits (Module 08), alarm fatigue from over-triggered alerts (Module 09), and tags that drift from their intended values (Module 04). The recurring question is: what could go wrong if this automated system behaves unexpectedly? Automation makes the right path easier and the wrong path faster. ### 3. Tagging as Operational Infrastructure Tags introduced in Module 04 for cost allocation reappear in Module 06 (operations support), Module 09 (monitoring), and Module 14 (cost management). Tagging discipline is not a nice-to-have — it is the foundation for cost attribution, operational automation, and access control. A consistent, enforced tagging strategy pays dividends in every module that follows Module 04. ### 4. Trade-offs, Not Best Practices The Well-Architected Framework offers principles, not prescriptions. Every module presents genuine tensions: performance vs. cost (Modules 07–08), flexibility vs. security (Modules 02–03), automation benefits vs. automation risks (Modules 05–08). Encourage students to identify these tensions explicitly rather than accepting AWS recommendations at face value. The most operationally mature teams understand *why* a practice is recommended and when it doesn't apply. ### 5. Detection Before Response Modules 09 and 10 address monitoring and security auditing from different angles. The common thread: you cannot respond to what you cannot detect. CloudWatch, AWS Config, CloudTrail, IAM Access Analyzer, GuardDuty, and Security Hub all expand the detection surface. Emphasize that detection tools require regular review to be effective — dashboards no one watches and findings no one triages are worse than no monitoring at all because they create false confidence. --- ## Lab Pacing Notes The course includes hands-on labs that reinforce specific module concepts. Labs should be positioned *after* the conceptual content and before the next module, not left for end-of-day. Students who fall behind on labs tend to disengage from the next module's content. If a lab is running long, let students continue on break rather than rushing them to completion. Partial completion of a lab with understanding is more valuable than full completion without it. --- ## Common Student Questions **"When should I use IAM users vs. roles?"** Use roles for applications, services, and cross-account access. Use IAM users only for human identities that don't have a corporate SSO that can federate, and prefer short-term credentials wherever possible. The general direction is toward fewer IAM users over time, not more. **"What's the difference between a security group and a network ACL?"** Security groups are stateful (response traffic is automatically allowed), operate at the instance level, and support only allow rules. Network ACLs are stateless (you must explicitly allow both directions), operate at the subnet level, and support both allow and deny rules. Use both — they address different threat vectors. **"Do I need CloudTrail enabled for CloudWatch to work?"** No. CloudWatch collects metrics from AWS services independently of CloudTrail. CloudTrail records API calls and management events. They are complementary, not dependent on each other. **"If I have Auto Scaling, do I still need a load balancer?"** Yes, in most architectures. Auto Scaling adds or removes instances; a load balancer distributes traffic across the instances that are running. Without a load balancer, new instances added by Auto Scaling receive no traffic until DNS records are updated or clients reconnect. **"What's the cheapest S3 storage class?"** S3 Glacier Deep Archive has the lowest storage cost per GB, but it has multi-hour retrieval times and minimum storage durations. The cheapest class for a given use case depends on how frequently the data is accessed and how quickly it needs to be retrieved. Cost Optimization requires matching the class to the actual access pattern.