Build and operate the data processing systems behind analytics and ML on Google Cloud, including BigQuery, Dataflow, and Pub/Sub, and track your readiness for the Professional Data Engineer exam.
Advanced
Prepare and test your skills
Advanced
Prepare and test your skills
Google Cloud feature
credential vending
Topic in 1 exam domain
- credential vending · Feature
- Credential Vending · Feature · Apache Iceberg REST catalog endpoint
Also called: storage access delegation
An access delegation mode that vends credentials to query engines for accessing Iceberg catalog resources.
Where this appears on the exam
1 objective in 1 of 5 domains
Related topics
FoundationsThis topicWorks alongsideBuilds on theseAppliedcatalogConceptLakehouseServiceApplication Default CredentialsFeature
credential vendingFeature
Sensitive Data ProtectionServiceAlloyDB for PostgreSQLServiceDatastreamServiceLakehouse runtime catalogFeatureCloud StorageServiceBigQueryServiceManaged Service for Apache SparkServicePoints to what builds on itWorks with or alternative toHover or tap a line to see what connects the two
- credential vending secures Cloud Storage From the official documentation: “With credential vending, the catalog securely issues temporary, table-scoped storage tokens to client engines and BigQuery, so external engines don't need direct IAM permissions on your bucket.”
- BigQuery works with credential vending From the official documentation: “BigQuery supports using [credential vending](/lakehouse/docs/credential-vending) for authentication when reading or writing Iceberg tables in the Lakehouse runtime catalog.”
- credential vending is part of catalog From the official documentation: “Administrators can enable credential vending on the catalog to delegate access, letting short-lived credentials with reduced scope be autogenerated instead of granting users direct bucket permissions.”
- credential vending secures Lakehouse runtime catalog From the official documentation: “Credential vending is a security mechanism that helps tighten access control when using the Lakehouse runtime catalog.”
- Application Default Credentials works with Cloud Storage From the official documentation: “To authenticate to Cloud Storage, set up Application Default Credentials.”
- Sensitive Data Protection depends on Application Default Credentials From the official documentation: “To authenticate to Sensitive Data Protection, set up Application Default Credentials.”
- Application Default Credentials secures BigQuery From the official documentation: “To authenticate to BigQuery, set up Application Default Credentials.”
- BigQuery depends on Application Default Credentials From the official documentation: “To authenticate to BigQuery, set up Application Default Credentials.”
- BigQuery works with Sensitive Data Protection From the official documentation: “Uses the Data Loss Prevention API to analyze BigQuery data.”
- BigQuery is an alternative to Cloud Storage From the official documentation: “The `import_result_sink` must be a Cloud Storage path or a BigQuery table.”
- BigQuery works with Cloud Storage From the official documentation: “External BigQuery data source backed by Cloud Storage”
- Application Default Credentials works with BigQuery From the official documentation: “Create a BigQuery client using application default credentials.”
- BigQuery works with Datastream From the official documentation: “Permissions needed for datastream to write to BigQuery.”
- Application Default Credentials secures Sensitive Data Protection From the official documentation: “To authenticate to Sensitive Data Protection, set up Application Default Credentials.”
- Cloud Storage works with Datastream From the official documentation: “When you stream to Cloud Storage, Datastream organizes data by object name and timestamp.”
- Application Default Credentials secures Cloud Storage From the official documentation: “To authenticate to Cloud Storage, set up Application Default Credentials.”
- Cloud Storage depends on Application Default Credentials From the official documentation: “To authenticate to Cloud Storage, set up Application Default Credentials.”
- BigQuery works with Lakehouse runtime catalog From the official documentation: “When querying Lakehouse runtime catalog tables from BigQuery, you use a four-part naming structure, often referred to as **P.C.N.T**:”
- Application Default Credentials works with Sensitive Data Protection From the official documentation: “To authenticate to Sensitive Data Protection, set up Application Default Credentials.”
- Cloud Storage works with Sensitive Data Protection From the official documentation: “Uses the Data Loss Prevention API to analyze a file on GCS.”
- BigQuery works with Managed Service for Apache Spark From the official documentation: “This means you can quickly read and write BigQuery data to and from Managed Service for Apache Spark.”
- Lakehouse runtime catalog works with Managed Service for Apache Spark From the official documentation: “Managed Service for Apache Spark supports only PySpark jobs with borderless Lakehouse Metastore.”
- AlloyDB for PostgreSQL works with Datastream From the official documentation: “Datastream works with the following types of PostgreSQL databases: - AlloyDB for PostgreSQL”
- BigQuery is an alternative to Managed Service for Apache Spark From the official documentation: “Run queries against your federated data using BigQuery or Managed Service for Apache Spark.”
- Cloud Storage works with Managed Service for Apache Spark From the official documentation: “Managed Service for Apache Spark accesses these files on Cloud Storage.”
- AlloyDB for PostgreSQL works with BigQuery From the official documentation: “BigQuery AlloyDB federation lets BigQuery query data residing in AlloyDB in real time without copying or moving the data.”
- AlloyDB for PostgreSQL works with Cloud Storage From the official documentation: “AlloyDB supports importing and exporting compressed `.gz` files from Cloud Storage.”
- Application Default Credentials works with Managed Service for Apache Spark From the official documentation: “To authenticate to Managed Service for Apache Spark, set up Application Default Credentials.”
- Application Default Credentials secures Managed Service for Apache Spark From the official documentation: “To authenticate to Managed Service for Apache Spark, set up Application Default Credentials.”
- BigQuery works with Lakehouse From the official documentation: “BigLake automatically registers the Iceberg table in BigQuery:”
- Managed Service for Apache Spark depends on Cloud Storage From the official documentation: “Managed Service for Apache Spark uses Cloud Storage as its default distributed file system.”
- Application Default Credentials configures Sensitive Data Protection From the official documentation: “To authenticate to Sensitive Data Protection, set up Application Default Credentials.”
- Cloud Storage works with Lakehouse runtime catalog From the official documentation: “Set up and configure Lakehouse catalog endpoints to unify data silos across AWS S3, Cloud Storage, and AlloyDB.”
- Lakehouse runtime catalog is part of Lakehouse From the official documentation: “*The Lakehouse runtime catalog* is a centralized, serverless metadata service that acts as the single source of truth for Google Cloud's Lakehouse.”
- Managed Service for Apache Spark depends on Application Default Credentials From the official documentation: “To authenticate to Managed Service for Apache Spark, set up Application Default Credentials.”
- AlloyDB for PostgreSQL works with Lakehouse runtime catalog From the official documentation: “Set up and configure Lakehouse catalog endpoints to unify data silos across AWS S3, Cloud Storage, and AlloyDB.”
- Application Default Credentials configures BigQuery From the official documentation: “To authenticate to BigQuery, set up Application Default Credentials.”
- Application Default Credentials configures Cloud Storage From the official documentation: “To authenticate to Cloud Storage, set up Application Default Credentials. For more information, see [Set up authentication for client libraries](/storage/docs/authentication#client-libs).”
- BigQuery depends on Cloud Storage From the official documentation: “BigQuery relies on Cloud Storage for staging file data and supports reading from and writing to several other sources and Google Cloud services.”
- BigQuery is an alternative to Lakehouse From the official documentation: “The BigLake External Tables view outlines tables that are identified as targets to migration to BigLake instead of BigQuery.”
- BigQuery depends on Lakehouse runtime catalog From the official documentation: “BigQuery federates queries to these endpoints using the Google Cloud Lakehouse runtime catalog connection.”
- Cloud Storage works with Lakehouse From the official documentation: “If your Parquet files are in Cloud Storage, this transform registers the files with Lakehouse without moving or rewriting the underlying data.”
- Datastream works with Lakehouse From the official documentation: “- [Learn how to use Datastream to replicate transactional databases to Lakehouse tables](/datastream/docs/destination-blmt).”
- Sensitive Data Protection secures BigQuery From the official documentation: “To help meet compliance requirements, use Sensitive Data Protection to inspect your BigQuery tables and to help protect your sensitive data.”
How learners score on this topic
Last updated