S3 practice questions

Store all videos in S3 Standard for the entire 5-year retention period.

Why wrong: S3 Standard is optimized for frequently accessed data, but storing all videos in this class for 5 years would incur high costs for data that is rarely accessed after the first 30 days. This does not minimize storage costs.

Store all videos in S3 Glacier Deep Archive immediately upon upload.

Why wrong: S3 Glacier Deep Archive provides the lowest storage cost, but retrieval times range from 12 to 48 hours. This would cause unacceptable delays for the frequent access required during the first 30 days after release.

Store newly uploaded videos in S3 One Zone-IA, then transition to S3 Glacier Flexible Retrieval after 30 days.

Why wrong: S3 One Zone-IA is not suitable for archival because it stores data in a single Availability Zone and has lower durability. Additionally, S3 Glacier Flexible Retrieval is more expensive than S3 Glacier Deep Archive for long-term archival, so this option does not minimize cost as effectively.

AWS Consolidated Billing

Why wrong: Consolidated Billing combines the costs of multiple accounts into a single bill, but it does not provide a report that groups costs by custom tags across accounts. It is a prerequisite for some features but not the direct solution for this requirement.

AWS Cost Explorer with tag filtering

Why wrong: AWS Cost Explorer allows interactive visualisation and filtering of costs by tags across accounts, making it tempting for understanding project spend. However, it does not generate the *detailed billing report* required, which typically implies a programmatic data export with granular line-item data for deep financial analysis or integration. Cost Explorer provides aggregated views and forecasting capabilities suitable for ad-hoc analysis and identifying cost trends, but it lacks the comprehensive, raw line-item data file needed to fulfil the requirement for a detailed billing report.

AWS Budgets with tag-based alerts

Why wrong: AWS Budgets allows you to set cost or usage thresholds and receive alerts when costs exceed those thresholds. It can filter by tags, but it is not designed to generate a comprehensive billing report grouped by tags. Its purpose is proactive monitoring, not historical reporting.

Hardcode the IAM user access keys in the application code

Why wrong: Hardcoding IAM user access keys in application code is a severe security risk because the keys become embedded in source files, build artifacts, and version-control history. Any source-code leak, shared repository, or decompiled artifact exposes the long-term credentials, and they remain valid until manually revoked. Since these keys are long-lived, rotating them requires editing and redeploying the application, creating downtime and operational burden.

Store IAM access keys in environment variables on the EC2 instance

Why wrong: Storing IAM access keys as environment variables on the EC2 instance only moves the plaintext credentials from source code to runtime memory. Any process able to inspect the environment, such as through /proc/self/environ, process listings, debugging tools, or a compromised container, can capture them. Additionally, the keys are long-term, so they do not rotate automatically and remain at risk in AMI snapshots or user-data scripts.

Create an IAM user and configure the instance with its credentials

Why wrong: Creating a dedicated IAM user and installing its access keys on the instance introduces long-term static credentials that require manual rotation whenever they are exposed or for compliance. These keys are stored in files on the instance or in configuration, making them targets for exfiltration via local exploits or backups. If multiple instances share the IAM user, privilege separation is lost, and auditing individual workloads becomes difficult.

AWS Trusted Advisor

Why wrong: AWS Trusted Advisor inspects AWS environments and provides best practice recommendations (including S3 bucket permissions and encryption) but does not support automatic remediation of non-compliant resources.

AWS IAM Access Analyzer

Why wrong: AWS IAM Access Analyzer helps identify resources shared with external entities (e.g., S3 buckets with public or cross-account access) but does not monitor or enforce encryption settings, nor does it automatically apply corrective actions.

AWS CloudTrail

Why wrong: AWS CloudTrail records API activity for governance and audit but does not monitor resource configurations or automatically enforce compliance rules; it cannot detect or remediate non-compliant S3 bucket settings.

Amazon EC2 + Elastic Load Balancing

Why wrong: Running a static website on Amazon EC2 with Elastic Load Balancing is inefficient because you must manage and patch the underlying instances, configure scaling policies, and ensure high availability across Availability Zones. Additionally, ELB only distributes traffic to regional instances and does not provide global edge caching, so users in remote locations experience higher latency compared to content delivered from CloudFront's worldwide point-of-presence cache.

AWS Amplify only

Why wrong: AWS Amplify can host static websites and automatically provides a global CDN, but it wraps S3, CloudFront, and CodeCommit into a higher-level service focused on CI/CD pipelines. Choosing 'Amplify only' hides the underlying architecture rather than demonstrating the specific storage plus CDN combination that the question asks about. It also locks you into Amplify's build/deploy workflow, whereas S3 + CloudFront gives you direct control over caching and origin settings—making Amplify a valid but less precise answer for this fundamental architecture.

Amazon Lightsail + Route 53

Why wrong: Amazon Lightsail + Route 53 is not appropriate because Lightsail provides virtual private servers (VPS) with fixed CPU/RAM/disk, so you still handle OS maintenance and there is no built-in global CDN; it primarily offers regional DNS-based load balancing within a VPC. Route 53 only handles DNS resolution and failover, not caching or content acceleration. Together they do not give you the edge caching and automatic scaling needed for low-latency distribution to a worldwide audience, unlike S3 + CloudFront.

AWS Security Hub

Why wrong: AWS Security Hub aggregates security findings from multiple services (including AWS Config) and provides a consolidated view, but it does not directly evaluate resource configurations or automatically remediate noncompliant resources. It lacks the automated remediation and continuous evaluation capability required.

AWS IAM Access Analyzer

Why wrong: AWS IAM Access Analyzer helps identify resources in your account that are shared with an external entity, but it does not evaluate server-side encryption settings or public access configurations on S3 buckets, nor does it offer automatic remediation.

Amazon Macie

Why wrong: Amazon Macie is a fully managed data security service that uses machine learning to discover, classify, and protect sensitive data stored in Amazon S3. It does not enforce encryption or public access policies, nor does it provide automatic remediation of bucket configurations.

Amazon GuardDuty

Why wrong: Amazon GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior, using threat intelligence feeds and machine learning to generate security findings. It does not evaluate resource configurations against compliance policies, such as checking whether an S3 bucket is publicly readable, nor does it automatically apply remediation actions to non-compliant resources. GuardDuty can only alert on suspicious activity; it cannot enforce or fix configuration compliance.

AWS CloudTrail

Why wrong: AWS CloudTrail is an auditing service that records every API call made in the account, providing a detailed event history of who made what request and when. It is designed for governance and operational forensics, not for proactive compliance enforcement. CloudTrail does not inspect the configuration state of S3 buckets, compare them against policy rules, or trigger automatic fixes, so it cannot meet the requirement to enforce a compliance policy.

AWS Identity and Access Management (IAM)

Why wrong: AWS Identity and Access Management (IAM) governs authentication and authorization for principals like users, groups, and roles, managing permissions to call AWS APIs. While IAM can restrict who can change an S3 bucket policy, it does not evaluate the bucket's actual configuration, such as whether public access is enabled, and it cannot detect or automatically remediate non-compliant resources. IAM controls access to actions, not the compliance state of AWS resources.

AWS Config rule compliance reporting only

Why wrong: AWS Config rule compliance reporting alone is a passive audit function: it evaluates resources against managed or custom rules and flags non-compliant ones, but it does not alter those resources. Without an attached remediation action, any corrective step—such as enabling encryption on an S3 bucket or configuring security groups—must be performed manually by an engineer, meaning compliance gaps persist until someone intervenes.

AWS Security Hub findings export to S3

Why wrong: Exporting Security Hub findings to S3 is purely a data-delivery mechanism: it copies aggregated security findings—including those from Config rules, GuardDuty, and Inspector—into an S3 bucket for long-term storage, analysis, or integration with tools like Athena. While this enables security teams to query or visualize non-compliance trends, it does not trigger any modification to the flagged resources. The export itself neither evaluates resources nor executes corrective actions, so non-compliant configurations stay non-compliant unless another automation is separately built.

Amazon GuardDuty threat response

Why wrong: Amazon GuardDuty is a threat-detection service that uses machine learning and anomaly detection on data such as VPC Flow Logs, DNS logs, and CloudTrail events to identify malicious activity like reconnaissance or unauthorized access. It has no awareness of AWS Config rule definitions and lacks any direct capability to remediate configuration drift—for example, it cannot enable a disabled encryption setting or adjust a overly permissive IAM policy. Therefore, while GuardDuty is valuable for security incident response, it doesn't address the compliance-focused, automated remediation described in the scenario.

Amazon GuardDuty

Why wrong: Amazon GuardDuty is a threat detection service that monitors for malicious activity and unauthorized behavior. It does not evaluate resource configuration compliance against internal policies or apply automatic remediation for noncompliant S3 bucket encryption settings.

AWS CloudTrail

Why wrong: AWS CloudTrail records API activity across an AWS account for auditing, security analysis, and operational troubleshooting. While CloudTrail logs can show who created a bucket without encryption, it cannot automatically detect or remediate noncompliant bucket encryption configurations.

AWS Trusted Advisor

Why wrong: AWS Trusted Advisor inspects an AWS environment and provides best practice recommendations in categories such as cost, performance, security, and fault tolerance. It can alert users about S3 buckets with insecure configurations but does not provide automated remediation to enforce specific encryption settings.

Configure an S3 bucket policy that denies s3:GetObject requests unless the request is encrypted in transit using HTTPS.

Why wrong: This enforces HTTPS for all requests but does not prevent unauthorized decryption of objects. A user who has s3:GetObject permission via the bucket policy can still download the encrypted object, and if they have kms:Decrypt permission, they could decrypt it. This option does not address the requirement to restrict decryption.

Enable S3 Block Public Access on the bucket and attach an IAM policy to the 'Auditors' role that allows s3:GetObject.

Why wrong: Block Public Access and IAM policies control who can read the objects from S3, but they do not control who can decrypt objects encrypted with a KMS key. Any principal with s3:GetObject permission could download the encrypted object; the KMS key policy then determines if they can decrypt it. This option does not restrict decryption to only the 'Auditors' role.

Use S3 object-level logging to monitor access and revoke permissions for any role that attempts to decrypt objects without authorization.

Why wrong: This is a reactive, detective control, not a preventive one. It does not enforce that only the 'Auditors' role can decrypt objects. Unauthorized decryption could occur before revocation. The requirement is to enforce access control, not just monitor it.

AWS Batch

Why wrong: AWS Batch is designed for running large-scale batch computing jobs, not for event-driven image processing. It fails because the requirement demands automatic thumbnail creation triggered by an S3 upload, which AWS Batch cannot natively initiate without additional orchestration. It is tempting because Batch does handle serverless compute for scheduled or queued workloads, but it would be correct only for processing jobs that run on a defined schedule or when tasks are submitted to a job queue, not for real-time object creation events.

Amazon EC2

Why wrong: Amazon EC2 is incorrect because it requires you to provision and manage virtual servers that run continuously, leading to idle resource costs when no uploads are occurring. EC2 is not natively event-driven; to trigger thumbnail creation on an S3 upload you would need additional components such as Lambda or EventBridge, and you would still be responsible for patching, scaling, and maintaining the instances, contradicting the serverless, low-management requirement.

Amazon ECS with EC2 launch type

Why wrong: Amazon ECS with the EC2 launch type requires managing a cluster of EC2 instances. While it can run containers, it is not serverless and does not automatically trigger based on S3 events without additional components like Lambda or EventBridge.

AWS CloudTrail

Why wrong: AWS CloudTrail records API activity (who made what call, when, from where) but does not evaluate the actual configuration of resources against policies. It is not designed for compliance rule evaluation or a compliance dashboard.

Amazon GuardDuty

Why wrong: Amazon GuardDuty is a threat detection service that uses machine learning to identify malicious or unauthorized behavior, such as unusual API calls or compromised instances. It does not evaluate resource configurations for compliance with internal policies.

Amazon Inspector

Why wrong: Amazon Inspector is a vulnerability management service that scans workloads for software vulnerabilities and unintended network exposure. It does not evaluate resource configurations against custom compliance rules or provide a compliance dashboard for resources like S3 bucket policies or security group rules.

Amazon CloudWatch

Why wrong: Amazon CloudWatch is an operational monitoring service for collecting metrics, logs, and alarms from AWS resources and applications. It does not natively record AWS API calls; although CloudTrail can be configured to deliver management event logs to CloudWatch Logs, the event data itself originates from CloudTrail, not CloudWatch. Thus, searching CloudWatch would only reveal the logs if you had already set up that CloudTrail-to-CloudWatch integration, and the definitive caller identity and timestamp for the S3 bucket deletion still come from CloudTrail, not CloudWatch.

AWS Config

Why wrong: AWS Config records the configuration state of AWS resources over time and can show that the bucket no longer exists, but it does not capture the API event details (caller identity, IP, timestamp) the way CloudTrail does.

Amazon GuardDuty

Why wrong: Amazon GuardDuty is a machine-learning-based threat detection service, not an API audit recorder. It continuously consumes CloudTrail management events, VPC Flow Logs, and DNS logs to detect anomalies such as compromised credentials or unusual S3 access patterns. While it may flag suspicious activity related to a bucket deletion, it relies on CloudTrail's audit records as a data source and cannot serve as the authoritative queryable history of who performed the DeleteBucket call.

Consolidated Billing

Why wrong: Consolidated Billing simply aggregates invoices and cost data from all linked accounts into a single monthly bill for the management account, and it may offer volume discounts across accounts. However, it operates entirely at the financial layer and has no mechanism to evaluate, deny, or restrict any AWS API actions. It cannot enforce security baselines or prevent any configuration change; it is a billing and cost-management feature, not a security control. Therefore, it does not meet the requirement to enforce permissions across a multi-account environment.

AWS Config rules

Why wrong: AWS Config rules evaluate your resource configurations against desired policies. They can detect noncompliant resources and trigger remediation actions, but they do not prevent actions from being taken in real time. They are detective, not preventive, controls.

IAM roles

Why wrong: IAM roles grant permissions to users and services within a single AWS account. They cannot centrally restrict permissions across multiple accounts. While cross-account roles exist, they are not designed to enforce a baseline of allowed or denied actions across all accounts in an organization.

Rapid elasticity

Why wrong: Rapid elasticity is the cloud characteristic that lets customers transparently scale resources up or down to match demand, often automatically and within minutes, giving the illusion of unlimited capacity. This dynamic provisioning can move workloads across many underlying physical servers, but the movement does not itself create or enforce the logical separation of stored patient records. The isolation that prevents cross-tenant data exposure is an architectural property of resource pooling, not an outcome of elastic scaling.

On-demand self-service

Why wrong: On-demand self-service describes a customer's ability to provision and configure computing resources—such as EC2 instances or S3 buckets—through a web console or API without needing a human administrator at the provider. This characteristic addresses operational convenience and automation, but says nothing about how a multi-tenant physical infrastructure keeps one customer's sensitive patient records from being accessed by another. The isolation mechanism in question is fundamentally a resource pooling design, not a self-service provisioning feature.

Measured service

Why wrong: Measured service refers to the cloud provider metering resource consumption—such as compute hours, storage gigabytes, or network I/O—and billing customers on a pay-as-you-go basis. For metering to be accurate, the provider must track usage across shared physical hardware, but the accounting abstraction does not establish the data-plane isolation needed to keep patient records private. It is a billing and optimization feature, not a security control for separating tenant data on the same hosts.

AWS Certificate Manager (ACM)

Why wrong: ACM is used to provision, manage, and deploy SSL/TLS certificates for use with AWS services like Elastic Load Balancing and CloudFront. It does not provide encryption keys for S3 object encryption nor does it log key usage events.

AWS CloudHSM

Why wrong: AWS CloudHSM offers dedicated hardware security modules for customer-managed keys, appealing for its high security and FIPS 140-2 Level 3 compliance where exclusive control over key material is paramount. However, it fails to natively provide the detailed, tamper-proof audit logging of *key usage on specific S3 objects* that the scenario demands. While CloudHSM logs administrative actions, it does not integrate with CloudTrail to log every data encryption/decryption operation involving keys for S3 objects in the required granular detail.

AWS Secrets Manager

Why wrong: Secrets Manager is designed to manage secrets such as database credentials, API keys, and passwords. It can automatically rotate secrets, but it is not used to create encryption keys for S3 objects or to log key usage events.

Amazon S3 server-side encryption with customer-provided keys (SSE-C)

Why wrong: SSE-C lets you provide your own encryption key with each S3 PUT request, and S3 applies that key to encrypt the object and discards the key after the operation. The customer is fully responsible for generating, storing, rotating, and safeguarding those keys; AWS does not manage them. Since the company wants AWS to handle key management, SSE-C would shift that burden back to the customer and is therefore not the right choice.

AWS Certificate Manager (ACM)

Why wrong: ACM provisions and manages public and private SSL/TLS certificates used to encrypt network traffic in transit, such as HTTPS connections to CloudFront or Application Load Balancers. It does not generate or manage symmetric data encryption keys used for encrypting objects at rest in S3, and ACM certificates cannot be applied to S3 bucket encryption. Therefore, ACM would not provide any data-at-rest encryption key management for the stored customer data.

AWS Secrets Manager

Why wrong: Incorrect. AWS Secrets Manager is designed to manage secrets such as database credentials and API keys. While it can help with key rotation, it is not the primary service for managing encryption keys for data at rest in Amazon S3.

Amazon CloudFront with an origin access identity

Why wrong: Incorrect. CloudFront is a content delivery network (CDN) optimized for delivering cached content to viewers, not for accelerating uploads to an origin. It can receive uploads via methods like POST, but it is not purpose-built for S3 upload acceleration and adds complexity.

AWS Global Accelerator using a custom routing accelerator

Why wrong: Incorrect. AWS Global Accelerator improves performance for applications running behind an Application Load Balancer, Network Load Balancer, or EC2 instances over TCP/UDP. It does not integrate directly with S3 bucket uploads and cannot be configured at the S3 bucket level.

Amazon S3 cross-region replication

Why wrong: Incorrect. S3 Cross-Region Replication (CRR) automatically copies objects from one bucket to another in a different AWS Region. It is used for compliance, latency reduction for data access, or disaster recovery, not for accelerating the initial upload from clients.

Use Amazon S3 server-side encryption with customer-provided keys (SSE-C) and store the keys in AWS Secrets Manager with automatic rotation enabled.

Why wrong: SSE-C requires you to supply your own encryption keys with each request. AWS Secrets Manager can rotate secrets, but it does not directly manage S3 key material or provide integration with S3 for automatic key rotation. Additionally, SSE-C does not integrate with AWS CloudTrail for auditing key usage at the key level.

Use Amazon S3 server-side encryption with AWS managed keys (SSE-S3) and enable automatic key rotation.

Why wrong: AWS managed keys (aws/s3) are owned and managed by AWS. You do not have full control over the key material, and automatic rotation is handled by AWS but is not configurable or auditable at the customer level.

Use AWS CloudHSM to generate and store the encryption keys, and configure an AWS Lambda function to rotate the keys every year and log usage to Amazon CloudWatch Logs.

Why wrong: CloudHSM provides dedicated hardware security modules, but it does not provide built-in automatic key rotation. You would need to build custom rotation logic, and auditing key usage across many principals would require significant custom integration.

High availability

Why wrong: High availability is an architectural property that ensures a system remains operational and accessible despite component failures, often through redundancy, failover, and health checks. It is a critical design goal for production workloads in AWS, but it has no bearing on whether a developer can request a resource without waiting for IT. The policy change is about the provisioning process and user autonomy, not about uptime guarantees. Therefore, high availability is a separate concern that does not satisfy the stated requirement for on-demand access.

Elasticity

Why wrong: Elasticity is the ability to automatically scale computing resources up or down based on demand. Although AWS offers elasticity, the scenario specifically highlights the removal of manual approval for resource provisioning, which is a different characteristic.

Resource pooling

Why wrong: Resource pooling describes the provider's multi-tenant model where compute, storage, and network resources are shared across many customers and dynamically reassigned based on demand. It is a fundamental characteristic of cloud economics, but it says nothing about a user's ability to spin up resources directly. The scenario is about removing internal approval friction, not about how the provider multiplexes physical infrastructure. Thus, while resource pooling enables cost efficiency, it does not address the self-provisioning workflow the company needs.