1. Explain the difference between S3 Standard and S3 Intelligent-Tiering storage classes and when you would use each in a production environment.

S3 Standard offers low-latency, high-throughput access with no retrieval fees, ideal for frequently accessed data and hot workloads. S3 Intelligent-Tiering automatically moves objects between access tiers (Frequent, Infrequent, Archive, Deep Archive) based on access patterns, reducing costs by ~70% for unpredictable workloads without performance impact. Use Standard for databases, web content, and real-time analytics; use Intelligent-Tiering for data lakes, logs, and backups with variable access patterns to optimize cost without manual intervention.

2. You're on-call and receive an alert that an application is experiencing intermittent 503 errors when uploading files to S3. The error logs show 'SlowDown' exceptions. What are three potential causes and how would you diagnose each?

First, check if the application is hitting S3 request rate limits (3,500 PUT/COPY/POST/DELETE per second per prefix); use CloudWatch metrics to see if RequestCount spikes correlate with errors. Second, verify the bucket key naming pattern—if all uploads use a similar prefix (e.g., 'uploads/2024-01-15/...'), they're throttled to the same partition; use randomized prefixes like 'uploads/{uuid}/{timestamp}/...' to distribute load. Third, examine network configuration: ensure the application uses S3 Transfer Acceleration if needed, check for NAT gateway bandwidth limits, and verify the application implements exponential backoff retry logic (AWS SDK defaults to this). Run `aws s3api head-bucket --bucket my-bucket` to confirm connectivity and `aws cloudwatch get-metric-statistics --namespace AWS/S3 --metric-name 4xxErrors` to quantify the issue.

3. What is S3 bucket versioning and what are the operational implications for cost and disaster recovery?

Bucket versioning maintains multiple versions of each object, allowing you to recover from accidental deletions or overwrites; each version is stored and billed separately. Cost implications: storage grows significantly as old versions accumulate (e.g., a 1GB file updated daily for a year costs 365GB of storage), so implement lifecycle policies to transition old versions to Glacier or delete them. Disaster recovery benefits include point-in-time recovery and protection against ransomware, but requires careful lifecycle management; pair versioning with MFA Delete on the bucket to prevent accidental permanent removal via `aws s3api put-bucket-versioning --bucket my-bucket --versioning-configuration Status=Enabled,MFADelete=Enabled`.

4. Design an S3-based log aggregation solution for 50 EC2 instances writing 100GB/day of logs. What architectural decisions would you make regarding bucket structure, lifecycle policies, and querying?

Use a partitioned prefix structure like `s3://logs-bucket/{app-name}/{region}/{instance-id}/{year}/{month}/{day}/{hour}/` to enable efficient querying and respect S3's 3,500 requests/second per prefix limit. Implement a lifecycle policy: transition to Standard-IA after 30 days, Glacier after 90 days, and expire after 2 years; this reduces storage costs by 80-90%. For querying, use S3 Select or Amazon Athena with Parquet-formatted logs partitioned by date, avoiding full bucket scans; configure CloudWatch Logs agent to batch writes and compress logs before upload. Monitor with CloudWatch metrics on `NumberOfObjects` and `BucketSizeBytes` to catch runaway log growth early.

5. Explain S3 Cross-Region Replication (CRR) and when you would use it instead of S3 Transfer Acceleration or CloudFront.

CRR asynchronously replicates objects to a destination bucket in another region, providing disaster recovery and compliance (e.g., data residency requirements). Use CRR when you need read-write failover capabilities, durability redundancy across regions, or regulatory compliance that mandates copies in specific regions; CRR also replicates metadata and delete markers. Use Transfer Acceleration or CloudFront instead if you only need faster uploads to a single region or low-latency reads from a fixed origin, as they're cheaper and simpler than maintaining dual buckets. Note: CRR incurs costs for replication requests and cross-region data transfer; it also requires versioning enabled on both source and destination buckets.

6. A developer reports that their application is unable to upload files larger than 5GB to S3. What is the issue and how would you fix it?

The developer is likely using the single `PutObject` API call, which has a 5GB maximum object size limit. The fix is to implement multipart upload via `aws s3 cp large-file.iso s3://bucket/key --metadata key=value` (AWS CLI handles multipart automatically) or use the SDK's `upload_file()` method, which parallelizes uploads and has a default threshold of 8MB before switching to multipart. For files larger than 160GB, multipart upload remains the only solution; configure the upload with `Threads=10` and `MultipartThreshold=8388608` in boto3 to optimize throughput. Verify the fix with: `aws s3api list-multipart-uploads --bucket my-bucket` to monitor in-progress uploads and ensure proper cleanup of failed parts via lifecycle policies.

7. You need to grant temporary, read-only access to a specific S3 prefix for an external contractor. Compare three approaches: IAM user, presigned URLs, and bucket policy. What are the pros and cons?

IAM user approach: creates permanent credentials, simplest to manage long-term, but violates least-privilege (contractor retains access after engagement ends unless manually revoked). Presigned URLs: temporary (configurable expiry, max 7 days), no IAM user required, ideal for one-off downloads, but only supports object-level access and URLs are shareable (security risk if leaked). Bucket policy: applies to all users/roles matching conditions, doesn't expire, good for programmatic access, but difficult to revoke quickly and creates permanent backdoors. For contractors: use presigned URLs with short expiry (1-24 hours) for downloads, or create a temporary IAM user with a 30-day credential rotation tied to a policy like `{"Effect":"Allow","Action":"s3:GetObject","Resource":"arn:aws:s3:::bucket/prefix/*"}` with an inline deny policy to auto-expire.

8. What is S3 Object Lock and how would you use it to meet compliance requirements? Describe a scenario where it would be essential.

S3 Object Lock prevents objects from being overwritten or deleted for a specified retention period (Compliance or Governance mode), ensuring immutability for regulatory compliance. Compliance mode is WORM (Write Once Read Many) and cannot be bypassed even by the AWS account owner, ideal for FINRA, SEC, or HIPAA audits; Governance mode allows privileged users to override retention with explicit `s3:BypassGovernanceRetention` permission. Example: a financial institution storing transaction logs must retain records for 7 years for SEC compliance; enable Object Lock with Compliance mode and 7-year retention, ensuring logs cannot be accidentally or maliciously deleted. Cost trade-off: Object Lock adds per-request overhead and prevents lifecycle transitions; pair it with lifecycle policies to transition to Glacier after retention expires to optimize storage costs.

9. You're debugging high S3 API costs. CloudWatch shows 10 million ListBucket requests/month but the application only needs to sync 1000 objects. How would you optimize this and what's the cost difference?

The application is likely performing repeated `ListBucket` or `ListBucketVersions` calls to check for new objects; each call costs $0.005 per 1,000 requests, so 10M calls = $50/month. Replace with S3 Event Notifications to SNS or SQS (minimal cost), triggering Lambda to process only new/changed objects, eliminating polling entirely. Alternatively, use S3 Inventory reports (daily snapshots, ~$0.10/million objects) or S3 Batch Operations for scheduled syncs instead of real-time polling. If polling is unavoidable, implement client-side caching with ETag/LastModified checks and use `--query 'Contents[?LastModified>=`2024-01-01`]'` to filter results, reducing requests by 99%. Expected cost reduction: from $50/month (polling) to <$1/month (event-driven), plus reduced latency and improved reliability.

10. Explain S3 bucket encryption options (SSE-S3, SSE-KMS, SSE-C) and when you would choose each. What are the performance and cost implications?

SSE-S3 (AES-256): AWS-managed keys, free, automatic encryption, no key management overhead; use for non-sensitive data or when compliance doesn't require key control. SSE-KMS: uses AWS KMS for key management, enables key rotation and audit logging via CloudTrail, costs $1/month per key + $0.03 per 10k API calls; use for sensitive data, regulated workloads, or when you need fine-grained access control and key policies. SSE-C: client-managed keys, you provide the key with each request, no AWS cost but adds client-side key management burden; use for highly sensitive data where you cannot trust AWS with key custody. Performance: SSE-S3 is fastest (no external calls), SSE-KMS adds ~5-10ms latency per request due to KMS API calls, SSE-C adds latency from key management. For most production workloads, SSE-KMS balances security, compliance, and cost; use `aws s3api put-object --bucket mybucket --key mykey --server-side-encryption aws:kms --sse-kms-key-id arn:aws:kms:...`.

11. You're migrating a 500TB dataset from on-premises to S3. Data transfer costs are your primary concern. Compare AWS DataSync, AWS Snowball, and S3 Transfer Acceleration. What would you recommend and why?

DataSync: $0.0125 per GB processed (~$6,250 for 500TB), ideal for 10-100TB transfers over direct connect/VPN with automatic data validation; slower but most cost-effective for ongoing syncs. Snowball Edge: fixed cost (~$300 per device, 100TB capacity = 5 devices = $1,500 total), fastest for large one-time migrations, includes data transfer; best for 500TB+ with offline shipping requirements. Transfer Acceleration: $0.04 per GB (~$20,000 for 500TB), only faster than standard S3 for lossy networks, not cost-effective for this scenario. Recommendation: use Snowball Edge for initial bulk transfer ($1,500), then DataSync for incremental syncs post-migration ($0.0125/GB monthly). Calculate: Snowball ($1,500) + 1 month DataSync for delta syncs ($625) = $2,125 vs. DataSync alone ($6,250) or Transfer Acceleration ($20,000). Snowball also eliminates egress costs and import time constraints.

12. A production bucket is receiving 'AccessDenied' errors from EC2 instances that previously had working access. How would you diagnose the root cause and fix it?

First, verify the IAM role attached to the EC2 instance has the necessary S3 permissions; check CloudTrail for the exact API call and denied action via `aws cloudtrail lookup-events --lookup-attributes AttributeKey=ResourceName,AttributeValue=my-bucket`. Second, confirm the bucket policy isn't blocking the principal; run `aws s3api get-bucket-policy --bucket my-bucket` and look for explicit Deny statements or missing Principal conditions. Third, check for resource-based policies like bucket ACLs, block public access settings (`aws s3api get-public-access-block --bucket my-bucket`), or S3 Object Lambda rules. Fix: attach the appropriate policy like `{"Effect":"Allow","Action":["s3:GetObject","s3:PutObject"],"Resource":"arn:aws:s3:::bucket/*"}` to the IAM role, or update the bucket policy to include the instance role ARN. Finally, test with `aws s3 ls s3://my-bucket --no-sign-request` (if public) or with explicit role credentials to confirm access is restored.

13. You're on-call and discover that S3 requests from your Lambda functions are failing with 'InvalidBucketName' errors, but the bucket name in your code hasn't changed. The bucket was recently migrated between AWS accounts. What steps would you take to diagnose and resolve this?

First, verify the bucket exists in the current account using `aws s3 ls` and confirm the IAM role attached to Lambda has the correct permissions via `aws iam get-role-policy`. Check if the bucket's resource-based policy or object ACLs are blocking cross-account access—this is common after migrations. Confirm the region in your Lambda code matches the bucket's actual region using `aws s3api get-bucket-location --bucket <name>`. Finally, add a bucket policy explicitly allowing the Lambda's execution role to access objects: `{"Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::ACCOUNT:role/lambda-role"}, "Action": "s3:*", "Resource": ["arn:aws:s3:::bucket/*", "arn:aws:s3:::bucket"]}`.

14. Your team uploads daily backups to S3 using a scheduled Lambda. Recently, the bucket reached 10TB and costs doubled. Investigation shows 2TB of old backups from 6+ months ago are still in Standard storage. Design a solution that automatically transitions old objects to cheaper storage without manual intervention.

Implement an S3 Lifecycle Policy that transitions objects to Glacier Flexible Retrieval after 90 days and Deep Archive after 1 year, reducing costs by ~80%. Use a policy like: `{"Transitions": [{"Days": 90, "StorageClass": "GLACIER_IR"}, {"Days": 365, "StorageClass": "DEEP_ARCHIVE"}]}`. Add expiration rules to delete backups after 3 years if not needed. Tag backups with creation date at upload time using Lambda metadata to enable more granular lifecycle rules if needed. Monitor costs weekly in Cost Explorer filtered by storage class to validate savings.

15. A compliance audit requires that all objects in your S3 bucket have immutable retention for 90 days and cannot be deleted during that period, even by administrators. How would you implement this and what are the operational trade-offs?

Enable S3 Object Lock with Compliance mode on the bucket using `aws s3api put-object-lock-configuration --bucket <name> --object-lock-configuration 'ObjectLockEnabled=Enabled,Rule={DefaultRetention={Mode=COMPLIANCE,Days=90}}'`. Compliance mode prevents any deletion or modification before the retention period expires, including by the root AWS account, ensuring audit compliance. Trade-offs include inability to quickly purge accidentally uploaded sensitive data, inability to recover storage space until retention expires, and the 1-second minimum latency increase. Implement careful CI/CD controls to prevent uploading wrong objects since they're locked.

16. Your application uses S3 Select to query JSON logs stored in S3. After deploying to production, you notice S3 Select costs are 5x higher than expected, but no new features were added. What could cause this and how would you optimize?

S3 Select is charged per object scanned, not per bytes returned; your application may be scanning entire large objects when it only needs a subset. Enable CloudTrail and query `eventName=SelectObjectContent` to see object sizes being scanned. Optimize by re-partitioning logs into smaller files (e.g., hourly instead of daily), using object prefixes to filter before S3 Select runs, or switching to Athena if you're doing complex aggregations across many objects. Add filtering in the S3 Select SQL itself: `SELECT * FROM s3object WHERE timestamp > 1000` to reduce scanned bytes. Consider whether logs should be stored in Parquet format instead of JSON for better compression and column-based access.

17. You're migrating a multi-region application from EBS-backed storage to S3. One region experiences 1000 requests/second with 10ms p99 latency requirement. Standard S3 can handle the throughput but you're concerned about request rate limits. What's the best approach?

Standard S3 allows 3500 PUT/COPY/POST/DELETE and 5500 GET/HEAD requests per second per partition key. Distribute requests across multiple partitions by using a prefix sharding strategy: instead of `logs/app-name/`, use `logs/{UUID}/app-name/` to spread load across 100+ partitions. Verify with CloudWatch metrics `AllRequests` and `UserErrors` (HTTP 503 responses indicate partition limits). For read-heavy workloads, place CloudFront in front to cache frequently accessed objects, reducing origin requests by 70-90%. Enable S3 Transfer Acceleration if clients are geographically distributed. Monitor with `RequestMetrics` to catch partition hot spots early.

18. Your organization stores sensitive customer data in S3 encrypted with KMS. The KMS key policy recently was audited and found to have overly permissive grants that were created months ago for a departed team member. How would you identify unused grants and safely revoke them?

Use `aws kms list-grants --key-id <key-arn>` to list all grants and their creation dates. Query CloudTrail for `GrantId` in events over the last 90 days using Athena to identify which grants are actively used. For each unused grant, revoke with `aws kms retire-grant --grant-id <id>` (if you have the grant token) or `aws kms revoke-grant --key-id <key-arn> --grant-id <id>`. Test revocation in non-prod first by removing one grant and confirming S3 object decryption still works for active applications. Document all removed grants in a change ticket and correlate with team departure dates. Set up automated reports monthly to catch future permission drift.

19. A developer tries to upload a 15GB file to S3 via the AWS CLI but the transfer fails halfway with a checksum error. What's the underlying issue and how would you fix it?

The AWS CLI defaults to multipart upload for files >100MB, splitting them into 8MB parts. Network failures or filesystem changes during upload cause checksum mismatches on reassembly. Fix by enabling resume capability: `aws s3 cp large-file.bin s3://bucket/ --sse AES256` with `--storage-class STANDARD_IA` to force a fresh upload, or use `aws s3 sync` which automatically retries failed parts. For future uploads, increase multipart chunk size with `--metadata 'custom-key=value'` or use AWS DataSync for reliability on large transfers. Verify file integrity post-upload using `aws s3api head-object --bucket <bucket> --key <key>` to check ETag matches local MD5.

20. Your company hosts a static website in S3 with CloudFront. Users report that cache invalidation requests are taking 2-3 minutes to propagate globally. A colleague suggests removing the CloudFront distribution and serving directly from S3 to reduce latency. What factors would you consider before making this trade-off?

Removing CloudFront means losing DDoS protection (AWS Shield Standard only), caching benefits, compression, and geographic distribution—S3 alone would experience 200ms+ latency from distant regions vs. 50ms via CloudFront edge. Cache invalidation latency is a separate issue; create a new CloudFront distribution version or use `aws cloudfront create-invalidation` with path patterns instead of wildcards to reduce propagation time. Instead, optimize current setup: enable S3 Transfer Acceleration ($0.04/GB) for origin fetches, set longer cache TTLs (86400s) for static assets, and implement versioned URLs to avoid invalidation. If invalidation latency is critical for live content, restructure to serve dynamic content via API Gateway + Lambda rather than invalidating S3 objects.

21. You inherit a bucket with 100 million objects. Auditing reveals 40% lack proper tags for cost allocation and compliance tracking. Manually tagging is infeasible. How would you automate this retroactively and prevent future untagged uploads?

Use S3 Batch Operations to tag existing objects at scale: create a manifest with S3 inventory, generate a JSON list of `{Tagging: {TagSet: [{Key: 'Environment', Value: 'prod'}]}}`, and submit a batch job using `aws s3control create-job`. This processes millions of objects in hours for ~$0.50 per million objects. Prevent future uploads using S3 Object Lambda to intercept PUT requests and inject tags before storage, or configure a bucket policy denying `s3:PutObject` without the `aws:PrincipalTag` condition. Use an EventBridge rule triggering a Lambda on `PutObject` events missing tags to tag retroactively within minutes. Monitor with S3 Inventory reports filtered by missing tags monthly.

22. Your CI/CD pipeline uploads build artifacts to S3 daily. Recently, developers accidentally committed credentials in artifact logs. Now you need to redact sensitive data from already-uploaded objects without re-uploading 500GB of artifacts. Is this possible and what's your approach?

S3 does not support in-place object modification; you must download, modify, and re-upload. Instead, use S3 Batch Operations with a Lambda function to process each object: download, redact sensitive patterns using regex, and re-upload with same key, keeping original versioning for audit. Enable MFA Delete on the bucket to prevent accidental purging. For future prevention, scan artifacts locally before upload using `grep -r 'AWS_SECRET' .` in CI/CD, reject builds with secrets, and use `aws secretsmanager` for credential injection instead of embedding in logs. Set up an EventBridge + Lambda to scan each uploaded object for credential patterns (regex for `AKIA[0-9A-Z]{16}`) and quarantine suspicious files to a separate bucket.

23. You're designing a disaster recovery solution where a primary bucket in us-east-1 must be replicated to us-west-2. The RTO is 4 hours and RPO is 1 hour. Compare S3 Cross-Region Replication (CRR) versus periodic snapshots with S3 Batch Replication. What would you recommend?

CRR provides ~15-minute RPO with near real-time replication and meets your 1-hour RPO easily, but costs $0.02/1000 requests plus replication fees; it's ideal for continuous sync. Batch Replication via S3 Sync scheduled hourly would miss up to 1 hour of writes but costs 80% less. For your requirements, use CRR for automatic failover meeting RPO/RTO, but disable replication of non-critical objects (logs, temp files) using replication rules with `Filter` to reduce costs. Add a Lambda-triggered on replication failures to alert ops. For 4-hour RTO, implement read-replica failover in application code: if us-east-1 is down, switch to us-west-2 using Route53 health checks. Test failover quarterly.

24. A data science team wants to run Spark jobs on 2TB of Parquet files stored in S3. Their job scans the entire dataset repeatedly, taking 3 hours per run. CloudWatch shows 600,000 s3:GetObject calls per run. What's causing the slowdown and how would you optimize?

Spark is reading metadata by calling GetObject on each small Parquet partition file repeatedly instead of leveraging columnar pruning; 2TB with 10KB average partition metadata = millions of round-trip requests. Optimize by: (1) coalescing small files into larger partitions (100MB+) using `coalesce()` to reduce GetObject calls by 90%, (2) enabling S3 SELECT within Spark to push column filtering to S3, reducing bytes transferred by 70%, (3) using S3 Intelligent-Tiering to cache frequently accessed metadata. Use S3 Batch Operations to repartition existing data: `aws s3api batch create-partitions` or use AWS Glue to optimize Parquet layout. Cache the dataset in EMR's HDFS for repeated jobs to eliminate S3 calls entirely. Monitor with S3 Storage Lens to identify inefficient access patterns.

25. Your application uploads files to S3 using multipart upload, but you notice that incomplete uploads are accumulating in the bucket and consuming storage costs. How would you identify these incomplete uploads and implement a solution to clean them up automatically?

Incomplete multipart uploads can be identified by calling the ListMultipartUploads API or viewing them in the S3 console under the Bucket > Management tab. To clean them up automatically, configure an S3 Lifecycle policy with the AbortIncompleteMultipartUpload action set to a reasonable threshold, such as 7 days, which will automatically terminate uploads that haven't completed within that window. You can also manually abort specific uploads using the AbortMultipartUpload API. This prevents orphaned parts from accumulating and reduces storage costs, since incomplete uploads still incur charges for the stored parts.

26. You're implementing an S3-based data lake where different teams need access to their respective prefixes, but your current approach using individual IAM policies has become unmaintainable with dozens of teams. What alternative approach would you use and what are the trade-offs?

Instead of individual IAM policies per team, implement attribute-based access control using IAM policy variables combined with a consistent naming convention, such as s3:::data-lake/team-${aws:username}/* for each team's prefix. Alternatively, use an S3 Access Grants configuration where you centrally define which principals can access which prefixes, decoupling access management from IAM policy maintenance. The Access Grants approach is more scalable for large organizations but requires additional setup and has a small per-request cost. Both approaches reduce policy sprawl, enable self-service access provisioning, and simplify auditing compared to managing dozens of custom policies.

27. You're storing time-series data in S3 using a partition scheme of s3:::bucket/year/month/day/hour/data.parquet. After six months, query performance against recent data has degraded significantly even though you're using the same query patterns. What might be causing this and how would you diagnose it?

This is likely caused by S3 request rate limits on the partition prefix where recent data is being written. As data accumulates, requests to the current day/hour prefix are hitting the 3,500 PUT/COPY/POST/DELETE requests per second limit on that specific key prefix, causing throttling. Diagnose this by checking CloudWatch metrics for 4xx HTTP 503 SlowDown errors or by examining S3 request metrics filtered by prefix. Resolve this by randomizing the key name prefix for recent writes using a hash or UUID component, then consolidating objects into the final partition structure during off-peak hours, or by distributing writes across multiple prefixes based on a sharding strategy.

28. Your organization requires that all S3 objects be encrypted, but you want to avoid managing encryption keys yourself. Compare SSE-S3 and SSE-KMS in terms of compliance requirements, audit capabilities, and operational overhead.

SSE-S3 uses AWS-managed encryption keys and provides automatic encryption with minimal operational overhead, but offers limited audit visibility since encryption is transparent and you cannot track key usage per object. SSE-KMS allows you to use either AWS-managed or customer-managed KMS keys, provides detailed CloudTrail logs showing who accessed the key and when, and enables key rotation policies, making it essential for compliance frameworks like HIPAA, PCI-DSS, or SOC 2. The trade-off is that SSE-KMS incurs per-request KMS API charges and adds slight latency, whereas SSE-S3 has no additional cost. For compliance-heavy environments, SSE-KMS is the standard choice despite the operational complexity.

29. You're configuring S3 bucket policies to allow cross-account EC2 instances to read objects, but the policy references an IAM role ARN. After deployment, the instances still receive AccessDenied errors even though the bucket policy appears correct. What's the likely issue?

The bucket policy likely references only the role ARN in the Principal field, but it's missing the assume-role session name component. Cross-account access via an IAM role requires the Principal to be in the format arn:aws:iam::ACCOUNT-ID:role/ROLE-NAME, but the actual requests come from the session created by assuming that role, which includes the session name. Additionally, the role's trust relationship must explicitly allow the EC2 service to assume it, and the inline role policy must also grant s3:GetObject permissions. Verify both the bucket policy and the role's trust policy, then test with the aws sts assume-role command to ensure the role can be assumed before validating bucket access.

30. Your team uses S3 events to trigger Lambda functions whenever files are uploaded to a specific prefix. After a data migration, you notice Lambda is being invoked thousands of times per second and your Lambda concurrency is exhausted. What are two potential causes and how would you fix each?

First cause: the S3 event notification filter prefix is too broad or missing, so every object upload in the bucket triggers Lambda, not just the intended prefix. Fix this by adding or refining the Prefix filter in the S3 event notification configuration to target only the specific prefix, such as events-filter-prefix: uploads/new/. Second cause: your migration tool uploaded many objects in a short time, creating a burst of event notifications that overwhelmed the Lambda concurrency limit. Fix this by temporarily increasing the reserved concurrency for that Lambda function, or by implementing exponential backoff and retry logic. Additionally, consider using SQS as an intermediate queue between S3 events and Lambda to smooth out the burst load.

31. You're implementing a solution where external users download files from S3 via presigned URLs. Your security team requires that URLs expire after 1 hour and only work from specific IP addresses. How would you implement the IP restriction?

IP restrictions cannot be enforced directly in presigned URLs because they are based on signature calculations that occur at URL generation time, not at request time. Instead, implement IP restrictions at a higher layer using CloudFront with Origin Shield and AWS WAF attached to a CloudFront distribution that sits in front of S3, or use VPC endpoints with security group rules if downloads occur from within your VPC. Alternatively, use S3 bucket policies combined with IP-based conditions, but this applies to all requests, not just presigned URLs. For the most secure approach, generate presigned URLs with a 1-hour expiration and a custom Lambda authorizer or API Gateway that validates the client IP before redirecting to S3, though this adds complexity and latency.

32. Your S3 bucket has versioning enabled and Object Lock configured for compliance mode with a 90-day retention period. A developer accidentally uploads a malformed configuration file that propagates through your system. Can you delete the current version immediately, or roll back to a previous version?

In compliance mode, you cannot delete or overwrite any version of an object during the retention period, including the current version, even with root account permissions. Your only option is to upload a new corrected version after waiting for the retention period to expire, or to contact AWS Support to request an exception, which they rarely grant. To roll back, you must use the version ID of the previous known-good version to download it, then upload it as a new current version without deleting the malformed version. For this reason, compliance mode is recommended only for immutable audit logs; if you need operational flexibility during incidents, use governance mode instead, which allows you to temporarily bypass retention with special permissions.

33. Your Lambda function uses boto3 to upload 1MB files to S3 at a rate of 100 uploads per second. CloudWatch shows that S3 API call costs are higher than expected. What optimization would you implement and why?

The issue is likely that each small file upload is making individual PutObject API calls, and at 100 requests per second to a single prefix, you're approaching per-prefix rate limits. Implement S3 Transfer Acceleration or use multipart upload with larger chunk sizes if applicable, but the most cost-effective solution is to batch objects into larger files using S3 Batch Operations or by buffering objects locally and uploading them as a single tar.gz or parquet file, reducing the number of API calls by 1-2 orders of magnitude. Additionally, randomize the key name prefix using a hash of the object key to distribute requests across multiple prefixes and avoid rate limiting. These changes reduce API call costs proportionally while improving throughput and reducing Lambda execution time.

34. You're using S3 Inventory reports to analyze object metadata across a 100TB bucket. The Inventory report is generated daily and shows object size, storage class, and last-modified date. However, you notice the report size is 50GB and takes 4 hours to query using Athena. How would you optimize this?

S3 Inventory reports are stored in Parquet or ORC format and should query efficiently in Athena, but 4 hours suggests either querying uncompressed data or scanning the entire report without partitioning. Optimize by enabling Parquet formatting if not already enabled, partitioning the Inventory destination by bucket, prefix, and date in the Inventory configuration, and querying only the relevant partitions using Athena partition pruning. Additionally, use columnar projection to select only the columns you need (size, storage-class, last-modified) rather than scanning all metadata. Consider using Amazon S3 Storage Lens for higher-level metrics and cost analysis instead of Inventory reports for real-time dashboards, reserving detailed Inventory queries for specific compliance or cost audits.

35. Your application synchronizes files between on-premises storage and S3 using the AWS CLI with the s3 sync command. The sync job takes 8 hours for a 5TB dataset and generates thousands of ListBucket API calls. What's the root cause and how would you optimize it?

The s3 sync command compares every object in the source and destination by calling ListBucket on both sides, which is expensive for large datasets and slow because it's single-threaded by default. Optimize by using AWS DataSync instead, which provides optimized protocols for fast transfers, concurrent processing, and intelligent change detection without excessive API calls. If you must use the CLI, increase parallelism using the max-concurrent-requests and max-bandwidth parameters, and use the exclude and include filters to reduce the scope of files being synced. Additionally, if you know which files have changed, use a manifest file or database to drive the sync instead of relying on list operations. For 5TB datasets, DataSync typically completes in 1-2 hours compared to 8 hours with the CLI and reduces API costs significantly.

36. You're running a machine learning pipeline that reads training data from S3, trains a model, and writes results back to S3. The pipeline runs in parallel with 50 concurrent workers, but you're experiencing occasional 503 SlowDown errors. Your monitoring shows that requests are distributed across multiple prefixes, but errors still occur. What's the underlying cause and how would you diagnose it?

Even though requests are distributed across prefixes, if they all converge on the same bucket, you may be hitting the overall bucket-level limit or experiencing request bursts that exceed the limit momentarily. Diagnose this by enabling S3 request metrics in CloudWatch to see the distribution of requests across object key names and checking if there's a hotspot in writes to a specific prefix like the results directory. Additionally, check CloudTrail logs for 503 SlowDown errors with timestamps to correlate with pipeline execution patterns. Resolve this by sharding write operations across multiple result prefixes using a hash of the worker ID, or by buffering writes to a local file system and batch-uploading results after training completes. If the issue persists, use S3 Intelligent-Tiering or consider splitting the workload across multiple buckets.