Question 640
An application team wants managed Kubernetes on AWS, but its current workload includes a privileged node-level security agent delivered as a DaemonSet and a CSI driver requiring specific host access. The team plans to run every pod on EKS Fargate and assumes this will work unchanged. Which architectural decision is most appropriate?
- Use Amazon EKS with suitably managed EC2 node groups for workloads requiring unsupported privileged or DaemonSet host functions, and use Fargate only for compatible pods.
- Move the privileged DaemonSet to a Fargate profile without converting it to an eligible sidecar, and keep its node-host access assumptions.
- Run the CSI driver as an ordinary Fargate Pod and assume all host-mounted storage operations are supported unchanged.
- Use S3 website hosting as the Kubernetes node runtime for privileged daemon processes.
Explanation
Correct Answer
A:EKS managed node groups provide host-level capabilities required by some privileged DaemonSets and CSI agents; Fargate profiles can still host compatible workloads, with the deployment split planned explicitly.
Incorrect Answers
B:EKS Fargate does not support DaemonSets or privileged pods, so a profile does not satisfy host-agent requirements.
C:Fargate host access and CSI/daemon compatibility must be reviewed; not all node-level drivers work on managed Fargate compute.
D:A static website service cannot run Kubernetes node agents or a privileged CSI driver.
Question 641
A Linux geospatial application is being rehosted from a proprietary NFS appliance. It needs managed shared NFS storage with advanced snapshot/clone workflows and high read throughput from multiple EC2 hosts, while Windows SMB semantics are not required. Which AWS storage platform should the team investigate?
- Use Amazon FSx for OpenZFS with an appropriately sized supported configuration and test its NFS and snapshot semantics against the workload.
- Use EFS without verifying the ZFS-style volume-clone semantics needed by the application and assume every NFS service supports identical snapshot clone capabilities.
- Use S3 Glacier Deep Archive as an NFS server with immediate POSIX random I/O without restoring any objects.
- Select FSx for Windows File Server because an SMB/Windows ACL workflow is required by this Linux NFS application.
Explanation
Correct Answer
A:FSx for OpenZFS provides managed NFS file access with OpenZFS-oriented snapshot and clone features suitable for the stated Unix file workload after compatibility validation.
Incorrect Answers
B:EFS provides shared NFS semantics but not the same FSx for OpenZFS snapshot/volume-clone workflow requested.
C:Glacier Deep Archive is archival object storage rather than an interactive NFS filesystem.
D:Windows File Server emphasizes SMB rather than the required NFS protocol and ZFS clone/rollback functions.
Question 642
A research institute already migrated its HPC simulations onto Amazon FSx for Lustre linked to an S3 data repository. Each simulation uses a known list of large input files. At the beginning of the run, the first access to those S3-backed files triggers import latency that violates the tight calculation start-time objective. How should the team prepare the existing file system before compute launches?
- Increase Lustre file system throughput without fetching specified S3-backed file contents before first access.
- Move the underlying objects to Glacier Deep Archive immediately before each run and expect filesystem reads to be instantaneous.
- Issue supported lfs hsm_restore requests for the required files, verify restore completion, and then begin latency-sensitive simulation reads.
- Create an additional empty FSx for Lustre file system for every simulation and assume it preloads the required S3 objects.
Explanation
Correct Answer
C:FSx for Lustre supports HSM preloading from the linked data repository so planned simulation input sets can be staged before time-critical reads.
Incorrect Answers
A:More throughput does not eliminate cold data repository import delay when the required file contents are not yet present.
B:Glacier archive classes require restoration and are not direct low-latency data repository sources for Lustre HSM fetch operations.
D:An empty or newly created file system does not proactively import the known input files without an HSM restore/preload action.
Question 643
Three ECS services mount an existing regional EFS filesystem. All services need the same underlying filesystem, but each must see only its assigned directory and use an enforced POSIX user and group identity so one service cannot accidentally write another service’s data. What EFS construct should be configured per application?
- Create EFS access points with application-specific root directories and enforced POSIX identities, and restrict mounts to the intended access point with the appropriate IAM and filesystem permissions.
- Create an IAM access policy for the entire EFS file system but mount through its generic root path, expecting IAM alone to change Linux POSIX UID/GID and directory root.
- Add another EFS mount target in the same AZ and assume its ENI imposes a different POSIX user and restricted file-tree root.
- Use a general S3 bucket lifecycle policy and assume it scopes the POSIX root directory visible through EFS NFS mounts.
Explanation
Correct Answer
A:An EFS access point can enforce a root directory and POSIX identity for clients connecting through it; IAM and directory permissions make this a supported per-service boundary.
Incorrect Answers
B:IAM can constrain client mount/use operations, but access points provide enforced root directory and POSIX identity per application.
C:EFS mount targets provide network access to a file system and do not by themselves establish per-application POSIX identity or directory boundaries.
D:S3 object lifecycle does not configure access control for an EFS NFS mount or create an application-specific filesystem root.
Question 644
A finance application runs an Aurora PostgreSQL production cluster with a supported engine version. The database team needs to test an engine upgrade and parameter changes against a synchronized staging environment before a controlled production switchover with minimal downtime. The task is not to change the cluster’s day-to-day capacity mode. Which managed workflow fits?
- Create an Aurora read replica from the production cluster and perform an in-place production engine upgrade, assuming the replica is the full managed blue/green deployment and rollback workflow.
- Use Aurora Blue/Green Deployments, test the green environment with ongoing synchronization, and perform a controlled switchover once compatibility checks pass.
- Restore a manual Aurora snapshot to a stand-alone green-like cluster but do not synchronize subsequent writer changes before the production switchover.
- Modify the production engine version in place immediately and treat connection failures during the upgrade as the rollback mechanism.
Explanation
Correct Answer
B:Aurora Blue/Green Deployments creates a synced green environment for supported updates and allows a tested controlled switchover.
Incorrect Answers
A:An ordinary read replica is not equivalent to a managed blue/green environment with coordinated upgrade testing and production switchover.
C:A disconnected snapshot can help static testing, but without continued synchronization it cannot provide the required low-downtime controlled cutover.
D:An untested in-place upgrade increases failure risk and is not the requested separate synchronized verification procedure.
Question 645
A document-processing service is being modernized from database polling to S3 event-triggered execution. Raw images arrive at `incoming/` in one S3 bucket, and the Lambda worker writes resized images into `processed/` in that same bucket. A first test triggered an unbounded cycle when the worker processed its own output. What event architecture should be implemented?
- Subscribe the Lambda processor to every ObjectCreated event in the bucket, then increase its reserved concurrency until the output-triggered recursion subsides.
- Configure a supported S3 ObjectCreated notification filtered to `incoming/` and the required source-file suffixes, write output to a disjoint `processed/` prefix, and make the handler idempotent for potentially repeated events.
- Keep a one-minute EventBridge schedule that scans every object in the bucket instead of filtering S3 ObjectCreated notifications to the raw-input keyspace.
- Create two overlapping S3 notification rules for all object prefixes and the `incoming/` prefix with the same event type, assuming S3 will automatically prioritize only the narrower rule.
Explanation
Correct Answer
B:S3 event rules can filter on object-key prefixes and suffixes. Targeting only the input keyspace prevents processed outputs from retriggering the same worker; idempotency also addresses repeated delivery. This is an event filtering and loop-safety design decision, not the original another practice scenario decision merely to choose Lambda.
Incorrect Answers
A:Increasing concurrency can amplify the recursion and costs; event delivery from both raw and derived objects remains in scope. Concurrency limits are a backstop, not a replacement for disjoint input/output event routing.
C:Scheduled listing would reintroduce unnecessary polling and requires custom logic to distinguish new raw inputs from generated outputs. It does not directly fix the mis-scoped S3 creation notification causing recursive invocations.
D:Overlapping notification prefixes for the same event type are disallowed or lead to ambiguous routing; they are not a supported precedence mechanism. Use valid nonoverlapping notification filters instead.
Question 646
A retail profile application already uses a DynamoDB global table in Multi-Region eventual-consistency mode. During regional network partitions, users modify the same loyalty-balance item in two Regions and later observe lost updates. The application cannot change global-table consistency mode in place. Which redesign most directly prevents this class of concurrent-write conflict while retaining regional reads?
- Increase the global table's read capacity in both Regions and assume larger capacity changes last-writer-wins reconciliation into an atomic merge.
- Add a global secondary index on the loyalty-balance attribute and assume indexing makes independent regional writes globally serializable.
- Route all updates for a given loyalty account to one authoritative writer Region or ownership partition, with idempotent commands and recovery procedures, while using replicas for reads consistent with the application's staleness tolerance.
- Wrap each Region's updates in a local DynamoDB TransactWriteItems call and assume the two independent regional transactions now serialize globally without writer ownership.
Explanation
Correct Answer
C:MREC replicas asynchronously exchange writes and concurrent updates can converge by last-writer-wins. Assigning each account a controlled write owner prevents competing Region writers for the same record; idempotency and explicit failover ownership preserve application semantics. This tests conflict avoidance, unlike another practice scenario's generic service selection.
Incorrect Answers
A:Additional throughput can reduce throttling but does not alter the cross-Region conflict-resolution semantics of MREC replicas. Concurrent changes to one item can still race and the eventual result is not a balance-preserving merge.
B:A GSI creates alternate query access paths, not a cross-Region transaction coordinator. It cannot guarantee serial ordering of two independent writes to the same item through replicas.
D:DynamoDB transactions guarantee atomicity within their supported local scope, not a globally ordered two-Region transaction for MREC replicas. Concurrent writes to the same logical item can still conflict under asynchronous replication.
Question 647
A migrated order-worker fleet already consumes a correctly configured Amazon SQS standard queue with retry and a dead-letter queue. Most hours have almost no messages, but 120 workers make `ReceiveMessage` requests every second with `WaitTimeSeconds=0`, generating thousands of empty responses. The application tolerates up to a 20-second wait for work. What is the most direct polling optimization?
- Enable SQS long polling, using a suitable nonzero `ReceiveMessage` wait time up to 20 seconds and an HTTP client timeout longer than the receive wait, while retaining the existing visibility and redrive policies.
- Convert every SQS message to a FIFO message group even though ordering is not required, because FIFO alone removes empty response polling without changing the receive wait time.
- Raise message retention from four days to fourteen days and keep one-second zero-wait polling, because retention alone reduces the count of empty API responses.
- Set MaxNumberOfMessages to 10 but keep `WaitTimeSeconds=0` and the same one-second polling loop, assuming batching automatically waits until messages arrive.
Explanation
Correct Answer
A:With a nonzero wait time, SQS can wait for messages before returning, reducing empty and false-empty responses; a suitable client timeout prevents premature HTTP errors. The queue's delivery and failure policies remain intact. This optimizes polling behavior rather than duplicating another practice scenario's queue-service selection.
Incorrect Answers
B:FIFO queues can provide per-group ordering and deduplication semantics but do not automatically turn a zero-wait receive call into long polling. Adding ordering would change application semantics without addressing the defined API pattern.
C:Retention controls how long unprocessed messages remain available, not the behavior of an empty `ReceiveMessage` call. Extending it cannot remove high-frequency empty polling and may increase data retention cost.
D:MaxNumberOfMessages controls the upper bound of messages returned per receive, not whether an empty queue waits for new messages. The zero-wait calls can still return immediately and consume excessive receive requests.
Question 648
A retailer has already moved its immutable product images into S3 behind a healthy CloudFront distribution. Marketing now deploys new images several times a day under the SAME file names, and users behind corporate proxies sometimes keep seeing stale files even after CloudFront invalidations. The team wants reliable release-by-release visual versions and fast rollback. What content-versioning approach should be adopted?
- Keep reusing the same object keys and lower only CloudFront's TTL, assuming this instantly removes copies held by browsers and corporate caching proxies.
- Route the same image URLs through AWS Global Accelerator instead of CloudFront, assuming anycast routing invalidates browser and corporate proxy copies of prior assets.
- Publish each immutable revision under a distinct versioned or content-hashed object name and update references in the page manifest, retaining prior versions for rollback and using invalidation selectively for urgent removals.
- Increase S3 object's version ID without changing its viewer URL and assume every intermediate browser cache will automatically request the new version ID.
Explanation
Correct Answer
C:Versioned file names make each asset release addressable independently of intervening caches. Updating references selects the desired release without depending on every proxy honoring an edge invalidation, and retaining prior keys provides a rollback path; this differs from simply choosing CloudFront for global delivery.
Incorrect Answers
A:Lowering the edge TTL only affects how CloudFront validates its own cache. Client and corporate proxy caches may still retain the old name and bytes, so this does not reliably select a particular release image.
B:Global Accelerator optimizes network entry and endpoint routing, not HTTP object versioning or cache invalidation for viewer proxies. The retained URL still has ambiguous old-versus-new cached content.
D:An S3 internal version ID is not automatically part of the CloudFront viewer URL for ordinary object retrieval. Reusing the unchanged URL does not establish deterministic browser-visible release version selection.
Question 649
A bank will move two databases in the same migration wave. The second database uses the first for foreign-key reference data and must not start writing until the first is consistent. The team proposes independent cutovers without coordination. What should change?
- Define a dependency-aware cutover order with consistency checks and application write controls across both databases.
- Complete the dependent database cutover first while the referenced database is still mid-copy, and rely on connection retries to repair foreign-key consistency.
- Increase S3 lifecycle transition frequency and assume it synchronizes relational foreign keys between target engines.
- Use independent migration tasks with no shared application write fence, consistency checkpoint, or dependency order for the two transactional databases.
Explanation
Correct Answer
A:Cross-database references require compatible migration checkpoints and ordered promotion rather than unrelated independent cutovers.
Incorrect Answers
B:Connection retries cannot ensure a dependent database sees a consistent prerequisite set before it begins writing.
C:Object storage lifecycle operations do not coordinate database constraints or writes.
D:Independent task completion does not establish cross-database transaction dependencies or a coordinated cutover point.
Question 650
A migrated Java application needs a managed broker supporting existing RabbitMQ AMQP client behavior and queues. The product team cannot rewrite protocol-level acknowledgments before the first cloud release. What AWS managed service should be evaluated?
- Replace RabbitMQ with SQS standard queues without changing AMQP acknowledgment, routing or transaction semantics in the existing Java clients.
- Use Amazon MQ for RabbitMQ with an approved deployment topology and preserve application broker protocol settings.
- Replace RabbitMQ with Amazon SQS without modifying existing AMQP connection and acknowledgment code.
- Use Amazon MSK without converting the existing RabbitMQ producers and consumers from AMQP to Kafka protocol semantics.
Explanation
Correct Answer
B:Amazon MQ offers managed support for compatible RabbitMQ broker behavior, reducing reimplementation during migration.
Incorrect Answers
A:SQS is a different queue API and acknowledgment model; an unmodified RabbitMQ AMQP client cannot directly use it as an AMQP broker.
C:SQS has different APIs and message semantics; an unmodified AMQP client cannot connect to it directly.
D:MSK is a managed Kafka service rather than a drop-in RabbitMQ protocol broker.
AWS Certified Solutions Architect - Professional SAP-C02 Practice Tests