Lab: choose a hosting model for your learning site

Use a small, real requirement

Your System engineer foundations project is a personal blog, static profile, or small PHP website. Start locally, publish only your own sanitized learning evidence, and retain its source in Git. This lab is a design exercise: no signup, purchase, cloud deployment, or external connectivity change is required.

Use the browser journey and virtualization notes you have already made. Separate the traffic path from the hosting decision; DNS and HTTPS are relevant whether the serving application runs locally, in a VM, or behind a managed endpoint.

Compare two viable choices

Choose a static or PHP site. Compare the current local Linux machine with one possible future cloud hosting model. If you choose PHP, the future option must support its runtime; uploading PHP source to a static host is not a valid execution design.

Write this table in your own notes:

Name the deployment and service model of the future proposal. Do not label the local machine “private cloud” just to fill a table. If a responsibility depends on a vendor feature, mark it unverified until you read that service's official documentation.

Draw the relevant request path

Draw your proposed client → name resolution → HTTPS endpoint → content/runtime path. Include a proxy or origin only if the design calls for one. Mark who configures each boundary. This is your proposal, not a diagram of LearnWithSK's production hosting.

Explain whether hybrid/cloud-to-cloud connectivity solves a real requirement. For this small learning site, it is acceptable to conclude that no such requirement exists.

Test the proposal against a requirement change

Work this example before judging your own table. For a static profile, a local BusyBox server is enough to practice file serving. A future managed static host is a plausible alternative, with account controls, domain/TLS setup, publication, usage, and removal still to verify. Neither choice requires a database just to show the profile.

Now suppose a form must run PHP when submitted. The static-only alternative no longer meets the execution requirement. Revise the hosting proposal to a documented compatible runtime or keep the project static and change the feature requirement. Do not claim that uploading source makes a service execute it.

Self-check: if your proposal says “the provider handles everything,” name who can publish a private note by mistake. If it says “local equals private cloud,” revisit the operating characteristics. If it says “free forever,” replace that assertion with the current terms and usage facts that would need verification. The completed lab is a reasoned decision with explicit unknowns.

Acceptance and handoff

Finish with one selected local implementation, one future alternative, a responsibility table, and a short list of facts needing verification. This is an architecture note, not deployment evidence.

Continue to Linux filesystem and permissions. You will now work with the files and identities that the site process needs, then build toward the personal-site project.

No cleanup is required because this exercise creates only your local notes. Keep them for the later AWS foundations module; cloud implementation and MicroBank begin in that path.

Sources

NIST deployment models↗, service-model comparison↗, and shared-responsibility example↗. The checklist above describes what to collect; it does not report a deployed or verified hosting service.