A Data Engineer is working on a Snowflake deployment in AWS eu-west-1 (Ireland). The Engineer is planning to load data from staged files into target tables using the COPY INTO command. Which sources a

Question

Options

• AInternal stage on GCP us-central1 (Iowa)
• BInternal stage on AWS eu-central-1 (Frankfurt)
• CExternal stage on GCP us-central1 (Iowa)
• DExternal stage in an Amazon S3 bucket on AWS eu-west-1 (Ireland)
• EExternal stage in an Amazon S3 bucket on AWS eu-central-1 (Frankfurt)
• FSSD attached to an Amazon EC2 instance on AWS eu-west-1 (Ireland)

• A
  6% (2)
• B
  3% (1)
• C
  88% (28)
• F
  3% (1)

Explanation

Options C, D, and E are correct because Snowflake's COPY INTO command supports external stages pointing to any cloud storage location - including cross-cloud (GCS from an AWS-hosted account) and cross-region (S3 in Frankfurt from a deployment in Ireland) - making C, D, and E all valid data sources.

Why the distractors fail:

• A & B (Internal stages): Internal stages are bound to your Snowflake account's own cloud/region storage. An account on AWS eu-west-1 cannot reference an internal stage on GCP or a different AWS region - those internal stages would belong to entirely different accounts.
• F (EC2 SSD): COPY INTO only loads from staged files (internal or external stages). A raw disk attached to an EC2 instance is not a Snowflake stage and cannot be referenced directly.

Memory tip: Think "External = Everywhere, Internal = Inside my account." External stages are flexible across clouds and regions; internal stages are locked to your account. And COPY INTO always needs a stage - bare compute storage (like an EC2 disk) never qualifies.

No community discussion yet for this question.