Express resources, variables, outputs and dependencies in reviewable modules.
Project-based Internship Programme
Provision a Three-Tier Cloud Architecture with Terraform
This cloud computing online internship with certificate is a fee-based, project-based internship programme that uses Terraform to document and provision the catalogue’s three-tier AWS architecture in a sandbox account. You reason about network isolation, dependencies, identity, secret references, health, logs, cost awareness and teardown. The operational principles are explained in vendor-neutral terms, and HireeBridge does not imply affiliation with AWS or any cloud provider.
Decision note 01
Does infrastructure and operations work suit this project choice?
A useful fit if…
- You want to model networking, identity, compute, data and monitoring as reviewable configuration.
- You will use a sandbox account, inspect planned exposure and remove resources after testing.
- You can explain availability and security choices without implying endorsement or certification by a provider.
Choose another route if…
- You want application feature development to be the main deliverable.
- You cannot use an approved sandbox or cannot review potential costs before provisioning.
- You seek a provider certification, employment or guaranteed college acceptance; this programme offers none of those.
Official assigned project
Production 3
The catalogue names a Production 3-Tier AWS Architecture, so the submitted Terraform must target that assigned environment. The engineering ideas remain portable: isolate public entry points from private application and data tiers, grant only required access, reference secrets safely, make dependencies explicit, observe health and logs, and remove resources deliberately. Provider names describe the target, not a partnership or endorsement.
Production 3-Tier AWS Architecture — Provision a documented AWS 3-tier architecture with Terraform and safe operational defaults.
Catalogue deliverables
- Terraform modules
- architecture diagram
- deployment guide
- monitoring notes
- and teardown steps
Your build path
Turn the architecture diagram into inspectable infrastructure
Translate the assigned three-tier architecture into network, application, data and operational boundaries. Identify public entry, private application and protected data paths, including administrative access and outbound dependencies.
Define Terraform modules for network segmentation, routing, security groups and tier dependencies. Separate reusable network, application and data concerns while documenting provider, backend and state assumptions.
Use roles and managed secret references rather than committed credentials. Use narrow security-group paths, roles and managed secret references instead of broad access or committed credentials.
Add health checks, logs, monitoring notes and scaling or availability choices where appropriate. Add health checks, logs and monitoring notes; explain availability, scaling and failure assumptions without claiming production guarantees.
Validate plans, inspect exposure, document cost assumptions and provide a safe teardown procedure. Run formatting and validation, inspect the plan for exposure and dependencies, estimate likely cost categories, then document teardown and residual resources.
Private self-check
Check your infrastructure safety preparation
Your answers remain in this browser tab and are not stored or sent.
Use these prompts for reflection; they are not an eligibility test.
Skills notebook
Develop provisioning and operational reasoning
These are general domain-learning suggestions, not confirmed HireeBridge tool requirements.
Infrastructure modelling
Separate entry, application and data tiers with explicit routing and traffic rules.
Document where infrastructure state lives and how sensitive values are protected.
Security and identity
Permit only the traffic and actions each component requires.
Use workload roles rather than long-lived credentials in source code.
Point to managed secret storage without printing values into examples or logs.
Operations
Describe how failed instances, requests and dependencies become visible.
Identify chargeable resource categories and test in a controlled sandbox.
Destroy resources in a checked order and verify that billable remnants are understood.
Authoritative references
Terraform language documentationAWS Well-Architected FrameworkAICTE internship portalReview before submitting
Infrastructure risks to remove before submission
- 01
Putting every tier in public subnets
Only the required entry point should be internet-facing. Document routes and permitted tier-to-tier traffic.
- 02
Opening security groups broadly for convenience
Temporary wide access often survives. Encode narrow sources, ports and purposes in configuration.
- 03
Committing credentials or secret values
Use roles and managed references. Keep local variables, state and provider credentials outside version control.
- 04
Treating a successful plan as operational proof
Formatting and planning help, but health, dependency, exposure and teardown reasoning still require evidence.
- 05
Forgetting cost-bearing remnants
Load balancers, addresses, storage, logs and backups may persist. Document the teardown scope and verify the sandbox afterward.
What reviewers check
Completeness against the assigned brief and deliverables; functional correctness; domain-relevant logic, data, metrics or implementation; required edge cases and failure handling; reproducible setup and submission evidence; and clear documentation of the completed work.
Reviewer
GreyRocks team
Run formatting/validation and inspect planned network exposure and resource dependencies.
Evidence language
Describe provisioned evidence without provider claims
Keep placeholders until you can replace them with evidence from your own project.
- Modelled a three-tier architecture in Terraform with separate network, application and data modules.
- Restricted traffic through [number] documented security-group paths and role-based service access.
- Added health, logging and monitoring configuration for [component] with stated operational limits.
- Reviewed the Terraform plan for public exposure, dependencies and [cost category] before sandbox provisioning.
- Documented deployment prerequisites, managed secret references and teardown verification without committing credentials.
Project readiness
Prepare a strong project submission
Certificate and verification
Validate and document before credential review
Submit the Terraform, diagram, validation evidence and operational documentation for review. Explicit approval enables the GreyRocks certificate record with a unique credential ID and QR verification destination. The credential is a HireeBridge educational completion record, not an AWS certification or evidence of provider affiliation.
- Complete
- Submit
- Review
- Approval
- Credential ID and QR
Read the certificate process · Verify a credential on GreyRocks
Duration: 1 Month / 4 Weeks.
Plan inclusions: Each domain maps to an assigned project and task specification. Reference repositories and comprehensive materials depend on the selected plan; certificates follow task submission and explicit reviewer approval.
Questions from students
Cloud Computing internship FAQ
What is the assigned Cloud Computing project?
The catalogue assigns a production three-tier AWS architecture provisioned with Terraform and documented operational defaults.
Is HireeBridge affiliated with AWS?
No affiliation is claimed. AWS is the target named by the assigned project; the networking and operational reasoning is explained generally.
Must I use a sandbox account?
Use an approved sandbox, review costs and permissions first, and never experiment in an unapproved production account.
What should remain private?
Application and data tiers should use private network placement unless a documented requirement proves otherwise.
Can credentials appear in Terraform files?
No. Use supported credential mechanisms, roles and managed secret references, and keep sensitive state protected.
What must teardown cover?
Document destruction and check for billable remnants such as addresses, storage, logs or backups.
When is the certificate issued?
Only after submission and explicit approval.
Does this replace a provider certification?
No. It documents completion of the reviewed educational project only.
Next step
Choose your plan and start building.
Review plan details, included resources and the assigned project scope before you begin.