ExamFinch.com My Study

Study guide

1.4 Amazon S3

Practice this exam

AWS Certified Developer – Associate DVA-C02

Track your progress as you read

Finished sections get a check mark.

1 Introduction: DVA-C02 Overview & Study Plan

1.1 What the AWS Developer Associate Tests 1.2 Exam Format, Scoring & Logistics 1.3 The Four Domains & A Study Plan

2 Chapter 1: Development with AWS Services

1.1 AWS Lambda 1.2 Amazon API Gateway 1.3 Amazon DynamoDB 1.4 Amazon S3 1.5 Messaging: SQS, SNS, EventBridge 1.6 Containers: ECS, ECR, Fargate 1.7 AWS SDK & API Best Practices

3 Chapter 2: Security

2.1 IAM for Developers 2.2 Encryption & AWS KMS 2.3 Secrets Manager vs Parameter Store 2.4 Amazon Cognito

4 Chapter 3: Deployment

3.1 CloudFormation & SAM 3.2 CI/CD with CodePipeline, CodeBuild, CodeDeploy 3.3 Deployment Strategies 3.4 Elastic Beanstalk & Container Deploys

5 Chapter 4: Troubleshooting, Optimization & Exam Strategy

4.1 Observability: CloudWatch & X-Ray 4.2 Performance & Caching 4.3 Common Traps & Final Review

1.4 Amazon S3

Key Takeaways Explain This Topic AI

S3 storage classes range from Standard (frequent access) through Standard-IA/One Zone-IA to Glacier tiers (archival); Intelligent-Tiering moves objects automatically based on access.

Versioning preserves every object version (delete adds a delete marker); lifecycle rules transition or expire objects and should abort incomplete multipart uploads.

Server-side encryption options are SSE-S3 (S3-managed AES-256, the default), SSE-KMS (KMS keys with key policies and CloudTrail audit), and SSE-C (customer-provided keys).

Presigned URLs grant temporary, time-limited access to a specific object using the signer's permissions, enabling direct browser upload/download with no AWS credentials on the client.

Multipart upload is recommended above 100 MB and required for single-object PUT above 5 GB; S3 provides strong read-after-write consistency for all operations.

Last updated: June 2026

S3 in Developer Scenarios

Amazon Simple Storage Service (S3) stores objects in buckets with 99.999999999% (eleven nines) durability. Each object is identified by a key within a bucket; the max single object size is 5 TB. Developer-domain questions focus on secure access (presigned URLs, encryption), large uploads (multipart), event-driven triggers, and cost optimization through storage classes and lifecycle rules. Bucket access is governed by IAM policies, bucket policies, and (legacy) ACLs, with Block Public Access on by default.

Storage Classes

  • Class Use case Notes
  • S3 Standard Frequently accessed data Multi-AZ, highest availability
  • Standard-IA Infrequent access Lower storage, per-GB retrieval fee, 30-day min
  • One Zone-IA Infrequent, re-creatable Single AZ, ~20% cheaper, lower durability
  • Glacier Instant Retrieval Archive, instant access Millisecond retrieval, 90-day min
  • Glacier Flexible / Deep Archive Long-term archive Minutes-to-hours retrieval, lowest cost, 90/180-day min

Intelligent-Tiering Unknown/changing patterns Auto-moves between tiers, small monitoring fee, no retrieval fees

Versioning and Lifecycle

Versioning keeps every version of an object so you can recover from accidental overwrites and deletes; a DELETE inserts a delete marker rather than removing data. Lifecycle rules transition objects to cheaper classes or expire them (current and noncurrent versions) on a schedule. Always include a rule to abort incomplete multipart uploads after a few days, because abandoned parts keep accruing storage cost invisibly.

Encryption Models

  • Option Who manages the key Audit / control When tested
  • SSE-S3 S3 (AES-256), default None per-request Simple at-rest encryption
  • SSE-KMS AWS KMS key Key policies + CloudTrail logs every use Compliance, audit, fine-grained control

SSE-C Customer supplies key per request You hold the key; S3 never stores it Customer must control keys outside AWS

A compliance requirement for auditable, controlled key usage points to SSE-KMS , because KMS key policies and CloudTrail give you the access trail SSE-S3 cannot. Watch for KMS request-rate throttling on very high-volume buckets; S3 Bucket Keys reduce KMS calls and cost.

Presigned URLs

A presigned URL grants temporary, time-limited access to a single object using the creator's credentials and permissions, so a client can GET or PUT one object directly without its own AWS credentials and without making the bucket public. This is the standard pattern for secure browser uploads and time-boxed downloads. The URL's validity is bounded by the signer's session — short-lived for role credentials, longer for IAM-user keys (up to 7 days).

Multipart Upload

Multipart upload splits a large object into parts (5 MB minimum each, except the last) uploaded in parallel and reassembled server-side, improving throughput, allowing pause/resume, and retrying only failed parts. AWS recommends multipart for objects over 100 MB and requires it for any object over the 5 GB single-PUT limit. Combine it with S3 Transfer Acceleration for long-distance uploads.

Events and Consistency

Event notifications fire on object actions such as s3:ObjectCreated:* or s3:ObjectRemoved:* and target Lambda, SQS, SNS, or EventBridge for event-driven pipelines (thumbnailing, indexing, virus scanning). S3 provides strong read-after-write consistency for all GET, PUT, and LIST operations across all buckets, with no configuration required — a read issued immediately after a successful write returns the latest data.

Access Control and Static Hosting

Object access is decided by combining identity-based IAM policies , resource-based bucket policies , and Block Public Access (on by default at the account and bucket level, and the reason many "why is my object private" questions resolve). For static websites, S3 can serve content directly via website hosting, but the production pattern fronts a private bucket with Amazon CloudFront using an Origin Access Control (OAC) so the bucket stays private while CloudFront caches at the edge. S3 Object Lambda can transform objects on the fly during GET (redact PII, resize images) without storing a second copy.

Replication, Performance, and Traps

Cross-Region Replication (CRR) and Same-Region Replication (SRR) asynchronously copy new objects to another bucket (CRR requires versioning on both ends) for compliance, latency, or DR. S3 scales to very high request rates per prefix automatically, so old advice to randomize key prefixes is obsolete.

Frequent exam traps: choosing One Zone-IA for non-reproducible data (it lives in a single AZ and can be lost if that AZ fails); forgetting the lifecycle rule to abort incomplete multipart uploads , which silently bills for orphaned parts; assuming you must enable versioning to get strong consistency (you do not); and using a public bucket when a presigned URL would grant scoped, time-limited access far more safely.

A further point worth memorizing: presigned-URL validity is bounded by the lifetime of the credentials that signed it, so a URL signed with short-lived role credentials may expire sooner than the requested expiration, while one signed with IAM-user keys can last up to seven days. When uploads must be enforced to a specific size or content type, generate a presigned POST policy rather than a presigned PUT, because the POST policy can impose conditions the browser must satisfy before S3 accepts the object.