Practice Test #4

GuardDuty is primarily a detective service. While it can generate findings related to S3 protection (e.g., suspicious access patterns) and you can automate remediation with Lambda, this is still reactive. There can be a time gap between a misconfiguration that makes a bucket public and the remediation action. For "never be exposed," preventive controls like S3 Block Public Access are more appropriate.

Trusted Advisor can report publicly accessible S3 buckets, but it is not a preventive control and relies on periodic checks and manual remediation. Email notifications and human intervention introduce delay and operational risk, which conflicts with strict HIPAA requirements. This option does not scale well across many buckets and does not guarantee that data is never exposed.

AWS Resource Access Manager (RAM) is for sharing resources across AWS accounts (e.g., subnets, Transit Gateways) and is not used to discover or manage public S3 bucket access. The described detection-and-remediation flow is not aligned with how RAM works. Even if implemented with other services, it would still be reactive rather than a strong preventive guardrail.

Not the best fit. AWS Backup can manage DynamoDB backups via backup plans and schedules, which reduces some effort but still typically restores to discrete backup points rather than any second in time. Meeting “any point in the last 24 hours” would require very frequent backups and still wouldn’t match PITR’s granularity. Operationally, you must manage backup plans, schedules, and retention policies.

Incorrect. Hourly on-demand backups via Lambda introduce operational overhead (Lambda code, IAM permissions, scheduling, monitoring, retries, error handling) and only provide hourly restore points, not “any point in time.” It also risks gaps if executions fail or throttling occurs. This is higher effort and lower recovery precision than DynamoDB PITR.

Incorrect for least-ops restore. DynamoDB Streams plus S3 storage can support custom replay/event sourcing, but it requires building and operating a replay mechanism, handling ordering, duplicates, schema changes, and retention. It’s complex and operationally heavy compared to PITR. Also, it’s not a native point-in-time restore feature for the table state without additional processing.

The “Amazon RDS Idle DB Instances” Trusted Advisor check is useful when databases are underutilized or unused, helping identify candidates for stopping, deleting, or downsizing. However, the question explicitly states the RDS for Oracle instances have consistent high utilization, so they are not idle. This check would be unlikely to surface meaningful savings for this workload profile.

Reviewing Trusted Advisor in each member account can technically identify RI opportunities where the RDS instances run, but it is less effective for a centralized financial planning team. It requires switching accounts and aggregating results manually. In an AWS Organizations environment, centralized review from the management account is typically the intended best practice for cross-account visibility.

Trusted Advisor “compute optimization” checks and AWS Compute Optimizer are primarily focused on compute resources like EC2 instances, Auto Scaling groups, and Lambda functions. They are not the primary tools for identifying RDS for Oracle Reserved Instance purchase opportunities. While they are valuable cost tools, they do not directly address the RDS RI optimization requirement described.

Incorrect. Amazon Inspector focuses on vulnerability management for compute (EC2 instances), container images in ECR, and Lambda functions. It does not scan S3 object contents to detect PHI/PII. Even though EventBridge + SNS is a valid alerting pattern, the underlying detection service is wrong for the requirement of identifying sensitive data inside S3 objects.

Incorrect. Macie is the right detection service, but sending findings to SQS is not the most effective way to “immediately alert the compliance team.” SQS is a queue for application processing and requires a consumer to poll and then notify humans. Also, filtering specifically on SensitiveData:S3Object/Personal may be too narrow for PHI use cases; SensitiveData findings broadly are more appropriate.

Incorrect. This option is doubly mismatched: Inspector does not detect PHI in S3 objects, and SQS is not a direct alerting mechanism for a compliance team. While you could build a workflow where a consumer reads SQS and triggers notifications, it adds unnecessary components and still fails the core requirement of scanning S3 content for sensitive data.

Amazon SageMaker JumpStart can help deploy prebuilt or foundation-model-based solutions, but it still requires selecting, deploying, and operating an inference endpoint. That introduces more complexity and operational overhead than necessary for a requirement already covered by a native managed moderation API. The question explicitly says no custom model development or training is required, which strongly favors Rekognition over SageMaker. While technically possible, this is not the most direct, lowest-latency, or most AWS-native solution for image moderation.

Amazon CloudFront Functions are extremely lightweight edge functions intended for simple HTTP request and response manipulation, not for calling AI services or performing heavy processing. They cannot directly invoke Amazon Textract, and Textract itself is designed for OCR, form extraction, and document text analysis rather than inappropriate image detection. Even if text were extracted from an image, that would not determine whether the image content itself is inappropriate or non-medical. This option is incorrect both because of service mismatch and because the execution environment is unsuitable.

Amazon Rekognition Video is intended for analyzing video files or streams, not still images uploaded through a web portal. The question specifically concerns uploaded images, so the correct Rekognition feature would be image moderation rather than video analysis. In addition, an S3-triggered Lambda runs after the object has already been uploaded, which does not inherently provide real-time blocking during the upload transaction. That makes this option a poor fit for both the media type and the timing requirement.

Incorrect. Multi-AZ is primarily for high availability and automatic failover, not for scaling reads. In standard RDS Multi-AZ, the standby cannot accept traffic, so you cannot use it for writes or reads. Directing reads to the primary and writes to the standby is not supported and would not address the read-driven CPU bottleneck causing increased latency.

Incorrect. This option assumes the standby in a Multi-AZ deployment can serve read traffic. In standard Amazon RDS Multi-AZ, the standby is not readable; it is maintained for failover only. Therefore, you cannot offload analytical reads to the standby, and the primary would remain CPU-constrained during peak trading hours.

Partially reasonable but not the best choice given "minimal infrastructure changes." Read replicas are correct, but matching the primary size (8 vCPU/32 GB) may be unnecessary and increases cost without evidence that smaller replicas won't meet the analytics workload. A better approach is to start with smaller replicas, monitor performance/lag, and scale up/out only if required.

Incorrect. NAT instances can provide outbound access, but they are self-managed EC2 instances requiring patching, scaling, and careful configuration (source/destination check disabled, security groups, failover scripts). Placing them in private subnets is also wrong because a NAT device must be able to reach the internet via an IGW, which typically requires being in a public subnet with a public IP/EIP.

Incorrect. You cannot attach an internet gateway to a subnet; an IGW attaches to a VPC. Also, routing private subnets directly to an IGW would make them effectively public (if instances have public IPs) and violates the requirement that trading application servers must not be directly accessible from the internet. A “secondary IGW” is not a valid construct for this purpose.

Incorrect. An egress-only internet gateway is used for IPv6 to allow outbound-only internet access while blocking inbound-initiated connections. It does not provide IPv4 NAT functionality, which is what most patch repositories, market data feeds, and third-party endpoints commonly use. Also, egress-only IGWs are attached to the VPC (not placed in a subnet) and do not replace NAT gateways for IPv4.

Lambda is a good compute choice for bursty workloads, but DynamoDB is not appropriate for storing video files. DynamoDB has a 400 KB item size limit and is optimized for key-value/document metadata, not large binaries. Even if videos were chunked, costs and complexity would be high and performance unpredictable. This option fails the storage requirement for large uploaded media.

Kinesis Data Firehose is designed to ingest and deliver streaming data to targets like S3, Redshift, or OpenSearch with optional lightweight transformations. It is not a general-purpose video processing service and does not run arbitrary thumbnail generation workloads. It also is not intended to store configuration metadata as a primary database. This option mismatches the workload type.

A fixed increase to five EC2 instances does not provide automatic scaling from 50 to 2000+ concurrent users; it is unlikely to meet peak demand and wastes capacity off-peak. EBS volumes are attached storage and not a scalable shared repository for uploads across instances without additional architecture. This approach increases operational burden and reduces resilience compared to managed/serverless options.

VPC peering provides private IP connectivity between two VPCs, but it is network-level access. Once routes and security rules allow it, the consumer can potentially reach many resources in the provider VPC, not just a single market data service. This fails the requirement to restrict connectivity only to the specific service and is often disallowed in regulated environments due to broader blast radius.

A virtual private gateway (VGW) is used for Site-to-Site VPN or Direct Connect, not for AWS PrivateLink. PrivateLink does not require a VGW on the provider side; it requires a VPC endpoint service backed by an NLB. This option reflects a common confusion between private connectivity mechanisms (VPN/DX) and service-level private access (PrivateLink).

A NAT gateway enables instances in private subnets to initiate outbound connections to the internet via a public IP. It does not create private connectivity to a third-party VPC service and would typically route traffic over the public internet (even if the destination is in AWS). This violates the “completely private” requirement and does not restrict access to only the specific service.