ARA-C01 Question 43
Single answerStorage integrationsA company stores raw CSV files in an Amazon S3 bucket under multiple prefixes. Snowflake will be used by several engineering teams to load data from only the s3://acme-raw-data/finance/ and s3://acme-raw-data/shared/ prefixes. The security team requires that Snowflake access be centrally managed, reusable across stages, and restricted so that no stage can reference other locations in the bucket. An architect creates an S3 storage integration and wants to ensure the design meets these requirements with the least ongoing administration. Which configuration should the architect implement?
- A
Create a storage integration with STORAGE_ALLOWED_LOCATIONS set to s3://acme-raw-data/finance/ and s3://acme-raw-data/shared/, grant USAGE on the integration to the required roles, and create external stages that reference the integration.
- B
Create external stages that point directly to the S3 URLs and embed AWS access keys in each stage definition so each team can manage its own credentials independently.
- C
Create a storage integration with STORAGE_ALLOWED_LOCATIONS set to s3://acme-raw-data/, then rely on developers to specify the correct subpath in each external stage definition.
- D
Create a storage integration with STORAGE_ALLOWED_LOCATIONS set to *, then restrict access by granting privileges only on selected stages.
- E
Create one storage integration per team, each with STORAGE_ALLOWED_LOCATIONS set to the entire bucket, because only separate integrations can prevent stages from pointing to unauthorized prefixes.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use a single S3 storage integration with STORAGE_ALLOWED_LOCATIONS explicitly limited to the approved prefixes and then create external stages that use this integration. This approach aligns with Snowflake best practices for cloud storage access: centralize trust and credential management in the integration, avoid embedding cloud credentials in stage definitions, and use allowed locations to constrain which cloud paths may be referenced. In Snowflake, storage integrations support reusable, governed access to external cloud storage for stages. The STORAGE_ALLOWED_LOCATIONS parameter is critical here because it enforces which S3 paths stages can use with that integration. Granting USAGE on the integration enables authorized roles to create or use stages based on it. This design satisfies the requirements for central management, reusability across teams, and path-level restriction with minimal ongoing administration.
- A. Correct.
Correct. A storage integration is the recommended way to centralize and manage Snowflake's access to cloud storage without embedding cloud credentials in stage definitions. By setting STORAGE_ALLOWED_LOCATIONS to only the finance and shared prefixes, Snowflake restricts stage creation and usage to those approved paths. Granting USAGE on the integration to the appropriate roles allows multiple teams to reuse the same secure configuration across stages while preventing references to other bucket locations.
- B. Incorrect.
Incorrect. Embedding AWS access keys in stage definitions is not the best practice for centralized, reusable, low-maintenance access control. Storage integrations were designed specifically to avoid distributing long-lived cloud credentials and to simplify governance. This option also increases operational overhead and credential management risk.
- C. Incorrect.
Incorrect. Allowing the entire bucket in STORAGE_ALLOWED_LOCATIONS does not meet the requirement that no stage can reference other locations in the bucket. Even if developers are instructed to use only approved subpaths, the integration itself would still permit stages to point elsewhere in the bucket, which violates the security team's requirement.
- D. Incorrect.
Incorrect. Using * for STORAGE_ALLOWED_LOCATIONS is overly broad and directly contradicts the requirement to restrict access to specific prefixes. Stage-level privileges control who can use a stage, but they do not limit the set of cloud storage locations that can be referenced by stages created with that integration.
- E. Incorrect.
Incorrect. Multiple integrations are not required to enforce prefix restrictions. A single integration can include multiple approved S3 locations in STORAGE_ALLOWED_LOCATIONS. Creating one integration per team with access to the full bucket would increase administration and still fail the requirement to prevent stages from referencing unauthorized prefixes.