Amazon SOA-C02: Storage and Data Management — Study Guide
Part of the AWS SysOps Administrator Associate SOA-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.
Storage and Data Management covers designing, operating, and optimizing object, block, and file storage in AWS to meet availability, cost, and performance requirements. It includes lifecycle policies, encryption and access controls, backup/snapshot strategies, and selecting appropriate storage classes or file systems based on access patterns. Operational importance lies in controlling cost, ensuring recoverability, and meeting performance SLAs while enforcing security and compliance.
S3 object lifecycle, versioning, and storage classes
S3 is object storage with a rich set of storage classes (STANDARD, INTELLIGENT_TIERING, STANDARD_IA, ONEZONE_IA, GLACIER_INSTANT_RETRIEVAL, GLACIER_FLEXIBLE_RETRIEVAL, DEEP_ARCHIVE) optimized for different access frequency, retrieval latency, and resiliency. Choose classes by access pattern (frequent vs infrequent), required retrieval time, and cross-AZ durability. Use lifecycle rules (console or aws s3api put-bucket-lifecycle-configuration –bucket my-bucket –lifecycle-configuration file://policy.json) to transition objects automatically; base transitions on object age, tags, or prefix. Intelligent-Tiering removes guesswork for unknown or changing patterns but has monitoring charges; Standard-IA yields lower storage cost but has per-GB retrieval and minimum storage duration.
Versioning must be enabled for critical buckets (aws s3api put-bucket-versioning –bucket my-bucket –versioning-configuration Status=Enabled). With versioning you can retain object history, recover from accidental deletes, and leverage S3 Object Lock (governance/compliance) and MFA Delete for stricter protection. Lifecycle rules can expire noncurrent versions or clean up delete markers; test lifecycle rules on a staging bucket to avoid unintended deletions. For access controls, combine bucket policies, IAM policies, and S3 Block Public Access; prefer SSE-KMS for auditability (SSE-KMS uses KMS CMKs and produces CloudTrail logs for key usage) or SSE-S3 when you need simple server-side encryption without KMS.
EBS volumes, snapshot management, and performance
EBS is block storage attached to EC2 instances and provides volume types targeted for cost and performance: gp3/gp2 (general purpose SSD), io1/io2 (provisioned IOPS SSD), st1/sc1 (throughput-optimized HDD / cold HDD). Select gp3 to decouple IOPS and throughput from size (use aws ec2 modify-volume to set IOPS/throughput). Monitor CloudWatch metrics VolumeReadOps, VolumeWriteOps, VolumeThroughput, and VolumeQueueLength to detect saturation; use EBS-optimized instances and appropriate ENA drivers for high throughput/IOPS.
Snapshots are incremental: the first snapshot copies all blocks, subsequent snapshots only store changed blocks, but snapshot costs can grow if many changed blocks accumulate or if you retain many generations. Manage lifecycle with Data Lifecycle Manager (DLM) or AWS Backup to schedule, retain, and copy snapshots across regions. Use aws ec2 create-snapshot –volume-id vol-xxxx –description “daily” for ad-hoc snapshots; restore with create-volume from snapshot. Remember snapshots capture the block device state from the perspective of the host—quiesce filesystems (fsfreeze or use application-consistent agents) for database consistency or use snapshots integrated with backup tools.
File systems: EFS and FSx operations
EFS provides managed NFSv4 (or NFSv4.1/4.2) for Linux workloads, offering elastic capacity, multiple throughput modes (bursting vs provisioned), and lifecycle management to move files to EFS Infrequent Access. Configure mount targets per Availability Zone, security group rules for NFS (TCP 2049), and enable encryption at rest with KMS and encryption in transit (TLS). Use Performance Modes (General Purpose vs Max I/O) depending on latency and metadata throughput needs and provision throughput for steady high-throughput workloads (aws efs create-file-system –performance-mode maxIO –throughput-mode provisioned –provisioned-throughput-in-mibps 128).
FSx offers SMB (FSx for Windows File Server) and Lustre (FSx for Lustre) with different semantics: FSx for Windows integrates with AD for SMB and supports Windows ACLs, DFS Namespaces, and backups; FSx for Lustre targets high-performance HPC and can link to S3 for data repository integration. Configure daily automated backups, set throughput capacity, and select SSD or HDD as needed. Use Active Directory configuration steps and mount via SMB (\fsx-dns\share) for Windows clients or Linux SMB clients with cifs-utils.
Storage tiering, lifecycle policies, and archive
Tiering reduces cost by moving data along a lifecycle: hot -> warm -> cold -> archive. Implement tiering through S3 lifecycle rules and EFS lifecycle policies, and use automatic migration tools (Intelligent-Tiering, EFS IA). For long-term archive choose Glacier classes based on retrieval SLAs: Instant Retrieval for frequent quick access, Flexible Retrieval for standard bulk restores, Deep Archive for smallest cost and multi-hour restore windows. For EBS, export snapshots to S3 Glacier-compatible archive using Backup Vault Lock with cross-region copies to optimize cost.
When designing policies consider minimum storage durations, retrieval and early-deletion charges, and access patterns. For compliance, combine S3 Object Lock (governance/compliance modes) with lifecycle transitions set to expire only after the retention period. Test restore procedures periodically (perform a restore from Glacier Flexible Retrieval/Deep Archive to validate time-cost and operational steps) and automate restores where possible using AWS CLI batch scripts or Lambda orchestration.
Data durability, consistency, and access patterns
Durability and consistency choices shape architecture: S3 offers high durability (11 nines) and strong read-after-write consistency for PUTs/DELETEs; EBS provides single-AZ durability for volumes with snapshots stored in S3 for durability and cross-region copies for DR; EFS offers strong consistency for concurrent clients. Select storage type by access pattern:
- Object (S3): best for large-scale immutable or append-only data, web assets, large datasets, analytics landing zones.
- Block (EBS): best for OS and databases requiring low-latency random reads/writes and single-writer semantics.
- File (EFS/FSx): best for shared file workloads, home directories, or Windows SMB applications requiring POSIX/ACL semantics.
Design for read/write locality, consider caching layers (Amazon ElastiCache, Amazon CloudFront for S3 objects), and use lifecycle and tiering to align cost with access frequency. Encrypt data at rest and in transit (SSE-S3/SSE-KMS or client-side, EBS encryption with KMS, EFS kms keys, and SMB/SMB3 encryption for FSx), and enforce least-privilege using IAM, bucket policies, and VPC endpoints for private access.
Common Pitfalls and Decision Criteria
- Not enabling S3 versioning for critical data: enable versioning and optionally apply S3 Object Lock for immutable retention; use lifecycle rules to expire noncurrent versions to control cost.
- Unexpected snapshot and storage costs: schedule snapshot pruning with DLM/AWS Backup, monitor snapshot storage consumption, and remember snapshots are incremental but can still reference many blocks—delete unneeded snapshots and copy only necessary snapshots across regions.
- Choosing wrong storage class for access patterns: use Intelligent-Tiering for unknown patterns, or analyze access logs and use lifecycle rules; avoid Glacier deep classes for frequently accessed objects.
- Assuming EBS snapshots are instantaneous application-consistent backups: quiesce filesystems or use application-aware backups for databases; use AWS Backup to capture application-consistent snapshots where supported.
- Missing encryption key access controls: when using SSE-KMS, ensure IAM and KMS key policies allow intended users and services; rotate keys and monitor KMS usage in CloudTrail.
- Overlooking throughput/IOPS limits: provision io1/io2 or gp3 IOPS/throughput as needed, select appropriate EFS performance mode, and choose FSx throughput capacity to avoid runtime bottlenecks.
Practical Problem: Use-Case Scenario
DataCorp Analytics stores month-end transaction dumps in S3 and nightly processed results on EBS-backed EC2 instances. They face rising storage costs, accidental overwrites, and slow restores from archived data.
- Enable S3 versioning on the bucket and set Object Lock for retention on regulated datasets; add lifecycle rules to transition older objects to Intelligent-Tiering then to Glacier Flexible Retrieval after a defined age.
- Analyze S3 access logs and CloudWatch metrics for a 30-day period; move truly cold objects to Glacier Deep Archive only after confirming low access.
- Implement DLM/AWS Backup policies for EBS volumes with weekly full snapshots and a retention policy; quiesce databases before snapshots and copy critical snapshots to another region for DR.
- Introduce Intelligent-Tiering for unknown pattern data and use cost allocation tags to track cost per environment; automate alerting for unexpected storage growth.
- Validate restore procedures quarterly by restoring sample Glacier and snapshot data to ensure recovery time and cost expectations are met.
Rationale: This approach matches storage class and snapshot lifecycle to observed access patterns, enforces recoverability with versioning and tested restores, and uses automated lifecycle and backup tools to control costs while meeting durability and compliance needs.
← Networking and Content Delivery · All domains · Compute and Auto Scaling →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →