Study guide
5.2 Managed Reader Accounts for External Consumers
SnowPro Advanced: Architect ARA-C01
Track your progress as you read
Finished sections get a check mark.
1 Introduction: The ARA-C01 Exam
About the SnowPro Advanced: Architect (ARA-C01) Exam
2 Chapter 1: Account Strategy & Organization Architecture
1.1 Multi-Account Strategy & Snowflake Organizations 1.2 Snowflake Parameter Hierarchy & Configuration 1.3 Database and Schema Design Architecture
3 Chapter 2: Identity, Access Control & Storage Integrations
2.1 Role-Based Access Control Architecture & Hierarchy 2.2 Secondary Roles, Object Ownership & Delegated Administration 2.3 Cloud Storage Integrations & IAM Trust Policies 2.4 Identity Federation, SSO, SCIM & Authentication Policies
4 Chapter 3: Governance, Data Privacy, Network Security & Compliance
3.1 Column-Level Masking & Row Access Policies 3.2 Object Tagging, Tag-Based Masking & Audit Governance 3.3 Encryption, Key Management & Tri-Secret Secure 3.4 Aggregation Policies, Projection Policies & External Tokenization 3.5 Network Policies, Network Rules, External Access & Private Connectivity 3.6 Snowflake Editions & Compliance Architecture (PCI DSS, PII & PHI)
5 Chapter 4: Data Modeling in Snowflake
4.1 Dimensional Modeling: Star vs. Snowflake Schemas 4.2 Data Vault 2.0 Architecture in Snowflake 4.3 Relational Constraints & Query Optimizer Integration
6 Chapter 5: Data Sharing & Collaboration Solutions
5.1 Direct Data Sharing Architecture & Security 5.2 Managed Reader Accounts for External Consumers 5.3 Snowflake Marketplace, Data Exchange & Clean Rooms
7 Chapter 6: Multi-Cloud, Multi-Region & Business Continuity
6.1 Database & Account Replication Mechanics 6.2 Disaster Recovery Architecture & Client Redirect 6.3 Cross-Cloud Auto-Fulfillment & Listing Replication 6.4 Data Protection: Time Travel, Fail-safe & Storage Costs
8 Chapter 7: Environments, Lakehouse, DevOps & AI/ML Applications
7.1 Multi-Tier Environment Strategy & Zero-Copy Cloning 7.2 Data Lakehouse Architecture & Apache Iceberg 7.3 DataOps, CI/CD & Snowflake Git Integration 7.4 AI/ML Pipelines & Applications: Cortex AI, ML Functions, Snowpark Container Services, Streamlit & Native Apps
9 Chapter 8: Data Ingestion Architecture
8.1 Bulk Ingestion Architecture: COPY INTO Optimization 8.2 Snowpipe Continuous Automated Ingestion 8.3 Snowpipe Streaming & Real-Time Ingestion 8.4 Data Unloading Architecture & Cloud Export Patterns 8.5 Schema Detection, Schema Evolution & Source-Change Architecture
10 Chapter 9: Continuous Pipelines & Stream Transformation
9.1 Change Data Capture (CDC) with Snowflake Streams 9.2 Task Orchestration, DAGs & Serverless Scheduling 9.3 Declarative Data Pipelines with Dynamic Tables 9.4 Views, Materialized Views & Transformation Table Design
11 Chapter 10: Semi-Structured Data & Ecosystem Tooling
10.1 Semi-Structured Data: VARIANT, OBJECT & ARRAY Processing 10.2 Snowflake Ecosystem Connectors, Drivers & SQL API 10.3 Snowpark, User-Defined Functions & Stored Procedures
12 Chapter 11: Virtual Warehouse Architecture & Concurrency
11.1 Virtual Warehouse Architecture, Sizing & Credit Economics 11.2 Multi-Cluster Warehouses & Concurrency Scaling Policies 11.3 Warehouse Types & Query Acceleration Service
13 Chapter 12: Query Profiling & Performance Diagnostics
12.1 Query Profile Deep-Dive & Bottleneck Analysis 12.2 Memory Spilling, Warehouse Queuing & Timeout Governance 12.3 Three-Tier Caching Architecture & Result Reuse
14 Chapter 13: Storage Optimization, Cost Governance & Observability
13.1 Micro-Partitioning & Automatic Clustering 13.2 Search Optimization Service (SOS) & Point Lookup Acceleration 13.3 Resource Monitors, Financial Governance & Usage Observability 13.4 Warehouse Monitoring, Alerts, Event Tables & Performance Explorer
5.2 Managed Reader Accounts for External Consumers
Key Takeaways Explain This Topic AI
Managed Reader Accounts provide secure, live Snowflake access to external consumers who do not possess an existing Snowflake account or contractual relationship.
The data provider bears 100% financial liability for all virtual warehouse compute credits consumed inside reader accounts; reader accounts receive zero invoices from Snowflake.
The provider controls reader spend by creating resource monitors inside the reader account (for the account or specific warehouses); without them, reader warehouses can consume unlimited credits billed to the provider.
Reader accounts can query and even create objects such as materialized views, but cannot upload or modify data (INSERT, UPDATE, DELETE, MERGE, COPY INTO <table> ) or run CREATE STAGE, CREATE PIPE, or CREATE SHARE.
Reader accounts are created with CREATE MANAGED ACCOUNT ... TYPE = READER by ACCOUNTADMIN or a role with the CREATE ACCOUNT privilege; a provider can create 20 reader accounts by default and can consume data only from that provider.
Last updated: September 2026
5.2 Managed Reader Accounts for External Consumers
While Snowflake Direct Data Sharing provides seamless data exchange between existing Snowflake accounts, enterprise data providers frequently need to share live datasets with external partners, suppliers, B2B clients, or regulatory agencies that do not have a Snowflake account .
Historically, organizations addressed this by building custom REST APIs, maintaining SFTP file dump pipelines, or licensing expensive third-party web portals. Snowflake eliminates these anti-patterns through Managed Reader Accounts (also known simply as Reader Accounts ). A Reader Account is a specialized, dedicated Snowflake account provisioned, managed, and financially sponsored by the data provider for the sole purpose of consuming shared data.
Reader Account Architecture & Provisioning Lifecycle
A reader account is created directly by the provider account and exists as a first-class tenant within Snowflake. However, unlike standard accounts, reader accounts have no independent billing relationship with Snowflake. ┌────────────────────────────────────────────────────────────────────────┐
- │ PROVIDER ACCOUNT │
- │ │
- │ ┌─────────────────────┐ ┌──────────────────────────┐ │
- │ │ ACCOUNTADMIN │──────────────►│ CREATE MANAGED ACCOUNT │ │
- │ │ (Sponsors Costs) │ │ (TYPE = READER) │ │
- │ └──────────┬──────────┘ └─────────────┬────────────┘ │
- │ │ │ │
- │ │ Billed for all Compute │ Provisions │
- │ ▼ ▼ │
- │ ┌─────────────────────┐ ┌──────────────────────────┐ │
- │ │ Resource Monitor │ │ Shared Inbound Data │ │
- │ │ (Enforces Quota) │ │ (Via ALTER SHARE ...) │ │
- │ └─────────────────────┘ └─────────────┬────────────┘ │
- └───────────────────────────────────────────────────────┼────────────────┘
- │
- ▼
- ┌────────────────────────────────────────────────────────────────────────┐
- │ MANAGED READER ACCOUNT (CLIENT) │
- │ │
- │ ┌────────────────────────────────────────────────────────────────┐ │
- │ │ Dedicated Account URL (https://org-reader.snowflakecomputing) │ │
- │ │ │ │
- │ │ ┌──────────────────────────┐ ┌────────────────────────┐ │ │
- │ │ │ Local Virtual Warehouse │ │ Mounted Shared DB │ │ │
- │ │ │ (X-Small, Auto-Suspend) │───►│ (Read-Only Live Access)│ │ │
- │ │ └──────────────────────────┘ └────────────────────────┘ │ │
- │ │ ▲ │ │
- │ │ │ Executes Queries │ │
- │ │ ┌─────────────┴────────────┐ │ │
- │ │ │ Client Users / BI Tools │ │ │
- │ │ │ (Tableau, Power BI, SQL) │ │ │
- │ │ └──────────────────────────┘ │ │
- │ └────────────────────────────────────────────────────────────────┘ │
- └────────────────────────────────────────────────────────────────────────┘
- Declarative Account Provisioning
To create a reader account, a user with ACCOUNTADMIN (or a role granted the global CREATE ACCOUNT privilege) in the provider account executes CREATE MANAGED ACCOUNT specifying TYPE = READER . By default a provider can create 20 reader accounts, and a dropped reader account keeps counting against that limit for its 7-day retention period: USE ROLE ACCOUNTADMIN;
- - Provision the managed reader account
- CREATE MANAGED ACCOUNT client_acme_reader
- ADMIN_NAME = 'acme_admin'
- ADMIN_PASSWORD = 'InitialTemporaryStrongPassword2026!'
- TYPE = READER
- COMMENT = 'Reader account for ACME partner logistics telemetry';
The output returns the new account's locator and URL. Share that URL, together with the initial administrator credentials, with the consumer. SHOW MANAGED ACCOUNTS lists the reader accounts a provider owns.
Associating Shares with the Reader Account
Once the reader account is provisioned, the provider adds the reader account to one or more existing shares: -- Add the newly created reader account to the target share
- ALTER SHARE logistics_telemetry_share ADD ACCOUNTS = client_acme_reader;
- Administrative Oversight and Access Delegation
The provider retains supreme administrative oversight over the reader account:
Bootstrap tasks happen inside the reader account: Using the initial administrator user, someone logs in to the reader account and creates users, custom roles, warehouses, resource monitors, and a database from each share. The account starts with a single administrator user.
Support model: Because a reader account has no contract with Snowflake, its users get support from the provider , who escalates to Snowflake Support when needed.
De-provisioning: If the business relationship ends, the provider revokes share access or drops the account: -- Revoke share access
ALTER SHARE logistics_telemetry_share REMOVE ACCOUNTS = client_acme_reader;
- - Permanently drop the reader account
- DROP MANAGED ACCOUNT client_acme_reader;
Resource & Cost Governance: The Provider Liability Model
The most critical architectural concept regarding reader accounts tested on the SnowPro Advanced: Architect exam is the financial liability model .
Architect Exam Rule: Reader accounts do not pay Snowflake for any service. ALL compute credits consumed by virtual warehouses operating within a reader account are billed directly to the PROVIDER'S Snowflake contract.
If an external partner runs poorly optimized queries, cartesian product joins, or connects uncurated BI dashboards that refresh every thirty seconds, the data provider pays for every single credit burned.
The Cost Control Strategy: Three Mandatory Layers
To prevent runaway compute spend in reader accounts, architects must enforce a three-layer governance framework:
Layer 1: Strict Virtual Warehouse Sizing & Parameters
When provisioning warehouses inside a reader account (either directly as provider or via initial bootstrap scripts), configure conservative parameters: -- Executed within the Reader Account context
USE ROLE ACCOUNTADMIN;
- CREATE WAREHOUSE reader_reporting_wh WITH
- WAREHOUSE_SIZE = 'XSMALL'
- AUTO_SUSPEND = 60 -- Suspend after 1 minute of inactivity
- AUTO_RESUME = TRUE
- INITIALLY_SUSPENDED = TRUE
- STATEMENT_TIMEOUT_IN_SECONDS = 300 -- Hard kill queries running > 5 minutes
- STATEMENT_QUEUED_TIMEOUT_IN_SECONDS = 60
- COMMENT = 'Conservative compute warehouse for external partner reporting';
Restrict warehouse size: Keep sizes to XSMALL or SMALL . Avoid creating large multi-cluster warehouses unless explicitly budgeted.
Aggressive AUTO_SUSPEND : Standard default is 10 minutes (600 seconds); reduce this to 60 seconds to eliminate idle credit burn.
STATEMENT_TIMEOUT_IN_SECONDS : Prevents runaway queries by terminating any execution exceeding the threshold (e.g., 300 seconds).
Layer 2: Resource Monitors Created Inside the Reader Account
Snowflake's guidance is explicit: without resource monitors, warehouses in a reader account can consume an unlimited number of credits, all billed to the provider. Resource monitors are created in the reader account (while logged in as its administrator) and can control all warehouses in the account or individual warehouses: -- Executed while logged in to the READER account as its administrator
USE ROLE ACCOUNTADMIN;
- CREATE RESOURCE MONITOR rm_acme_reader_cap
- WITH CREDIT_QUOTA = 200 -- Monthly budget of 200 credits
- FREQUENCY = MONTHLY
- START_TIMESTAMP = IMMEDIATELY
- TRIGGERS
- ON 75 PERCENT DO NOTIFY
- ON 90 PERCENT DO SUSPEND -- Prevent new queries
- ON 100 PERCENT DO SUSPEND_IMMEDIATE; -- Cancel running queries
- - Apply it to every warehouse in the reader account
- ALTER ACCOUNT SET RESOURCE_MONITOR = rm_acme_reader_cap;
Exam Trap: There is no ALTER MANAGED ACCOUNT ... SET RESOURCE_MONITOR command. MANAGED ACCOUNT supports only CREATE , DROP , and SHOW . Spend controls are configured inside the reader account, and the provider cannot rely on the consumer to do it.
Layer 3: Spend Telemetry & Auditing
Providers audit reader consumption from the provider account through the SNOWFLAKE.READER_ACCOUNT_USAGE schema, whose views (for example WAREHOUSE_METERING_HISTORY , QUERY_HISTORY , LOGIN_HISTORY , RESOURCE_MONITORS , STORAGE_USAGE ) cover all reader accounts created by the provider and include a READER_ACCOUNT_NAME column: -- Inspect reader account warehouse usage from the provider account
USE ROLE ACCOUNTADMIN;
- SELECT reader_account_name, warehouse_name, SUM(credits_used) AS credits
- FROM snowflake.reader_account_usage.warehouse_metering_history
- WHERE start_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
- GROUP BY 1, 2
- ORDER BY credits DESC;
- Operational Restrictions & Security Boundaries
A reader account is intended mainly for querying data shared by its provider, so Snowflake blocks anything that loads or modifies data.
What Reader Accounts CANNOT Do
Upload or modify data: INSERT , UPDATE , DELETE , MERGE , and COPY INTO <table> are not allowed.
Create stages, pipes, or shares: CREATE STAGE , CREATE PIPE , and CREATE SHARE are blocked, so readers cannot build ingestion pipelines or re-share data.
Create governance or ML objects: CREATE MASKING POLICY , CREATE ROW ACCESS POLICY , CREATE MODEL , CREATE SERVICE , CREATE STREAMLIT , and CREATE IMAGE REPOSITORY are blocked, as is setting data metric functions.
Unload through a storage integration: not allowed — but a reader can still run COPY INTO <location> with its own cloud credentials to unload query results. Reader accounts are therefore not an exfiltration control; the provider must decide what data to share in the first place.
Consume other providers' data: a reader account can consume data only from the provider that created it.
Everything else is allowed — for example, creating materialized views on shared data to speed up the reader's own queries.
What Reader Accounts CAN Do (Allowed Capabilities)
Mount and Query Shares: Mount shared databases and execute queries against shared tables and secure views.
User & Role Administration: The reader account administrator can create local users and custom roles on top of the standard system roles ( SYSADMIN , SECURITYADMIN , PUBLIC ), and should grant SECURITYADMIN and SYSADMIN to at least one other user to share administration.
Network Policies: Configure account-level and user-level network policies to restrict access to the reader account from specific partner corporate IP ranges.
BI and Driver Connectivity: Connect seamlessly via standard Snowflake drivers (JDBC, ODBC, Python, .NET, Go) and business intelligence tools (Tableau, Power BI, Looker, ThoughtSpot, Excel).
Standard Consumer Account vs. Managed Reader Account
- Capability / Architectural Dimension Standard Consumer Account Managed Reader Account
- Account Contract Owner Consumer owns independent contract Provider owns and sponsors contract
- Compute Credit Billing Consumer pays Snowflake Provider pays 100% of compute
Storage Credit Billing Consumer pays for local storage Any storage used in the reader account is billed to the provider
- Load or modify data (INSERT/UPDATE/DELETE/MERGE/COPY INTO table) Permitted Blocked
- Create Internal / External Stages Permitted Blocked
- Unload ( COPY INTO <location> ) Permitted Only with inline credentials; not through a storage integration
- Create Outbound Shares ( CREATE SHARE ) Permitted Blocked
- Local User & Role Management Permitted Permitted
- BI Tool & Driver Connectivity Permitted Permitted
- Network Policy Enforcement Permitted Permitted