Integrated Cloud Infrastructure Build and Documentation

Integrated Cloud Infrastructure Build and Documentation

This lab is the capstone of the Cloud Basics course. You will independently design, deploy, secure, document, and present a complete multi-service cloud environment that satisfies a realistic business scenario. Every skill covered in this course — compute, storage, networking, identity and access management (IAM), monitoring, and cost controls — comes together in a single build. This is also the format used in real IT support and cloud operations roles, where you are expected to deliver a working solution and explain every decision you made.

Why the Design Phase Comes First

Professional cloud engineers never open a console before they have a written plan. Rushing into deployment without a design produces insecure, hard-to-troubleshoot environments and unpredictable costs. Before you touch any console, you must produce two deliverables:

1. Architecture diagram — a visual map showing every component (compute instances, storage buckets, subnets, security groups, IAM users) and how they connect. Use the template provided. Label each component with its role and mark which resources are public-facing and which are private.

2. Bill of materials (BOM) — a list of every resource you plan to deploy, its configuration (instance type, storage class, region), and its estimated monthly cost. The cost estimate worksheet guides you through this step.

A clear design catches problems early. For example, placing a database server in a public subnet is a security error you can spot on paper before you deploy anything.

Core Components You Will Deploy

The business scenario will include some or all of the following:

• Public web server — a compute instance (virtual machine) in a public subnet, reachable from the internet on port 80 or 443. A security group must allow only HTTP/HTTPS inbound traffic; SSH access should be restricted to a known IP or disabled.
• Private database server — a compute instance in a private subnet with no direct internet route. Its security group should allow inbound database traffic only from the web server's security group, not from the open internet.
• Object storage bucket — used for backups. Encryption must be enabled at rest. Public access must be blocked unless the scenario explicitly requires otherwise. Enable versioning if long-term retention is required.
• IAM users and roles — each user gets only the permissions required for their job (the principle of least privilege). Do not attach overly broad policies such as full administrator access to accounts that only need read access to a bucket.
• Billing alert — a budget threshold that sends an email notification when estimated spending reaches a defined limit. This prevents surprise charges in a sandbox and mirrors what operations teams configure in production accounts.

Security Controls and Why They Matter

Every control you apply must be intentional and documented. Instructors will ask you to explain your choices. Key principles:

• Least privilege applies to both IAM policies and security groups. Open only what is required; close everything else by default.
• Encryption in transit and at rest — use HTTPS endpoints where possible and enable server-side encryption on storage buckets. This protects data if storage media is compromised or traffic is intercepted.
• No hard-coded credentials — never embed access keys or passwords in scripts or documentation. Use IAM roles attached to compute instances instead of placing keys in the operating system.
• Monitoring and logging — enable flow logs or equivalent audit logging so that unusual traffic or unauthorized API calls can be detected. A billing alert is also a form of monitoring.

Electrical and Physical Safety Note

Cloud labs run in software sandboxes, so there is no high-voltage equipment in this lesson. However, if your program includes any hands-on cabling or data-center simulation work alongside cloud labs, follow your facility's lockout/tagout (LOTO) procedures before working inside any powered rack or patch panel, and wear appropriate PPE as directed by your instructor. Never bypass safety procedures because the task seems quick.

Completing the Independent Build

During the lab session, work methodically through your design in this order: network and subnets first, then compute, then storage, then IAM, then monitoring. This order mirrors the dependency chain — you cannot attach a security group to an instance that does not yet exist on a defined subnet. Save your work frequently and note any deviation from your original plan in your documentation; deviations are normal and acceptable as long as you explain them.

Technical Documentation and Defense Walkthrough

Your written document (one to two pages) must cover: the architecture and each component's purpose, each security control applied and the reason for it, the monthly cost estimate with line items, and any changes made during the build and why. Clear, concise technical writing is a job skill. During the five-minute walkthrough defense, the instructor will ask four probing questions. You must answer at least three correctly. Typical questions target your reasoning: why a specific port is open, how a particular IAM policy limits access, or what would happen if a security group rule were changed. Rehearse by explaining your design aloud before the defense.

Connecting to Certification Objectives

This lab maps directly to CompTIA A+ Core 2 objectives around cloud computing concepts and security best practices, CompTIA Network+ objectives around network architecture and cloud connectivity, and Cisco CCST and CCNA objectives around network segmentation and access control. Documenting and defending your technical decisions is a skill tested implicitly across all of these credentials and explicitly in workplace performance reviews.