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 what exactly S3 Cross-Region Replication (CRR) replicates by default versus what it doesn’t. In production, this is about knowing precisely which objects, versions, and metadata automatically replicate, and how access permissions impact replication success. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
At DataStream Corp, the cloud operations team recently implemented Amazon S3 Cross-Region Replication to enhance disaster recovery capabilities. The team set up CRR on the primary S3 bucket in us-east-1 to replicate data to a secondary bucket in eu-west-1. After some time, they want to verify exactly what data and metadata are replicated automatically by this feature.
The Requirement: #
Identify which of the following items Amazon S3 Cross-Region Replication replicates to the destination bucket by default without additional manual intervention.
The Options #
- A) Objects in the source S3 bucket for which the bucket owner does not have permissions
- B) Objects that are stored in S3 Glacier storage class
- C) Objects that existed before replication was configured
- D) Object metadata
Google adsense #
leave a comment:
Correct Answer #
D) Object metadata
Quick Insight: The SysOps Imperative #
- For SOA-C02, understanding replication boundaries is crucial to troubleshooting sync failures or unexpected data gaps. Knowing that metadata replicates by default helps with ops monitoring and debugging.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option D
The Winning Logic #
Amazon S3 Cross-Region Replication (CRR) copies both the objects and their associated metadata to the destination bucket after replication is enabled. This means metadata such as object tags, ACLs (if bucket owner controls them), and user-defined metadata are replicated alongside the objects.
However, by default:
- Objects that existed before CRR was configured (Option C) are not replicated unless a manual backfill or batch replication is initiated.
- Objects stored in S3 Glacier (Option B) are not replicated because Glacier is a deep archival tier inaccessible for replication until restored.
- Objects for which the bucket owner lacks permissions (Option A) will not replicate since replication requires read access by the replication role.
Therefore, only object metadata associated with replicated objects automatically transfers during replication.
The Trap (Distractor Analysis): #
- Why not A? Permissions are required for replication to work; otherwise, replication skips those objects.
- Why not B? Glacier storage class objects are archived and cannot be replicated until restored.
- Why not C? Pre-existing objects before replication enablement require manual intervention to replicate.
The Technical Blueprint #
For SysOps (CLI snippet to check replication status):
aws s3api get-bucket-replication --bucket datastream-primary-bucket
This command helps inspect replication configuration, status, and can aid in troubleshooting what is replicating.
The Comparative Analysis #
| Option | Operational Overhead | Automation Level | Impact on Replication |
|---|---|---|---|
| A | High: Requires fixing permissions errors | Low | Objects without proper perms never replicate |
| B | Manual restore needed before replication | None (until restored) | Glacier-stored objects excluded until restored |
| C | Requires manual backfill or custom scripts | None | Objects pre-dating replication setup won’t replicate |
| D | Included in default replication process | High | Metadata replication happens automatically |
Real-World Application (Practitioner Insight) #
Exam Rule #
“For the exam, always remember S3 CRR automatically replicates object metadata along with objects created after replication is enabled.”
Real World #
“In production, especially during audits or DR drills, teams often forget to replicate existing objects unless they run a backfill job. This oversight can cause data inconsistency in critical recovery scenarios.”
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS SOA-C02 exam.