Free DEA-C01 practice test

AWS DMS offers three LOB (Large Object) handling modes: Limited LOB mode (truncates LOBs above a set size), Full LOB mode (replicates complete LOBs regardless of size, at lower performance), and Inline LOB mode. When BLOBs up to 500 MB are failing, switching to Full LOB mode ensures the entire LOB is fetched and replicated without truncation. Option C (larger instance) may help with memory pressure but does not address the root cause — LOB replication mode configuration. Option B (Limit LOB mode at 600 MB) sounds correct but Limited LOB mode still reads LOB data inline up to the limit and can cause memory issues with very large BLOBs — Full LOB mode uses a different, more robust fetch strategy for large objects. Option A (excluding BLOBs) avoids the problem but results in incomplete data replication.

Adding more DPUs gives Spark more executor cores and memory, so each shuffle partition is processed faster and less data is spilled to disk. Pre-partitioning the DataFrame by the groupBy key using .repartition() co-locates records with the same key on the same executor, reducing the amount of data that must cross the network during the shuffle.

Option E (job bookmarks) only tracks already-processed data to avoid reprocessing; it has no effect on shuffle performance.

Option C (.coalesce(1)) reduces parallelism to a single partition, which serializes all work onto one executor and would dramatically increase runtime.

Option B (caching) helps when the DataFrame is reused multiple times in the DAG, but does not reduce shuffle data volume for a single aggregation pass.

Option A (CSV output) has no effect on shuffle overhead during the transformation phase.

Amazon Kinesis Data Firehose natively supports dynamic Parquet/ORC format conversion using a schema defined in the AWS Glue Data Catalog — no separate conversion job is required. It writes directly to S3 and the Glue Data Catalog table is already available for Athena, minimizing operational overhead. Option B works but is more complex: it requires three separate components (DMS, crawler, Glue job) and adds latency between landing and Parquet availability. Option A involves custom Lambda code to handle JDBC queries and Parquet serialization, which increases operational burden and is error-prone. Option C (MSK Connect) is a valid Kafka-based approach but involves deploying and managing MSK Connect workers, which is higher operational overhead than Firehose for a simple 15-minute micro-batch case. Option D: AWS Glue DataBrew is primarily a data preparation and profiling tool; it supports scheduled runs but is not designed as a recurring ingestion pipeline and lacks a native JDBC source for streaming/micro-batch ingest.

Option C (Glue ETL jobs for CSV-to-Parquet conversion) is correct because Glue natively supports reading CSV and writing Parquet, and the job can be updated to accommodate new columns during schema evolution without touching existing files. Option D (Kinesis Data Firehose with Parquet conversion) is correct for streaming ingestion scenarios, as Firehose can convert records to Parquet on the fly using the Glue Data Catalog as the schema source, which handles schema evolution by referencing the latest catalog definition. Option E is partially relevant but describes a crawler setting, not a conversion mechanism — it does not convert CSV to Parquet. Option A is incorrect because Athena uses schema-on-read for querying but cannot convert file formats; reading CSV as Parquet is not possible via SerDe. Option B (Glue DataBrew) can convert formats, but it is primarily a visual data preparation tool designed for data quality and profiling, not a scalable, pipeline-oriented format conversion solution.

AWS Glue DataBrew supports custom formula transformations using regex and string functions. Using a regex to extract only numeric digits (e.g., extracting '[0-9]+') from values like '25 years' and '30yrs' is the correct approach to standardize the column. Option A is wrong — 'Format date' applies to date/time columns, not age strings. Option D is incorrect — casting to INTEGER in DataBrew does not automatically strip non-numeric text; it would fail or produce null values for strings like '25 years'. Option B ('Nest column') is for combining multiple columns into a struct, which is irrelevant here.

To run a scheduled DataBrew transformation, you need: (1) A DataBrew dataset that defines the source data (the S3 location and file format), and (2) A DataBrew recipe job that references the recipe containing the masking/standardization steps and specifies the output S3 prefix. A schedule can be attached directly to the recipe job — it is not a separate standalone resource that must be created independently; schedules are configured as part of the job definition. A ruleset is used for data quality checks/validation, not for transformation. A DataBrew project with an interactive session is used for building and testing recipes, not for automated scheduled execution. Therefore options A and C are the correct required resources.

An EventBridge rule supports up to five targets per rule (and more with additional configuration). Adding both the SQS queue and the Lambda function as targets on the same rule delivers matching events to both destinations in parallel — this is the simplest and most direct solution. Option A works functionally (two rules with the same pattern both fire) but is less clean and doubles maintenance overhead with no added benefit. Option B (SNS fanout) is a valid pattern but adds an unnecessary SNS layer when EventBridge natively supports multiple targets. Option C (EventBridge Pipes) is designed for point-to-point integrations with enrichment steps — Pipes do not natively fan out to multiple independent targets simultaneously.

Options A and D are correct. Applying KEY distribution on the large orders fact table using the customer_id join column co-locates matching rows from both tables on the same slice, eliminating network shuffling during joins. Applying ALL distribution on the small customers dimension table (500,000 rows) broadcasts a full copy to every slice, ensuring that the join can always be resolved locally. This KEY+ALL pattern is the standard Redshift best practice for large fact-to-small-dimension joins. Option E is wrong because applying ALL distribution to a 2-billion-row fact table would be extremely slow to maintain and consume enormous storage on every node. Option B is wrong because EVEN distribution spreads rows randomly, which does not co-locate join keys and does not eliminate shuffling. Option C is wrong because distributing customers on order_id makes no logical sense—customers do not have order_ids as a natural key—and would not co-locate the join.

Option C is correct. Short-Query Acceleration (SQA) is a Redshift WLM feature specifically designed for this scenario. When enabled, Redshift uses machine learning to predict query execution time and automatically routes short-running queries (below the configured maximum SQA run time) to a dedicated SQA queue that runs ahead of user-defined WLM queues. Setting the maximum SQA run time to 5 seconds ensures that dashboard queries meeting the SLA threshold are promoted ahead of long ETL jobs without requiring manual queue assignment or user group configuration, making it the most targeted and operationally simple solution. Option A is wrong because Concurrency Scaling adds transient cluster capacity for read queries experiencing high concurrency, but it does not prioritize short queries over long ones — dashboard queries would still queue behind ETL jobs within the main cluster before being routed to a scaling cluster, and the delay may persist. Option B is wrong in comparison to C because it requires manual operational overhead (user group or query group assignments, ongoing tuning of concurrency limits) and introduces risk of misconfiguration; SQA achieves the same outcome automatically and is the AWS-recommended approach for mixed short/long workloads. Option D is wrong because scaling out the cluster adds capacity but does not change the scheduling priority; short queries will still queue behind ETL jobs in the same WLM queue, failing the dashboard SLA. Option E is wrong because increasing concurrency to 50 in a single queue degrades per-query performance due to resource contention (Redshift recommends keeping total WLM concurrency low), and a query timeout only terminates queries rather than prioritizing short ones.

Automatic WLM with priority settings is the recommended modern approach in Redshift. By assigning higher priority to ETL queries and lower priority to dashboard queries, Redshift automatically manages concurrency and memory allocation so ETL queries are no longer starved behind long-running dashboard queries. Option A (adding more nodes) increases overall throughput but does not address queue prioritization; ETL queries will still queue behind dashboard queries. Option D (manual WLM) was the legacy approach and can work, but it requires careful, manual slot and memory tuning. More importantly, the question asks for the 'most appropriate' solution, and AWS guidance recommends automatic WLM over manual WLM for new configurations. Option B (Redshift Serverless) is a valid architectural pattern but involves migrating workloads to a separate environment, which is a significant operational change and not the intended WLM solution.

Lake Formation tag-based access control (LF-TBAC) lets administrators assign LF-tags (key-value labels) to databases, tables, or columns, then grant permissions on those tags to principals. When a new PII table is tagged, the existing permission grants automatically apply — no new per-table policies are needed. This scales elegantly. Option B (governed tables) provides row-level filtering and ACID transactions but is not specifically designed for column-level RBAC scalability via tags. Option A (S3 bucket policies) operate at the S3 object/prefix level and cannot enforce column-level restrictions; they also bypass the unified Lake Formation permissions model. Option D (Glue resource-based policies) control access to the Data Catalog API but do not provide fine-grained column-level data access control and do not scale as new tables are added.

Compacting small files (Option E) dramatically reduces the overhead of opening and reading many individual S3 objects; Redshift Spectrum parallelizes across files, and large files allow efficient stripe-level Parquet reads. Partitioning (Option B) allows Spectrum to skip entire S3 prefixes based on query predicates, reducing the amount of data scanned. Together, these are the two highest-impact changes. Option F is incorrect — external tables in the Glue Data Catalog do not support sort keys; sort keys are a Redshift internal table concept and do not apply to S3-backed external tables. Option C (result caching) only helps if the exact same query is repeated; it does not speed up new or varied ad-hoc queries. Option D (converting to CSV) is counterproductive — Parquet is columnar and compressed, which is far superior to CSV for Spectrum; converting to CSV would make performance worse. Option A (scaling the cluster) adds more concurrency but Spectrum performance bottlenecks on S3 file size and metadata overhead, not Redshift node count.

Correct: Manual WLM with separate queues — one for short interactive analyst queries (with a query execution time limit and higher slot allocation) and one for long BI queries — is the canonical solution. Assigning higher priority or more slots to the analyst queue prevents BI queries from blocking them. Wrong answers: (B) Short Query Acceleration (SQA) is a separate feature designed to auto-route short queries, not a WLM timeout parameter; also, routing BI long-running queries to the default queue doesn't help isolation. (C) Concurrency Scaling adds burst capacity for concurrency spikes but does not isolate or prioritize specific query types within the same queue. (A) Adding nodes increases overall throughput but does not resolve the queue starvation problem; long queries will still consume all available slots.

Correct: (A) EMR Managed Scaling continuously monitors YARN metrics and automatically adds or removes instances within the configured min/max bounds, handling variable workloads without manual intervention. (B) Using an instance fleet for Task nodes with multiple Spot instance types increases the likelihood of obtaining capacity at low cost during scale-out events and reduces interruption risk through diversification. Wrong answers: (C) Configuring EC2 Auto Scaling independently from EMR can conflict with EMR's own scaling logic and does not integrate with YARN resource manager metrics — EMR managed scaling is the supported approach. (D) A fixed configuration sized for the nightly peak wastes significant compute cost during low-utilization morning hours, which is exactly what auto-scaling is designed to avoid. (E) Using CloudWatch alarms with Systems Manager to run CLI commands is a fragile, high-maintenance custom solution that duplicates EMR's built-in managed scaling capability.

Correct: AWS Glue crawlers support an incremental crawl mode ('Crawl new sub-folders only') that restricts the crawler to paths added since the last run. This dramatically reduces the S3 paths the crawler must evaluate, cutting execution time for tables with few new partitions. Wrong answers: (B) Glue crawlers use a fixed internal compute model; DPU allocation does not apply to crawlers the same way it does to ETL jobs — crawlers do not expose a DPU tuning knob that would speed them up for small incremental changes. (A) Running more frequently reduces partitions per run but increases total crawler invocations and does not reduce per-run cost if the crawler still re-evaluates existing paths. (D) MSCK REPAIR TABLE discovers partitions by scanning S3 prefixes; it can work for simple cases but doesn't provide the managed scheduling, schema inference, or Data Catalog integration that crawlers provide, and it is a lateral move rather than an optimization.

Low CPU utilization (18%) combined with frequent GC pauses indicates the job is over-provisioned with workers but each worker is processing too much data per task (large partitions causing high memory pressure). Enabling Glue auto-scaling (B) allows the service to dynamically allocate only the DPUs needed, reducing cost when utilization is low. Converting data to Parquet with Snappy compression (A) reduces I/O and data deserialization overhead, directly cutting job duration and the amount of memory needed per task, which also reduces GC pressure. Option C is incorrect because switching to G.2X adds more memory per worker but CPU utilization is already low at 18%; more memory alone does not address the parallelism imbalance and increases cost. Option E is incorrect because adding more workers when CPU utilization is already only 18% will not help—the bottleneck is not compute parallelism but data volume and memory pressure; adding workers increases cost without proportional benefit. Option D could improve utilization but repartitioning alone does not address the GC pressure caused by large data volume per executor, and reducing workers without addressing the format wastes the opportunity for cost and performance gains.

Amazon Redshift dynamic data masking (DDM) allows a masking policy to be attached to a column for specific roles, returning a masked value (e.g., NULL, a fixed value, or a partial value) in query results while keeping the underlying data unchanged. This allows aggregate queries (SUM, AVG) on the salary column to function correctly from a system perspective while hiding individual values—though note that with NULL masking, aggregates on that column would also return NULL/skewed results for that role, which satisfies 'never see individual values.' Option C (REVOKE SELECT on salary column) would prevent any query referencing the salary column, including aggregates, which is too restrictive. Option A (RLS filtering rows where salary IS NOT NULL) would remove virtually all rows from results, not just mask the column value. Option D (Lake Formation) applies to the Glue Data Catalog and Athena/EMR access paths, not natively to Redshift queries.

S3 Object Lock in Compliance mode enforces a WORM (Write Once Read Many) retention period that cannot be shortened or removed by any user — including the AWS account root user and AWS Support. This is specifically designed to meet regulations like SEC Rule 17a-4 that require tamper-proof retention.

Option B (Governance mode) also prevents most users from deleting objects during the retention period, but privileged IAM users with the s3:BypassGovernanceRetention permission CAN override it — making it not truly tamper-proof and therefore insufficient for strict regulatory compliance.

Option D (Versioning + Lifecycle to Glacier) does preserve object versions and moves them to cheaper storage, but it does not prevent deletion of versions by an authorized user or root — it is not a WORM mechanism.

Option C (bucket policy Deny) can be effective in many cases, but an S3 bucket policy can be modified or deleted by the account root user, so it is not truly tamper-proof against root access.

Tokenization replaces sensitive values with surrogate tokens stored in a token vault. The same PAN always maps to the same token (referential consistency), and the original PAN is never stored in the pipeline or dataset. This satisfies PCI-DSS requirements for protecting PANs. Option D (static masking) replaces PANs with a fixed string, losing referential integrity and preventing any analytics that require consistent identifiers. Option A (hashing) is deterministic and consistent but SHA-256 of PANs is vulnerable to rainbow table attacks given the limited PAN space, and PCI-DSS does not consider hashing alone sufficient protection. Option C (encryption) stores ciphertext but the data can be decrypted if the key is compromised; PCI-DSS scope is not fully reduced for encrypted PANs in the same way as tokenization.

Option A (EMR security configuration with SSE-KMS/CMK for EMRFS) configures the Spark job to encrypt all data written to S3 with the specified CMK at the EMR level — ensuring the job uses the correct key.

Option B (S3 bucket policy denying PutObject without the specific CMK) is a server-side enforcement mechanism that rejects any write that does not use the designated CMK, providing a hard guardrail even if the EMR configuration is bypassed. Together, A and B cover both the 'configure the job' and 'enforce at the storage layer' requirements.

Option C (S3 default bucket encryption) encrypts objects when no encryption header is provided, but it does NOT prevent a caller from using a different CMK or SSE-S3 — it only acts as a default fallback, so it does not enforce exclusive use of the specific CMK.

Option D (IAM policy condition) could theoretically restrict KMS key usage but would need to be on the role used by the Spark job, not the EC2 instance profile broadly, and is complex to implement correctly across multiple KMS operations; also it does not stop writes that use SSE-S3 entirely.

Option E (Amazon Macie) is a detective control for PII/sensitive data classification in S3, not an encryption enforcement mechanism.