Practice Test #3

Incorrect. This is operationally heavy (role and inline deny policies in every account) and not centrally enforced. IAM policies cannot reliably override all possible privilege paths, and account admins/root could still grant themselves permissions unless constrained by SCPs. Also, creating vendor-admin-role in every account expands the attack surface and does not address spoofing or consistent organization-wide enforcement.

Incorrect. Permission boundaries limit only the roles/users they are attached to; they do not restrict other principals (including admins/root) and do not provide organization-wide enforcement. Creating vendor-admin-role in every account with AdministratorAccess is the opposite of least privilege and increases risk. Boundaries on developer roles do not prevent other roles from gaining Private Marketplace admin permissions.

Incorrect. It places the admin role in developer product accounts, violating the requirement that administration be restricted to vendor managers in shared services accounts. Attaching an SCP only to shared services OUs is backwards; the restriction must apply across the entire organization. It also fails to prevent spoofing and does not centrally deny other accounts from gaining Private Marketplace admin capabilities.

File Gateway correctly preserves NFSv3 access and Lifecycle can transition objects after 5 days, but S3 Standard-IA is not the most cost-effective archival choice for backups when multi-hour retrieval is acceptable. Standard-IA is designed for infrequent access with millisecond retrieval and has higher storage cost (plus minimum storage duration and retrieval fees). Given a 72-hour DR retrieval window, Deep Archive would reduce storage cost significantly.

Volume Gateway presents iSCSI block volumes, not NFS file shares, so it fails the “preserves NFS access” requirement. While transitioning to S3 Glacier Deep Archive could be cost-effective for archival, the access method is wrong for the stated workflow. Volume Gateway is better when applications require block storage semantics (e.g., iSCSI) rather than file-based NFS/SMB shares.

Tape Gateway is intended for integrating with existing backup software that writes to a virtual tape library (VTL), not for preserving NFSv3 file access. It can be cost-effective for tape-based backup workflows, but it changes the access pattern and tooling. Additionally, transitioning to S3 Standard-IA is not an archival optimization compared to Glacier Deep Archive for long-term backup retention.

AWS Control Tower with strongly recommended guardrails can improve governance posture, but this option does not directly address the requirement to detect newly created unencrypted RDS instances within 15 minutes. Strongly recommended controls are optional enhancements rather than a concrete detection workflow tied to RDS creation events. It also does nothing to remediate the existing unencrypted DB instances. Therefore, it is incomplete for the stated requirements.

This is incorrect because Amazon RDS does not support enabling storage encryption in place on an existing unencrypted DB instance. The ModifyDBInstance operation cannot convert unencrypted storage to encrypted storage after creation. This is a common exam trap because many AWS services allow in-place changes, but RDS encryption at rest is not one of them. A replacement-based migration is required instead.

AWS Control Tower with mandatory guardrails is useful for establishing a multi-account governance baseline, but it does not directly fulfill the explicit requirement to automatically detect newly created unencrypted RDS instances within 15 minutes. Mandatory guardrails focus on foundational governance and compliance controls, not necessarily near-real-time event detection for this specific RDS condition. Since the question asks for only two choices, the option that directly implements rapid detection is a better fit. As a result, D is helpful contextually but not one of the best answers.

This option requires building a full custom recommendation engine. CloudWatch Logs can show invocation behavior and memory usage details, but they do not directly provide right-sizing recommendations or estimated monthly savings, so the team would need to implement analysis logic and pricing calculations themselves. That creates significantly more development and maintenance effort than using Compute Optimizer. It also increases the risk of inaccurate recommendations compared to AWS’s managed optimization service.

This option is incorrect because Compute Optimizer does not provide a native console feature to schedule recurring biweekly CSV exports directly to S3 as described. While the console can display recommendations and support export-related workflows, recurring automation still needs an external scheduler or orchestration mechanism. Therefore, this answer claims a built-in scheduling capability that is not the right assumption for the exam. It sounds convenient, but it is not the supported least-effort implementation pattern.

Trusted Advisor is not the primary AWS service for detailed Lambda memory right-sizing recommendations with estimated monthly cost impact. Even with a Business Support plan, Trusted Advisor does not replace Compute Optimizer for this use case and does not provide the described recurring export-to-S3 workflow. It also introduces unnecessary cost and an additional service dependency. For Lambda optimization recommendations, Compute Optimizer is the more direct and purpose-built choice.

Direct Connect improves bandwidth and latency from a colocation to an AWS Region, but it does not keep workloads physically on premises or in-country for jurisdictions requiring local processing. It also cannot guarantee sub-5 ms RTT to on-prem HSMs if compute is in-Region. Finally, it does not address kiosk outages or provide local compute during disconnections; it’s primarily a connectivity solution, not a consistent hybrid runtime.

Snowball Edge Storage Optimized is mainly for data transfer and local storage with limited compute; it is not intended to host regulated, always-on cardholder-processing services with a broad set of native AWS services and consistent control-plane integration like Outposts. AWS Wavelength is designed for ultra-low latency applications on 5G networks in carrier locations, not for rural kiosks with 5–10 Mbps backhaul and frequent outages, and it doesn’t provide disconnected operation.

Local Zones extend an AWS Region closer to large metros, but they are still AWS-managed locations and may not satisfy strict “must remain in country or in our Frankfurt colocation” requirements across 12 jurisdictions, especially where no Local Zone exists. Wavelength targets 5G carrier edge and assumes reliable connectivity; it does not solve kiosk disconnections or low-bandwidth backhaul constraints, nor does it provide an on-prem consistent AWS runtime like Outposts.