A trainee asks whether an Amazon S3 bucket can be attached as the EC2 instance's boot volume for a new virtual server. Which guidance is correct?
Select an answer to reveal the explanation.
Short Explanation
S3 is a locker for objects, not a hard drive you boot from. EC2 operating system volumes live on Amazon EBS (or ephemeral instance store in special cases). Pointing an instance at a bucket does not magically turn object storage into a root disk.
Full Explanation
A trainee asking whether an Amazon S3 bucket can be attached as an EC2 instance's boot volume needs a clear correction: no—object storage is not an EC2 boot disk. Operating system volumes for EC2 use Amazon EBS (or instance store where appropriate for ephemeral local disks). S3 stores objects accessed by API using keys; granting s3:GetObject on an instance profile does not transform a bucket into a root block device. Municipal server builds must continue to use AMIs backed by EBS volumes (typical) rather than attempting to "boot from a bucket."
Claims that S3 mounts as root when the instance profile includes s3:GetObject are false. S3 Intelligent-Tiering changes storage cost tiers based on access patterns; it does not convert object storage into block storage. Amazon CloudFront cannot boot EC2 instances from edge caches—CloudFront is a CDN, not a hypervisor boot source. Each distractor invents a boot path that does not exist.
Exam caveat: This is a pure storage-model question. If the stem says boot volume / OS disk → EBS (or instance store). If it says object by key / data lake / static assets → S3. Do not let IAM permissions blur that architectural boundary.
Operational check for new virtual servers: launch from an approved hardened AMI on EBS, encrypt the root volume, keep application payloads that belong in object storage in S3 and pull them with the instance role after boot, document the difference for trainees, and reject architecture proposals that treat buckets as drop-in replacements for root volumes.