S3 & Storage

Correct answer: .

S3 Glacier Deep Archive is the lowest-cost storage class in S3 and is designed exactly for long-term retention of data accessed perhaps once or twice a year. Its standard retrieval completes within 12 hours, which matches the auditors' tolerance precisely. Glacier Flexible Retrieval restores faster but costs more per GB stored, so paying for speed the hospital does not need wastes money over a 10-year horizon. Standard-IA suits data needing millisecond access at infrequent intervals, and S3 Standard suits frequently accessed data; both are far more expensive for a decade-long archive. On the exam, match the stated retrieval tolerance to the cheapest class that satisfies it.

Source: AWS S3 docs: Amazon S3 storage classes — Glacier Deep Archive retrieval times

Correct answer: .

Once versioning has been enabled on a bucket, the bucket can never return to the unversioned state. The only available change is to suspend versioning. Suspension preserves every existing object version exactly as it is, and from that point new uploads receive a null version ID instead of stacking new versions. Nothing is deleted automatically, so the option claiming that disabling versioning deletes all previous versions describes behaviour that does not exist and would be dangerous if it did. Emptying the bucket does not unlock a disable option either. The claim that versioning can never be changed at all overstates the restriction, since suspension is a real state change. The exam frequently tests this exact enabled-versus-suspended distinction.

Source: AWS S3 docs: Using versioning in S3 buckets — versioning states

Correct answer: .

Since January 5, 2023, Amazon S3 applies server-side encryption with Amazon S3 managed keys (SSE-S3) as the base level of encryption for every object uploaded to every bucket, automatically and at no additional cost, with no performance impact. This happens whether or not the uploader specifies encryption headers or the bucket has a default encryption setting configured, so the object here is encrypted with SSE-S3 by default. It is never stored unencrypted, so that option describes behaviour S3 no longer allows. The upload does not fail and does not require any prior configuration step, so the option claiming encryption must be set up first is wrong. SSE-KMS is only used when explicitly requested via a header or a bucket default encryption configuration naming a KMS key; without that configuration S3 falls back to SSE-S3, not SSE-KMS, so the option claiming automatic SSE-KMS encryption misidentifies which key type is used automatically.

Source: AWS S3 documentation: Using server-side encryption with AWS KMS keys (SSE-KMS) — default SSE-S3 encryption for all new object uploads since January 5, 2023

Correct answer: .

Every object in Amazon S3 has an associated storage class, and S3 Standard is explicitly documented as the default: if you don't specify the storage class when you upload an object, Amazon S3 assigns S3 Standard. This makes S3 Standard the correct answer regardless of what prefix or key the object shares with other objects. S3 Intelligent-Tiering is a real storage class, but it must be deliberately selected at upload time or applied later through a lifecycle rule; it is never assigned automatically just because no class was specified. S3 Standard-Infrequent Access likewise requires an explicit choice and is not a fallback default. The storage class of other objects sharing a key prefix is irrelevant because S3 has no concept of folder-level storage class inheritance; each object's class is set independently per PutObject call, so the option suggesting inheritance from a previous object with the same key prefix describes behaviour S3 does not have.

Source: AWS S3 documentation: Understanding and managing Amazon S3 storage classes — S3 Standard is the default storage class

Correct answer: .

S3 Standard-IA carries a minimum storage duration of 30 days. AWS documentation states that objects deleted, overwritten, or transitioned to a different storage class before 30 days incur the normal storage usage charge for the days the object was actually stored, plus a pro-rated charge for the remainder of the 30-day minimum, so the pro-rated charge is exactly what the company should expect. The option expecting no extra charge is wrong because deletion is treated the same as early transition for billing purposes; there is no exemption just because the action is a delete rather than a move. There is no separate flat annual penalty fee defined anywhere in S3's pricing model, so the option describing a year-of-storage penalty invents a charge that does not exist. Finally, the minimum duration is a billing construct, not an operational lock: S3 never prevents a user from deleting or overwriting an object early, it simply still bills for the unused portion of the minimum period, so the deletion is not blocked.

Source: AWS S3 documentation: Understanding and managing Amazon S3 storage classes — S3 Standard-IA minimum storage duration and early-deletion billing

Correct answer: .

S3 One Zone-IA stores object data in only a single Availability Zone, which makes it less expensive than S3 Standard-IA, but it is explicitly documented as not resilient to the physical loss of that Availability Zone from disasters such as fire, flood, or earthquake. AWS recommends it specifically for data that can be re-created if the AZ fails, which matches the reproducible simulation output described. S3 Standard-IA stores data redundantly across at least three Availability Zones and costs more precisely because it protects against AZ loss, which the lab does not need to pay for here. S3 Glacier Instant Retrieval is also multi-AZ and is designed for archive data accessed roughly once a quarter with a 90-day minimum duration, not the cheapest option for this profile. S3 Intelligent-Tiering is also multi-AZ resilient and adds a monitoring fee, so it does not offer the single-AZ cost saving the question asks for.

Source: AWS S3 documentation: Understanding and managing Amazon S3 storage classes — S3 One Zone-IA durability and recommended use

Correct answer: .

S3 Intelligent-Tiering is designed to optimise storage costs for data with unknown or changing access patterns by automatically moving objects between access tiers at the object level, and AWS documentation states plainly that there are no retrieval fees for S3 Intelligent-Tiering; instead, a small monthly monitoring and automation fee is charged per object, which makes that statement the correct one. The option claiming per-GB retrieval fees is wrong because retrieval fees are exactly what this storage class avoids, unlike Standard-IA or One Zone-IA. The option requiring manual lifecycle rules is wrong because the whole point of Intelligent-Tiering is that S3 monitors access patterns and moves objects between the Frequent Access, Infrequent Access, and Archive Instant Access tiers automatically, without any lifecycle rule or manual action required. The claim that small objects are rejected is also wrong: objects smaller than 128 KB are not rejected, they are simply not monitored for tiering and remain in the Frequent Access tier by default, still fully stored and accessible.

Source: AWS S3 documentation: Understanding and managing Amazon S3 storage classes — S3 Intelligent-Tiering fees and automatic tier movement

Correct answer: .

AWS documentation on replication requirements states plainly that both the source and destination buckets must have versioning enabled before a replication configuration can be created; if the destination bucket does not have versioning enabled, the replication configuration will not succeed. This makes enabling versioning on the destination bucket the missing requirement, and the option claiming nothing further is required incorrect, since versioning on the source alone is not sufficient. Cross-account replication is explicitly supported by S3 as long as the destination bucket owner grants the source account permission through a bucket policy, so replication does not require both buckets to belong to the same account, making the same-account option wrong. Requester Pays is unrelated to enabling replication on the source side; in fact, AWS documentation notes that in a cross-account scenario the destination bucket specifically cannot be configured as Requester Pays, but nothing requires the source bucket to become Requester Pays, making the Requester Pays option incorrect.

Source: AWS S3 documentation: Requirements and considerations for replication — versioning must be enabled on both source and destination buckets

Correct answer: .

A gateway VPC endpoint for S3 is a target you add to a route table so that traffic destined for S3 in the same Region travels over the AWS network instead of the internet, and AWS documentation lists gateway endpoints as 'not billed', unlike interface endpoints. Because the instances only need same-Region access and no internet gateway or NAT is available, a gateway endpoint satisfies the requirement at no extra hourly cost, making it the correct choice. An interface VPC endpoint (AWS PrivateLink) also keeps traffic off the internet and works for S3, but it is billed hourly plus per-GB data processing charges, and it is primarily needed for on-premises or cross-Region access rather than same-Region in-VPC traffic, so it doesn't meet the 'no additional charge' requirement here. A NAT gateway would route traffic out through an internet gateway to reach S3's public endpoint, which is unavailable in this subnet and also incurs its own hourly and data processing charges. VPC peering connects two VPCs directly and has no role in reaching a public AWS service endpoint like S3, so it does not apply.

Source: AWS S3 documentation: AWS PrivateLink for Amazon S3 — gateway endpoints are not billed and route S3 traffic within a Region over the AWS network

Correct answer: .

AWS documentation on uploading objects states that with a single PUT operation, using the AWS CLI, SDKs, or REST API, you can upload a single object only up to 5 GB in size; anything larger must use the multipart upload API instead, which supports objects up to far larger sizes. The 6 GB file in this scenario exceeds that 5 GB single-PUT ceiling, so the request fails and the engineer must switch to multipart upload, making the first option correct. The third option incorrectly applies a large aggregate object-size limit to a single PUT request, when that ceiling only applies to the overall size an object can reach via multipart upload, not to one PUT call. S3 does not silently convert an oversized single PUT into multipart parts on the caller's behalf; the caller must explicitly initiate a multipart upload, so the fourth option describes automation that does not exist. The AWS CLI does support single PUT uploads for objects at or below 5 GB, so the second option is factually wrong.

Source: AWS S3 documentation: Uploading objects — single PUT operation limited to 5 GB, multipart required above that size

Correct answer: .

AWS's published multipart upload specifications state that part size must be between 5 MiB and 5 GiB, but explicitly add that there is no minimum size limit on the last part of a multipart upload. Since every part in this scenario is 5 MiB except the final, smaller part, the upload conforms exactly to this rule, so it is valid. The option applying the minimum to every part is wrong because it misapplies the 5 MiB minimum to the last part, when AWS explicitly exempts it. The option requiring uniform part sizes is wrong because multipart upload never requires them; parts can vary in size as long as each (other than the last) meets the 5 MiB to 5 GiB range, and parts can even be uploaded in any order or in parallel. The option requiring the smaller part to be uploaded first invents an ordering requirement that does not exist: part numbers determine the final assembled sequence of the object, not the order in which they are physically uploaded, and the smaller final part does not need to be uploaded first or last relative to the others.

Source: AWS S3 documentation: Amazon S3 multipart upload limits — part size 5 MiB to 5 GiB, no minimum on the last part

Correct answer: .

AWS documentation on S3 Object Lock states directly that Object Lock works only in buckets that have S3 Versioning enabled, because retention periods and legal holds are applied to individual object versions rather than to a single mutable object. This means the firm must enable versioning on the bucket before Object Lock protection can be configured, and the claim that Object Lock is independent of versioning is incorrect. Storage class has nothing to do with Object Lock eligibility; One Zone-IA is a cost-and-durability choice unrelated to WORM protection, so converting the bucket to that storage class would not satisfy any Object Lock prerequisite and is not even how storage classes are set at the bucket level. Legal holds are optional per-object-version protections that can be applied after Object Lock is enabled on a versioned bucket; they are not a prerequisite that must be applied to existing objects before Object Lock itself can be turned on, so the option requiring legal holds first reverses the actual order of operations.

Source: AWS S3 documentation: Locking objects with Object Lock — Object Lock requires S3 Versioning to be enabled

Correct answer: .

AWS documentation on S3 Object Lock retention modes is explicit that in Compliance mode, a protected object version can't be overwritten or deleted by any user, including the root user of the AWS account, and its retention mode can't be changed and its retention period can't be shortened; the documented note even states the only way to delete such an object before its retention date expires is to delete the entire AWS account. The deletion therefore fails for everyone, root included. The option claiming the root user can always override any S3 protection is wrong because root-user override is exactly what Compliance mode is designed to prevent, unlike ordinary IAM permission boundaries. The option involving the BypassGovernanceRetention header describes the bypass mechanism for Governance mode, where the s3:BypassGovernanceRetention permission plus the x-amz-bypass-governance-retention header allow authorized users to override the lock; this mechanism has no effect in Compliance mode, so it cannot be used here. The option tying the failure to a legal hold incorrectly conflates legal holds with retention periods: a legal hold is an independent, indefinite protection that can be removed by an authorized user, but removing one does not affect a separate Compliance-mode retention period, which remains enforced regardless.

Source: AWS S3 documentation: Locking objects with Object Lock — Compliance mode retention cannot be overridden by any user including root

Correct answer: .

AWS documentation on Object Lock retention modes explains that to override or remove Governance-mode retention settings, a user must have the s3:BypassGovernanceRetention permission AND must explicitly include the x-amz-bypass-governance-retention:true header with the request that requires overriding governance mode; holding the permission alone is not sufficient without also sending that header (the console includes it automatically, but a direct API or CLI call does not add it for you). This makes including the bypass header the required step, and the claim that the permission alone silently allows the delete incorrect, since the header is a required explicit step, not an automatic consequence of having the permission. Legal holds are a separate, independent protection mechanism from retention periods; this scenario describes only a retention period, so there is no legal hold to wait out, making the option about waiting for a legal hold irrelevant to this situation. Retention mode can be changed from Governance to Compliance, but doing so would make the object harder to delete, not easier, since Compliance mode cannot be bypassed by anyone; switching modes achieves the opposite of what the administrator needs, so that option is incorrect.

Source: AWS S3 documentation: Locking objects with Object Lock — Governance mode bypass requires s3:BypassGovernanceRetention permission and the bypass header

Correct answer: .

AWS documentation on presigned URLs states that if you use the AWS CLI or AWS SDKs with long-term credentials such as an IAM user's access keys, the expiration time for a presigned URL can be set as high as 7 days, which is the maximum in this scenario. Both 15 minutes and 1 hour are valid values someone could choose for a shorter-lived URL, but neither represents the actual ceiling the SDK enforces, so they understate the true maximum and are incorrect as answers to what the maximum is. The claim that there is no maximum is wrong because presigned URLs generated with long-term credentials are always subject to this 7-day ceiling; attempting to set a longer expiration does not produce an unlimited or indefinitely valid URL. (Note that if temporary, STS-issued credentials are used instead, the presigned URL's validity is further capped by the remaining lifetime of that temporary session, which can be shorter than 7 days, but that is not the case described here.)

Source: AWS S3 documentation: Uploading objects with presigned URLs — 7-day maximum expiration when using the AWS CLI or SDKs

Correct answer: .

AWS's documented requirements for replication state that in a cross-account replication scenario, the destination bucket cannot be configured as a Requester Pays bucket; this is listed as an explicit additional requirement alongside the destination bucket owner granting the source account permission via a bucket policy. Because Company A's bucket is both Requester Pays and in a different account from Company B's source bucket, the configuration described is simply not permitted. The claim that Requester Pays has no effect on replication is wrong because Requester Pays status directly blocks this specific cross-account replication setup rather than being irrelevant to it. The option shifting all replication costs onto Company A invents a workaround that does not exist in AWS's documentation; the restriction is an outright prohibition, not a billing reassignment. The option suggesting versioning be disabled is also incorrect: replication has its own hard requirement that both source and destination buckets have versioning enabled, so disabling versioning would break replication entirely rather than unblocking the Requester Pays restriction, and no such workaround is described in AWS's guidance.

Source: AWS S3 documentation: Requirements and considerations for replication — cross-account replication destination buckets cannot be Requester Pays

Correct answer: .

S3 Access Points are named network endpoints attached to a bucket, and each access point carries its own dedicated access policy, so a team can be granted access scoped to only its own prefix through its own endpoint without anyone touching the underlying bucket policy. This is exactly the problem access points solve: managing access to a large shared dataset at scale as the number of consumers grows. Replicating the bucket per team multiplies storage cost, still requires policy management on every copy, and does not scope access by prefix on a single dataset. Granting broad administrative permissions to every team violates least privilege and gives far more access than the stated requirement. Continually appending statements to one bucket policy is the unscalable pattern the company is trying to escape, and bucket policies are also capped at 20 KB, so that approach eventually stops working outright as more teams are onboarded.

Source: AWS S3 docs: Managing access to shared datasets with access points

Correct answer: .

Static website hosting on S3 requires enabling the website hosting configuration on the bucket, specifying at least an index document, and making the objects publicly readable, since S3 buckets and objects are private by default. All of this is necessary: without public read access, visitors receive access-denied errors even with hosting enabled, and without an index document configured, requests to the bucket root have nothing to serve. Transfer Acceleration only affects the speed of uploads and downloads over long distances using CloudFront edge locations; it has no bearing on whether a site can be served at all and is unrelated to public HTTP hosting. Object Lock protects objects from deletion or overwrite for compliance purposes and would have no effect on visitors being able to view the marketing pages. Intelligent-Tiering only moves objects between S3 access tiers based on access patterns to save cost; it does not enable public web serving.

Source: AWS S3 docs: Hosting a static website using Amazon S3

Correct answer: .

A bucket policy is a resource-based policy attached to the bucket itself, so the bucket's owning account can name a principal in another account, such as a specific IAM role ARN, and grant that principal the exact actions and resources needed, including a scoped prefix, entirely from the S3 side without creating any IAM users in the other account. This is the standard way to grant cross-account access to S3 data. An ACL granting a whole other account's root user full control is far broader than the requirement and cannot be scoped to a prefix or to specific API actions the way a policy can, and modern buckets disable ACLs by default besides. A permissions boundary only limits what an IAM principal can be granted within its own account; it cannot itself grant access to a resource owned by a different account. Object Lock governs whether objects can be deleted or overwritten during a retention period and has nothing to do with granting read or write access across accounts.

Source: AWS S3 docs: Bucket policies for Amazon S3

Correct answer: .

S3 Event Notifications let a bucket automatically publish an event to a destination such as an AWS Lambda function, Amazon SQS queue, or Amazon SNS topic whenever a specified action, such as a PutObject upload matching a prefix, occurs. That is precisely the automatic, push-based trigger the thumbnail generator needs, with no polling required. Storage Class Analysis only observes access patterns over time to help decide when objects should move to a cheaper storage class; it has no mechanism to invoke Lambda on upload. Requester Pays only changes who is billed for requests and data transfer against a bucket and has nothing to do with triggering compute. Running S3 Batch Operations manually is a one-time, administrator-initiated bulk action against a manifest of existing objects, not an automatic reaction to each new upload as it happens.

Source: AWS S3 docs: Amazon S3 Event Notifications

Correct answer: .

S3 Select lets an application run a SQL-like expression directly against an object stored in S3 and retrieve only the matching rows or columns, instead of pulling down and parsing the entire object client-side, which cuts both the data transferred and the latency for large CSV, JSON, or Parquet files. Transfer Acceleration only speeds up the network path for uploading or downloading whole objects over long distances; it does not let you filter the contents of an object. Cross-Region Replication copies whole objects to a bucket in another Region for redundancy or latency reasons and has no query capability at all. Glacier Bulk Retrieval is a slow, low-cost restore option for archived objects in Glacier storage classes; it retrieves entire archived objects and is unrelated to running a query against object contents.

Source: AWS S3 docs: Selecting content from objects with S3 Select

Correct answer: .

S3 Storage Lens is built exactly for this purpose: it aggregates usage and activity metrics across an entire organization, including multiple accounts, Regions, and buckets, into interactive dashboards, so nobody has to query each bucket individually to understand storage trends or find cost-optimisation opportunities. Object Lock only prevents objects from being deleted or overwritten for a set period or indefinitely, for WORM compliance, and reports nothing about usage. Requester Pays only shifts who is billed for requests and transfer on a bucket and provides no analytics. Same-Region Replication copies objects to another bucket in the same Region for redundancy or compliance reasons; it is a data-movement feature, not a visibility or reporting feature.

Source: AWS S3 docs: Assessing your storage activity and usage with S3 Storage Lens

Correct answer: .

S3 Batch Operations is designed exactly for this scenario: given a manifest listing the target objects, it can invoke a single action, including invoking a Lambda function, copying, or restoring, across millions or billions of existing objects with a single S3 API request or a few console clicks, handling the iteration, retries, and completion reporting internally. Event Notifications only fire in reaction to new activity on objects, such as a fresh upload, and have no mechanism to sweep across 200 million objects that already exist. Transfer Acceleration only speeds up network transfer of individual uploads and downloads over long distances and has nothing to do with running an operation across a bucket's existing contents. Lifecycle expiration rules only delete or transition objects based on age; they cannot invoke an arbitrary Lambda function to redact a field within each object.

Source: AWS S3 docs: Performing large-scale batch operations on Amazon S3 objects

Correct answer: .

An S3 Bucket Key is a bucket-level key that AWS KMS generates and that Amazon S3 reuses, for a time-limited period, to derive unique data keys for objects in that bucket, which can reduce the volume of requests reaching AWS KMS by up to 99 percent compared with requesting a fresh data key from KMS for every single object request. That directly relieves KMS request throttling while the objects continue to be encrypted with the same customer managed KMS key, satisfying the regulatory requirement. Moving to SSE-C would put key management entirely on the client and abandon the mandated customer managed KMS key, which the requirement rules out. Moving to SSE-S3 would stop using AWS KMS entirely, also violating the mandate, even though it would incidentally solve the throttling. Disabling default bucket encryption does not reduce KMS calls in any useful way and abandons encryption requirements altogether, which the company cannot do.

Source: AWS S3 docs: Reducing the cost of SSE-KMS with Amazon S3 Bucket Keys

Correct answer: .

S3 Transfer Acceleration takes advantage of the globally distributed edge locations that make up the Amazon CloudFront network: data uploaded to the accelerate endpoint enters the AWS network at the nearest edge location and travels the rest of the way to the bucket's Region over Amazon's optimized backbone, rather than the public internet, which is exactly what benefits users far from the bucket's Region. Same-Region Replication only copies objects to another bucket in the same Region after they have already landed in S3; it does nothing to speed up the initial long-distance upload. Intelligent-Tiering only changes which access tier an object's storage cost falls into based on access patterns and has no effect on network transfer speed. Object Lock in Compliance mode only prevents deletion or modification of objects for a retention period and is unrelated to transfer performance.

Source: AWS S3 docs: Configuring fast, secure file transfers using Amazon S3 Transfer Acceleration

Correct answer: .

Amazon S3 provides strong read-after-write consistency for PUT and DELETE requests on objects, in every AWS Region, for both new object writes and overwrites of existing objects, meaning any read that starts after a successful write response is guaranteed to return the new data, never stale or partial data. This replaced the older eventual-consistency behaviour S3 once had for overwrite PUTs in certain cases, so a candidate should not assume a delay is still needed today. Expecting the read to possibly return nothing or stale data for a period describes the older eventual-consistency model, which no longer applies to object reads. There is no requirement to wait for replication to multiple Availability Zones before a read succeeds, since S3 replicates synchronously as part of a successful write. Consistency here does not depend on whether S3 Versioning is turned on; that setting affects whether multiple versions are retained, not whether a read reflects the latest write.

Source: AWS S3 docs: Amazon S3 data consistency model

Correct answer: .

Same-Region Replication (SRR) creates a second copy of objects in a different bucket within the same AWS Region as the source, which fits a requirement for redundancy and faster local access without any data ever leaving the Region, unlike Cross-Region Replication, which by definition copies data into a different Region and does not fit a same-country, no-cross-Region requirement. Transfer Acceleration only optimises the speed of client uploads and downloads over long distances using CloudFront edge locations; it does not create a second persistent copy of the data at all. Object Lock only prevents deletion or modification of objects during a retention period and has no replication mechanism of its own; whether Region-independent or not, it does not copy data anywhere.

Source: AWS S3 docs: Replicating objects within the same AWS Region

Correct answer: .

Since Amazon S3 updated its default Lifecycle transition behaviour, objects smaller than 128 KB are not transitioned to any storage class by default, because the per-object transition request cost can outweigh the storage savings for very small objects; a rule author must add an object size filter allowing smaller objects if they actually want those objects to transition. This default behaviour, not any restriction based on file type, fully explains why the small JSON files stayed in S3 Standard while larger objects transitioned normally under the same rule. Lifecycle rules are not restricted by file format or extension at all, so a blanket claim that JSON is excluded is incorrect. Objects that fail to meet transition criteria are simply left alone in their current storage class; S3 does not delete objects instead of transitioning them unless an expiration action is separately configured. Lifecycle transitions work on both versioned and unversioned buckets, so the presence of versioning is not the explanation here.

Source: AWS S3 docs: Transitioning objects using Amazon S3 Lifecycle — constraints and considerations

Correct answer: .

New S3 buckets are created with the Bucket owner enforced setting for Object Ownership by default, which disables ACLs entirely: the bucket only accepts PUT requests that either specify no ACL or specify the bucket-owner-full-control canned ACL, and any PUT request specifying a different, custom ACL is rejected with an error rather than silently ignored. So the upload in this scenario fails outright, and the bucket owner automatically owns and controls every object regardless of who uploaded it. The idea that the ACL succeeds and grants the third account access is wrong precisely because ACLs no longer affect permissions once this default setting is in place. The idea that the upload succeeds but the ACL is silently dropped is close but incorrect: S3 actively rejects PUT requests carrying an unsupported ACL rather than accepting the upload and discarding the ACL. Block Public Access is a separate setting entirely, governing public access, and has no bearing on whether a same-account-owner ACL upload is accepted.

Source: AWS S3 docs: Controlling ownership of objects and disabling ACLs for your bucket

Correct answer: .

MFA Delete is the S3 feature that requires an additional authentication factor, the concatenation of a valid MFA device serial number and its current code, alongside normal security credentials, before Amazon S3 will permanently delete an object version or change a bucket's versioning state. Critically, only the bucket owner's root account can enable MFA Delete, and it cannot be turned on through the AWS Management Console at all; it must be configured through the AWS CLI or the REST API by including the MFA parameter alongside the versioning configuration request. Object Lock in Governance mode is a different protection mechanism entirely, based on a retention period rather than a second authentication factor, and it can be configured through the console. Access Points manage where and how requests reach a bucket, not what authentication is required to delete a version. Storage Lens only reports on usage and activity; it does not enforce any deletion protection and is not automatically enabled with extra deletion controls.

Source: AWS S3 docs: Configuring MFA delete

Correct answer: .

A CORS (cross-origin resource sharing) configuration is a document attached to the bucket that identifies the origins allowed to access it, the HTTP methods supported for each origin, and other operation-specific details such as which headers a preflight request may send and which response headers a browser script may read. Without a matching CORS rule, a browser enforces same-origin policy and blocks the script's requests to the bucket's different domain, regardless of whether the underlying IAM or bucket-policy permissions would otherwise allow the call; CORS is a browser-side check layered on top of those permissions. Transfer Acceleration only speeds up long-distance uploads and downloads by routing them through CloudFront edge locations onto AWS's backbone network; it has no effect on whether a browser permits a cross-origin script request and does not address the blocking behaviour described. Object Lock in Governance mode only prevents object versions from being deleted or overwritten before a retention period expires; it has nothing to do with cross-origin browser restrictions and would not change what the browser allows. A gateway VPC endpoint for S3 only changes how traffic from within a VPC reaches S3 over the AWS network instead of the internet; it is irrelevant to a public browser making requests from a user's machine and does not configure any origin, method, or header allowances.

Source: AWS S3 documentation: Using cross-origin resource sharing (CORS) — elements of a CORS configuration (AllowedOrigins, AllowedMethods, AllowedHeaders)

Correct answer: .

In a versioning-enabled bucket, a simple DELETE request, meaning one that does not specify a version ID, does not remove any existing object data at all. Instead, Amazon S3 inserts a delete marker, which becomes the new current version of that key. A delete marker has no data associated with it, so a subsequent GET request that also omits a version ID sees the delete marker as the current version and returns a 404 Not Found response (along with an `x-amz-delete-marker: true` header), even though every prior version, including the one that was current before the DELETE, is still fully intact and can be retrieved by requesting it with its specific version ID. The option describing both versions as permanently deleted immediately is wrong because no data is destroyed by a version-less DELETE; that is precisely the safety behaviour versioning is designed to provide. The option describing only the most recent version being permanently deleted, exposing the older version as current, describes what would happen only if the DELETE request had specified that most recent version's ID explicitly, which is a fundamentally different, irreversible operation from the version-less DELETE described here. The option claiming the DELETE is rejected is wrong because S3 never requires a version ID on a DELETE request; omitting it is a fully valid, and in fact the most common, way to delete an object in a versioned bucket, precisely because it is non-destructive.

Source: AWS S3 documentation: Working with delete markers — a simple DELETE without a version ID inserts a delete marker as the current version, and GET without a version ID returns a 404 when the current version is a delete marker

Correct answer: .

AWS documentation explains that after a multipart upload is initiated, S3 retains and bills for every uploaded part until the upload is either completed or explicitly stopped; if neither happens, the parts remain in the bucket indefinitely, accruing storage charges for data that will never become a usable object. The recommended fix is a Lifecycle rule using the AbortIncompleteMultipartUpload action, which tells S3 to automatically identify and delete the parts of any multipart upload that has not completed within a specified number of days, stopping the storage charges without any manual cleanup. Object Lock in Compliance mode only prevents completed object versions from being deleted or overwritten during a retention period; it has no mechanism for finding or removing abandoned multipart upload parts and would not address this cost at all. A Lifecycle rule that transitions completed objects to Glacier Deep Archive only affects objects that already exist in the bucket; it has no effect on in-progress, incomplete multipart uploads, which are not objects and are not eligible for storage-class transition. Requester Pays only shifts who is billed for requests and completed data transfer to the requester; the bucket owner still pays for the underlying storage of the abandoned parts, and Requester Pays does nothing to make the incomplete uploads eligible for automatic deletion.

Source: AWS S3 documentation: Uploading and copying objects using multipart upload — multipart upload pricing and the AbortIncompleteMultipartUpload lifecycle action

Correct answer: .

AWS documentation on what S3 replicates states plainly that, by default, Amazon S3 replicates objects created after a replication configuration is added to the bucket; objects that already existed beforehand are not automatically picked up by live, rule-based replication (whether Same-Region or Cross-Region). To replicate that pre-existing backlog, AWS provides S3 Batch Replication, a separate, explicitly initiated job that takes a manifest of the existing objects and replicates them to the destination bucket on demand. This is exactly the gap the engineer observed and exactly the fix required. The idea that S3 will eventually replicate the backlog automatically given more time is incorrect: standard replication configurations never retroactively sweep up pre-existing objects, no matter how long the rule has been active, which is precisely why a distinct Batch Replication feature exists to solve this problem. There is no 30-day historical cutoff rule governing which pre-existing objects can ever be replicated; the constraint is about the object's creation time relative to when the rule was added, not a fixed lookback window, and Batch Replication has no such 30-day limitation. Deleting and re-uploading every object would technically make each object new relative to the replication rule and trigger replication, but this is a wasteful, disruptive, and unnecessary workaround (it destroys version history and metadata timestamps) when S3 Batch Replication is the documented, purpose-built solution for replicating an existing dataset without touching the source objects.

Source: AWS S3 documentation: What does Amazon S3 replicate? — objects created before a replication configuration are not replicated by default; use S3 Batch Replication for existing objects

Correct answer: .

AWS's general purpose bucket naming rules require names to be 3 to 63 characters long, to consist only of lowercase letters, numbers, periods, and hyphens, to begin and end with a letter or number, to avoid two adjacent periods, and to avoid the format of an IP address; names must also be unique across every AWS account within the same partition, since general purpose buckets share a single global namespace. A name using only lowercase letters, numbers, and hyphens that begins and ends alphanumerically, such as one appending a year, satisfies every one of these rules and is a valid candidate name if not already taken. The option containing uppercase letters and mixed case is invalid because bucket names must be entirely lowercase; S3 will reject it outright regardless of availability. The option with two consecutive periods is explicitly disallowed, since bucket names must not contain two adjacent periods. The option formatted as four dot-separated numeric octets is explicitly disallowed because it matches the format of an IP address, which S3's naming rules specifically forbid regardless of whether such a name is otherwise free.

Source: AWS S3 documentation: General purpose bucket naming rules — length, allowed characters, IP-address format prohibition, and global uniqueness

Correct answer: .

An S3 Multi-Region Access Point provides exactly one global endpoint that applications can use to reach S3 buckets located in multiple AWS Regions; requests made to that endpoint use AWS Global Accelerator to route automatically over the AWS global network to the bucket replica with the closest proximity and an active routing status, rather than requiring clients to be hardcoded to a specific Region. When a Regional traffic disruption occurs, Multi-Region Access Points failover controls let an operator shift request traffic away from the affected Region within minutes, which is exactly the manual, error-prone DNS problem described. An S3 Access Point scoped to a single Region is still bound to one specific bucket in one Region; creating one per Region does not produce a single global endpoint or any automatic nearest-Region routing or failover behaviour, leaving clients to solve that routing problem themselves. S3 Transfer Acceleration only speeds up a single upload or download to one specific bucket by routing it through the nearest CloudFront edge location onto AWS's backbone; it does not provide a unified multi-bucket endpoint or any failover mechanism between Regions. S3 Storage Lens only produces usage and activity metrics dashboards across accounts and Regions; it has no request-routing capability and cannot serve as an endpoint applications connect to at all.

Source: AWS S3 documentation: Managing multi-Region traffic with Multi-Region Access Points — single global endpoint via AWS Global Accelerator and failover controls

Correct answer: .

Amazon S3 supports specifying an additional checksum algorithm when uploading, copying, or managing an object, choosing among CRC-64/NVME (the default used automatically when no algorithm is specified and clients don't supply their own value), CRC-32, CRC-32C, SHA-1, and SHA-256. When a checksum is supplied or requested, S3 independently calculates its own checksum of the received data server-side and validates it against the provided value before storing the object, giving the strong, verifiable integrity guarantee the firm needs, including cryptographic-strength options like SHA-256. Object Lock has nothing to do with data integrity checking; it only controls whether an object version can be deleted or overwritten during a retention period, and it does not sign or checksum object contents at all. Storage Class Analysis only observes access frequency patterns over time to recommend transitioning data to a cheaper storage class; it has no data-integrity or corruption-detection function whatsoever. The claim that the ETag is always a SHA-256 hash is incorrect: for a simple (non-multipart) upload without additional checksums, the ETag is typically the MD5 hash of the object, and for a multipart upload the ETag becomes a hash of the concatenated part hashes rather than a hash of the object's contents at all, so it cannot be relied upon as a straightforward, algorithm-guaranteed integrity check the way an explicitly requested checksum can.

Source: AWS S3 documentation: Checking object integrity in Amazon S3 — supported checksum algorithms (CRC-64/NVME default, CRC-32, CRC-32C, SHA-1, SHA-256) and server-side validation

Correct answer: .

AWS documentation on Requester Pays buckets states directly that if Requester Pays is enabled on a bucket, anonymous access to that bucket is not allowed, and lists anonymous requests explicitly among the request types Requester Pays buckets do not support. Every request against a Requester Pays bucket must be authenticated, specifically so that AWS can identify which requester's account to charge for the request and data transfer; an unauthenticated visitor with no AWS credentials has no account for S3 to bill, so the request is denied outright rather than served. There is no mechanism for AWS to bill an IP address directly for a data transfer; billing is always tied to an authenticated AWS account or the IAM role assumed by the requester, so that option describes a billing model S3 does not have. Including the x-amz-request-payer header is indeed required to accept the transfer charges, but that header alone does nothing without valid AWS credentials backing the request; an anonymous request supplying only that header is still rejected because it remains unauthenticated. The download does not fall back to being billed to the bucket owner as though Requester Pays were absent; enabling Requester Pays specifically closes off the anonymous-access path that would otherwise let the owner absorb the cost, rather than silently preserving the old behaviour for unauthenticated users.

Source: AWS S3 documentation: Using Requester Pays general purpose buckets — anonymous access is not allowed once Requester Pays is enabled

Correct answer: .

S3 Object Lambda lets you add your own code, packaged as an AWS Lambda function, that runs automatically as data is returned to an application through a standard GetObject request, transparently transforming or filtering that data, such as redacting sensitive fields, before the application receives it, all without creating, storing, or maintaining any additional copy of the underlying data. This is exactly the reporting-application requirement described: only that access path sees the transformed response, while the original object in the bucket stays untouched. Lifecycle rules only expire, transition, or delete whole objects (or parts) based on age; they have no ability to selectively strip individual fields from an object's content on a per-request basis, and deleting fields permanently would destroy the original data for every consumer, not just the reporting application. Same-Region Replication would require creating, storing, and continuously maintaining a second physical copy of every object, exactly the overhead and duplication the requirement explicitly rules out, and replication has no field-level redaction capability of its own regardless. S3 Select can extract a subset of an object's data using a SQL-like query, but it does not transform or rewrite the object it reads, and it certainly does not permanently modify the stored object; describing it as rewriting the stored object misstates how S3 Select works entirely.

Source: AWS S3 documentation: What is S3 Object Lambda? — using a Lambda function to add custom transformation code to standard GetObject requests without duplicating data

Correct answer: .

By default, Amazon S3 does not replicate objects encrypted with SSE-KMS at all; the replication configuration must explicitly opt in by enabling the SourceSelectionCriteria element for SSE-KMS encrypted objects and must specify the destination KMS key ID that will encrypt the replicas. In a cross-account scenario, AWS documentation is explicit that the KMS key owner (Account B) must grant the source bucket owner's replication role permission to use that key, via the key's own key policy, since a bucket policy alone cannot grant access to a KMS resource owned by another account. AWS documentation further notes that a cross-account replication rule must specify a customer managed key for the destination, because AWS managed keys don't allow cross-account use and therefore cannot serve as the destination key at all. The option claiming nothing extra is required beyond versioning is wrong because KMS-encrypted objects are excluded from replication by default and require this explicit opt-in and key-policy grant on top of the baseline versioning requirement. Switching the source bucket to SSE-S3 is not a requirement and defeats the stated goal of replicating SSE-KMS-encrypted objects with a KMS key in Account B; it describes abandoning KMS entirely rather than enabling its cross-account replication. Making the destination bucket fully public is neither necessary nor sufficient: cross-account replication access is granted through a bucket policy statement authorizing the source account's role, and the KMS key policy grant described above, not through making the bucket world-readable, which would be a serious and unrelated security exposure.

Source: AWS S3 documentation: Replicating encrypted objects (SSE-S3, SSE-KMS, DSSE-KMS, SSE-C) — SourceSelectionCriteria opt-in, cross-account KMS key policy grants, and the customer-managed-key requirement for cross-account replication

Correct answer: .

S3 Storage Class Analysis is the feature designed exactly for this purpose: an administrator configures a filter, by prefix, by object tag, or both, and Storage Class Analysis observes that filtered data set's access patterns, grouping objects by age since upload, for roughly 30 days or longer before producing a reliable recommendation, specifically for transitioning STANDARD storage to STANDARD_IA once objects reach a given observed age. This is a targeted, evidence-based recommendation exactly matching the company's requirement, distinct from a guess-based lifecycle rule. S3 Storage Lens is a different, broader feature: it aggregates usage and activity metrics across an entire organization's accounts, Regions, and buckets into dashboards, but it does not analyse a specific prefix's access pattern to recommend a Standard-to-Standard-IA transition age the way Storage Class Analysis does. S3 Intelligent-Tiering does not require any prior analysis step at all; it is a storage class you assign to objects that then handles tier movement automatically based on real-time access, which is a fundamentally different mechanism from receiving a lifecycle-transition-age recommendation for objects still sitting in S3 Standard. S3 Inventory only produces a scheduled report listing objects and selected metadata fields, such as size, storage class, and encryption status; it has no access-pattern analysis capability and cannot generate any recommendation about when to transition data.

Source: AWS S3 documentation: Amazon S3 analytics – Storage Class Analysis — 30-day-or-longer observation period and STANDARD-to-STANDARD_IA transition-age recommendations

Correct answer: .

AWS documentation on restoring archived objects explains that objects in the S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive storage classes are not accessible in real time, so to read one you must restore a temporary copy of the object into the bucket for a specified number of days; unless the analyst separately copies that restored data into a new object with a different storage class, the original object itself remains stored in Deep Archive throughout and after the process, and the temporary copy is automatically removed once the specified restoration period, 10 days here, expires. The option claiming the object's storage class permanently changes to Standard is wrong because a restore operation never changes the storage class of the original archived object; the restored data is only a temporary, separate accessible copy, and a permanent class change would require an explicit copy operation. The option describing the original as permanently deleted and replaced is wrong because restoring never removes the archived original; documentation notes the requester is billed for both the ongoing archived storage and the temporary restored copy simultaneously, which would make no sense if the archived original had been deleted. The option claiming there is no temporary copy and instead direct real-time reads occur against the archived data misdescribes the entire mechanism: Glacier Deep Archive data is never read in place, which is exactly why a restore operation exists to stage a temporary, ordinarily accessible copy elsewhere in the bucket for the requested duration.

Source: AWS S3 documentation: Restoring an archived object — a temporary copy is created for a specified number of days while the original remains archived, and expires automatically

Correct answer: .

AWS's example bucket policies for controlling access from VPC endpoints use exactly this pattern: a Deny statement with a StringNotEquals condition on the aws:SourceVpce key, naming the one permitted VPC endpoint ID; because the condition evaluates true for every request whose source VPC endpoint does not equal that ID, the Deny fires for every other path in, including console requests, which do not originate from any VPC endpoint at all, and requests from clients outside the VPC entirely. AWS documentation notes explicitly that a policy shaped this way disables console access to the bucket precisely because the console doesn't route through the named endpoint, which matches the company's stated intent to block everything except that one endpoint. A Principal element identifies who is making a request (an account, user, or role); it has no mechanism for constraining which network path or VPC endpoint a request travels through, so naming the endpoint's ARN as a Principal would not achieve any routing restriction and is not even a valid use of that element. Object Lock only governs whether an object version can be deleted or overwritten during a retention period and has no concept of VPC endpoints or network-path restriction at all. A CORS rule only controls whether a browser permits cross-origin JavaScript requests based on the page's origin domain; it does not evaluate or restrict which VPC endpoint a request arrived through, and non-browser clients such as backend EC2 applications are not subject to CORS enforcement in the first place.

Source: AWS S3 documentation: Controlling access from VPC endpoints with bucket policies — example Deny policy using StringNotEquals on aws:SourceVpce to restrict access to one specific VPC endpoint

Correct answer: .

AWS documentation describes S3 Glacier Instant Retrieval as designed for long-lived, archive data that's accessed about once a quarter and requires milliseconds retrieval, with the data remaining available for real-time access at any time, which matches this scenario's rare, roughly quarterly access paired with a hard requirement for immediate, dashboard-ready responses. It carries a 90-day minimum storage duration but never requires an explicit restore step before data can be read, unlike the fully archived Glacier tiers. S3 Glacier Flexible Retrieval is explicitly documented as archived and not available for real-time access, requiring an explicit restore that completes in minutes to hours depending on the retrieval tier chosen, which would violate the millisecond compliance-dashboard requirement outright. S3 Glacier Deep Archive is even slower, designed for data accessed less than once a year with restore times measured in hours, making it entirely unsuitable when results must appear in milliseconds. S3 One Zone-IA does offer millisecond access, but it is designed for infrequently accessed data (roughly once a month) rather than the rare, quarterly access pattern described, it is not resilient to the loss of its single Availability Zone, and it costs more than Glacier Instant Retrieval for data accessed this rarely, since its pricing model targets a much higher access frequency.

Source: AWS S3 documentation: Understanding and managing Amazon S3 storage classes — S3 Glacier Instant Retrieval's quarterly-access, millisecond-retrieval design point and 90-day minimum storage duration