AWS SOA-C02 Drill: S3 Versioning & Lifecycle - The Noncurrent Object Retention Pattern

Jeff’s Note

#

Jeff’s Note

#

“Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Site Reliability Engineer (SRE).”

“For SOA-C02 candidates, the confusion often lies in distinguishing between backup solutions, replication features, and native S3 data protection mechanisms. In production, this is about knowing exactly which S3 feature provides versioning protection and how lifecycle policies manage object retention automatically. Let’s drill down.”

The Certification Drill (Simulated Question)

#

Scenario

#

A SysOps engineer at CloudRetail Inc. is responsible for implementing a data protection strategy for their primary inventory management system that stores critical files in Amazon S3. The engineering team has reported several incidents where objects were accidentally overwritten during automated batch uploads, causing data integrity issues. The compliance team requires that any replaced or deleted object versions must be retained for exactly 90 days for audit purposes, after which they must be permanently removed to reduce storage costs. All data must remain within the us-east-1 region due to data residency requirements.

The Requirement:

#

Implement a solution that protects S3 objects from accidental overwrites and deletions, retains superseded object versions for 90 days, and automatically purges them afterward—all while keeping objects in the same AWS region.

The Options

#

• A) Create an Amazon Data Lifecycle Manager (Amazon DLM) lifecycle policy for the S3 bucket and add a rule to delete noncurrent objects after 90 days.
• B) Create an AWS Backup policy for the S3 bucket with a backup rule that includes a lifecycle to expire noncurrent objects after 90 days.
• C) Enable cross-region replication on the S3 bucket and create an S3 lifecycle policy for the bucket to expire noncurrent objects after 90 days.
• D) Enable S3 versioning on the bucket and create an S3 lifecycle policy for the bucket to expire noncurrent objects after 90 days.

Correct Answer

#

D) Enable S3 versioning on the bucket and create an S3 lifecycle policy for the bucket to expire noncurrent objects after 90 days.

Quick Insight: The SysOps Automation Imperative

#

• For SysOps Engineers: This scenario tests your understanding of native S3 data protection features versus auxiliary backup/replication services. The key differentiator is recognizing that S3 Versioning is the foundational mechanism for protecting against overwrites/deletes, and S3 Lifecycle policies with NoncurrentVersionExpiration provide the automation layer for retention management—no external services required.

Content Locked: The Expert Analysis

#

You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior SysOps Engineer?

The Expert’s Analysis

#

Correct Answer

#

Option D: Enable S3 versioning on the bucket and create an S3 lifecycle policy for the bucket to expire noncurrent objects after 90 days.

The Winning Logic

#

This solution addresses all requirements through native S3 capabilities:

• S3 Versioning Protection: When versioning is enabled, S3 preserves every version of every object. An overwrite creates a new version rather than replacing the original. A delete operation inserts a delete marker instead of permanently removing the object—both actions preserve the previous versions.

• Noncurrent Version Management: Once a new version becomes current, previous versions become “noncurrent.” The lifecycle policy’s NoncurrentVersionExpiration action specifically targets these versions.

• Automated Retention & Cleanup: The lifecycle rule automatically expires (permanently deletes) noncurrent versions after exactly 90 days, satisfying both the retention requirement and the cost-optimization mandate.

• Single-Region Operation: All versioning and lifecycle operations occur within the same bucket in the same region—no data movement required.

Key API/Configuration Details for SysOps:

# Enable versioning
aws s3api put-bucket-versioning \
    --bucket cloudretail-inventory \
    --versioning-configuration Status=Enabled

# Create lifecycle policy
aws s3api put-bucket-lifecycle-configuration \
    --bucket cloudretail-inventory \
    --lifecycle-configuration file://lifecycle.json

lifecycle.json:

{
  "Rules": [
    {
      "Id": "ExpireNoncurrentVersions",
      "Status": "Enabled",
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": 90
      }
    }
  ]
}

The Trap (Distractor Analysis):

#

• Why not Option A? Amazon Data Lifecycle Manager (DLM) manages EBS snapshots and EBS-backed AMIs—it does not manage S3 objects or S3 versioning. This is a classic service-scope trap for candidates who confuse lifecycle management services.

• Why not Option B? AWS Backup for S3 creates point-in-time backups (called “recovery points”) in a separate backup vault, which adds complexity and cost. It does not provide the continuous versioning protection that prevents overwrites in real-time. Additionally, the requirement specifies managing “noncurrent objects” which is a versioning concept, not a backup concept. AWS Backup’s lifecycle rules manage backup retention, not object version retention within the source bucket.

• Why not Option C? Cross-Region Replication (CRR) explicitly violates the “same AWS region” requirement. While you could technically create a lifecycle policy on the source bucket, enabling CRR is unnecessary overhead and introduces compliance risks by copying data to another region. CRR is for disaster recovery across regions, not for version retention within a single bucket.

The Technical Blueprint

#

SysOps CLI Implementation Pattern:

# Step 1: Verify current versioning status
aws s3api get-bucket-versioning --bucket cloudretail-inventory

# Step 2: Enable versioning (if not already enabled)
aws s3api put-bucket-versioning \
    --bucket cloudretail-inventory \
    --versioning-configuration Status=Enabled

# Step 3: Create lifecycle configuration file
cat > lifecycle-policy.json << EOF
{
  "Rules": [
    {
      "Id": "RetainNoncurrentVersions90Days",
      "Status": "Enabled",
      "Filter": {},
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": 90
      }
    }
  ]
}
EOF

# Step 4: Apply lifecycle policy
aws s3api put-bucket-lifecycle-configuration \
    --bucket cloudretail-inventory \
    --lifecycle-configuration file://lifecycle-policy.json

# Step 5: Verify lifecycle configuration
aws s3api get-bucket-lifecycle-configuration \
    --bucket cloudretail-inventory

# Step 6: Monitor with CloudWatch Metrics (SysOps Best Practice)
aws cloudwatch get-metric-statistics \
    --namespace AWS/S3 \
    --metric-name NumberOfObjects \
    --dimensions Name=BucketName,Value=cloudretail-inventory Name=StorageType,Value=AllStorageTypes \
    --start-time 2025-01-01T00:00:00Z \
    --end-time 2025-01-21T23:59:59Z \
    --period 86400 \
    --statistics Average

Operational Validation:

# Test versioning protection
echo "version1" > test-object.txt
aws s3 cp test-object.txt s3://cloudretail-inventory/

echo "version2" > test-object.txt
aws s3 cp test-object.txt s3://cloudretail-inventory/

# List all versions to confirm protection
aws s3api list-object-versions \
    --bucket cloudretail-inventory \
    --prefix test-object.txt

The Comparative Analysis

#

SysOps Impact Assessment:

• Option D requires zero ongoing intervention after initial setup—lifecycle policies run automatically
• Option B would require monitoring backup jobs, managing backup vaults, and handling restore operations
• Option C doubles storage costs unnecessarily and complicates compliance

Real-World Application (Practitioner Insight)

#

Exam Rule

#

“For the SOA-C02 exam, when you see requirements for protecting against accidental overwrites/deletes + retaining previous versions for a specific period + same region, immediately think: S3 Versioning + Lifecycle Policy with NoncurrentVersionExpiration.”

Real World

#

“In production at large-scale organizations, we often layer multiple strategies:

1. Enable S3 Versioning with lifecycle policies for operational protection (as in this scenario)
2. Add MFA Delete for buckets containing critical financial/compliance data to prevent even authorized users from permanently deleting versions without multi-factor authentication
3. Implement S3 Object Lock (compliance mode) for write-once-read-many (WORM) requirements where even the root account cannot delete objects before the retention period
4. Use AWS Backup as a secondary layer for long-term archival to Glacier, separate from the operational versioning strategy

The exam simplifies this to test your understanding of the foundational pattern, but real-world SRE teams combine these based on RTO/RPO requirements, compliance mandates (HIPAA, SOC 2, GDPR), and cost optimization targets. For example, we might use:

{
  "Rules": [
    {
      "Id": "IntelligentTiering",
      "Status": "Enabled",
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "INTELLIGENT_TIERING"
        }
      ],
      "NoncurrentVersionTransitions": [
        {
          "NoncurrentDays": 30,
          "StorageClass": "GLACIER_IR"
        }
      ],
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": 90
      }
    }
  ]
}

This moves noncurrent versions to cheaper Glacier Instant Retrieval after 30 days, then expires them at 90 days—reducing storage costs by ~70% while maintaining compliance.”

SysOps Monitoring Pro Tip: Set up a CloudWatch alarm for the NumberOfObjects metric filtered by StorageType=NonCurrentVersions to track version accumulation and validate that lifecycle policies are executing as expected.

Stop Guessing, Start Mastering

#

Disclaimer

This is a study note based on simulated scenarios for the SOA-C02 exam. Always refer to the official AWS documentation and your organization’s compliance requirements when implementing data protection strategies.