ExamFinch.com My Study

Study guide

2.7 Vector Store Security, Multi-Tenancy & Connectivity

Practice this exam

AWS Certified Generative AI Developer - Professional AIP-C01

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Exam Overview & Foundation Model Fundamentals

1.1 AIP-C01 Exam Structure, Logistics & Passing Strategy 1.2 AIP-C01 Scoring & Professional Decision Strategy 1.3 Foundation Model Landscape & Model Selection on Amazon Bedrock 1.4 Model Abstraction, Controlled Switching & Resilience 1.5 Customization Spectrum: Prompting vs RAG vs Fine-Tuning vs Continued Pre-training 1.6 Custom Model Deployment & Lifecycle Management

2 Chapter 2: Bedrock Knowledge Bases & RAG Architectures

2.1 Managed RAG Architecture with Bedrock Knowledge Bases 2.2 Knowledge Source Integration, Synchronization & Freshness 2.3 Data Ingestion, Parsing & Chunking Strategies 2.4 Embedding Models & Vector Representations 2.5 Vector Index Scale, Migration & Retrieval Evaluation 2.6 Vector Database Selection: OpenSearch Serverless vs Aurora pgvector vs Managed Stores 2.7 Vector Store Security, Multi-Tenancy & Connectivity

3 Chapter 3: Advanced Vector Search, Indexing & Data Compliance

3.1 Hybrid Search, Metadata Filtering & Semantic Reranking 3.2 Metadata Filtering, Reranking & Query Transformation 3.3 Fine-Tuning & Continued Pre-Training Data Pipeline Engineering 3.4 Data Validation, Multimodal Processing & Model Formatting 3.5 Data Privacy, Data Residency & Compliance Governance 3.6 Privacy Preservation, Source Lineage & Audit Evidence

4 Chapter 4: Prompt Engineering & Bedrock Runtime APIs

4.1 Advanced Prompt Engineering Techniques & Inference Parameters 4.2 Inference Parameters, Prompt Governance & Regression 4.3 Converse API vs InvokeModel API & Message Formatting 4.4 Tool Calling, FM API Resilience & Model Routing 4.5 Streaming Architectures & Asynchronous Event Processing 4.6 Resilient Streaming, Deployment & Asynchronous Processing

5 Chapter 5: Amazon Bedrock Agents & Tool Integration

5.1 Agentic Architecture, ReAct Reasoning Loops & Orchestration 5.2 Agent Frameworks, MCP & Lifecycle Management 5.3 Action Groups, OpenAPI Schemas & AWS Lambda Integration 5.4 Agent Memory, Session State & Multi-Agent Collaboration Patterns 5.5 Persistent State & Multi-Agent Coordination 5.6 Advanced Agent Prompt Templates & Flow Customization 5.7 Agent Safeguards, Tool Reliability & Cost Control

6 Chapter 6: Workflow Orchestration & Application Integration

6.1 Amazon Bedrock Prompt Flows & Visual Orchestration 6.2 Step Functions Orchestration & Human-in-the-Loop Workflows 6.3 Enterprise Integration: API Gateway, AppSync, and EventBridge 6.4 Hybrid Integration, GenAI Gateways & CI/CD Tooling

7 Chapter 7: AI Safety & Guardrails for Amazon Bedrock

7.1 Guardrails Architecture, Denied Topics & Content Filters 7.2 Content Safety, Defense in Depth & Threat Detection 7.3 Sensitive Information Filters & PII Redaction/Masking 7.4 Contextual Grounding Checks & Hallucination Prevention

8 Chapter 8: Security, Access Control & Network Architecture

8.1 IAM Least Privilege & Resource Policies for Bedrock 8.2 PrivateLink VPC Endpoints & Network Isolation 8.3 Encryption with AWS KMS & Cross-Account Access Patterns

9 Chapter 9: Governance, Auditing & Operational Logging

9.1 SageMaker Model Cards & AI Governance Frameworks 9.2 Lineage, Fairness, Transparency & Continuous Governance 9.3 Invocation Logging, CloudTrail Auditing & Observability 9.4 Responsible AI, Bias Mitigation & Red Teaming Methodologies

10 Chapter 10: Performance, Throughput & Cost Optimization

10.1 On-Demand vs Provisioned Throughput & Capacity Planning 10.2 Capacity Measurement, Scaling Patterns & Resilience 10.3 Batch Inference & Bedrock Intelligent Prompt Routing 10.4 Intelligent Prompt Routing & Application Eligibility 10.5 Prompt Caching, Token Optimization & Latency Reduction

11 Chapter 11: Testing, Evaluation & Troubleshooting GenAI Solutions

11.1 Amazon Bedrock Model Evaluation (Automatic & Human Workflows) 11.2 Human, RAG & Continuous Evaluation 11.3 Evaluation Metrics & RAG Quality Benchmarking (Ragas, ROUGE, BLEU) 11.4 RAG and Agent Performance Evaluation 11.5 CloudWatch Metrics, Throttling & Operational Observability 11.6 Quota Diagnosis, Retry Control & Operational Troubleshooting 11.7 Troubleshooting Common GenAI Failure Modes & Agent Traces 11.8 Prompt Maintenance, Content Handling & Deployment Validation

2.7 Vector Store Security, Multi-Tenancy & Connectivity

Key Takeaways Explain This Topic AI

Use relational vector storage when SQL joins, transactions, or row-level security are core requirements.

Apply tenant constraints before retrieval and test for cross-tenant leakage.

OpenSearch Serverless capacity floors vary by generation and configuration, including scale-to-zero options for supported NextGen groups.

Last updated: September 2026

  • 2.7 Vector Store Security, Multi-Tenancy & Connectivity
  • Vector Store Architectural Comparison Matrix

Feature / Dimension OpenSearch Serverless Aurora PostgreSQL (pgvector) Pinecone (Serverless) MongoDB Atlas Redis Enterprise

Operational Model Fully Serverless Managed Instances / Serverless v2 Fully Serverless Managed DBaaS Managed In-Memory

  • Indexing Methods HNSW (Faiss/NMSLIB) HNSW, IVFFlat Proprietary HNSW-variant HNSW (Lucene) HNSW, Flat
  • Query Latency (p95) 15–35 ms 10–30 ms 15–30 ms 20–40 ms 1–5 ms
  • Relational SQL Joins No Yes (Full ACID SQL) No No (MQL Aggregations) No

Cost Basis OCUs (generation/configuration dependent) Aurora ACUs / Instance + Storage Read/Write Units + Storage Cluster Tier + Storage RAM capacity (GB)

Setup Complexity Lowest (Automated) Moderate (VPC, SQL scripts) Low (Secrets Manager) Moderate (VPC peering) Moderate

  • Multi-Cloud Support AWS Only AWS Only Multi-Cloud Multi-Cloud Multi-Cloud
  • Multi-Tenant Isolation Patterns in Vector Databases

Enterprise RAG architectures frequently serve multiple corporate tenants or user roles with strict confidentiality requirements.

Pattern 1: Metadata Filtering (Soft Isolation)

Mechanics : All tenants share a single vector index. Every ingested chunk includes a tenant_id metadata attribute.

Query Time : Runtime calls inject a strict metadata filter: {"filter": {"equals": {"key": "tenant_id", "value": "tenant_442"}}} .

Pros : Highly cost-effective; minimizes baseline OCU/instance overhead; simple operational model.

Risks : Application-level misconfiguration could leak data; neighbor graph traversal in HNSW can occasionally suffer search quality degradation if a tenant filter excludes 99% of graph nodes.

Pattern 2: Schema / Table-Level Isolation (Aurora PostgreSQL)

Mechanics : Each tenant receives an independent PostgreSQL table or schema within the same Aurora database.

Security : Can be enforced using PostgreSQL Row-Level Security (RLS) policies tied to database application roles.

Pros : Strong database-enforced security boundaries; complete ACID guarantees per tenant.

Pattern 3: Index-per-Tenant (Hard Isolation)

Mechanics : A dedicated vector index or collection is provisioned for each customer tenant.

Pros : Separate vector graphs reduce application-filter mistakes, but access policies and negative tests are still required.

Cons : Substantial infrastructure cost; limits on maximum collections/indices per account; administrative scaling bottleneck.

AWS Secrets Manager & Network Security Configuration

When connecting Bedrock Knowledge Bases to third-party or provisioned vector stores (Aurora, Pinecone, MongoDB, Redis), security integration relies on AWS Secrets Manager and IAM:

Secrets Manager Integration :

Database administrative credentials (PostgreSQL username/password, Pinecone API key) are stored in an AWS Secrets Manager secret.

The Bedrock Knowledge Base service execution role must possess explicit permissions: secretsmanager:GetSecretValue on the secret ARN, and kms:Decrypt on the KMS key used to encrypt the secret.

Network & VPC Routing :

If Amazon Aurora is deployed inside a private VPC, Bedrock must be granted access.

For OpenSearch Serverless, a VPC Network Policy or public network policy must be associated with the vector collection, accompanied by an Encryption Policy (AWS KMS) and a Data Access Policy allowing the Bedrock service role ARN aoss:Create* , aoss:Update* , and aoss:Describe* permissions.

  • Exam Scenarios & Architectural Traps
  • Exam Scenario 1: The Relational Joining Requirement

A retail bank is building an internal RAG assistant to answer employee questions regarding client loans. The loan contracts are stored as vector embeddings, but user queries must only return contracts where loan_status = 'ACTIVE' , risk_tier < 3 , and the employee has regional territory clearance in the employee management database.

Architectural Solution : Choose Amazon Aurora PostgreSQL with pgvector . This allows the application to execute a single query joining the vector similarity search ( <=> cosine distance operator) directly against relational tables containing loan statuses and employee territory permissions, enforcing complete ACID consistency.

Exam Scenario 2: Index Degradation with IVFFlat

A development team selects Amazon Aurora with pgvector and builds an IVFFlat index over 100,000 initial documents. Over the next six months, the data volume triples to 300,000 documents. Users report that search recall has dropped noticeably and queries frequently miss recently added documents.

Root Cause & Solution : IVFFlat partitions vectors around fixed centroid lists determined at index creation time. As new vectors are inserted, they are assigned to existing centroids without re-clustering, causing vector drift and degraded recall. The team must either:

Transition the index to HNSW , which dynamically updates its multi-layer graph on every insert without requiring retraining.

Implement a scheduled maintenance job that runs REINDEX INDEX during off-peak hours.

Common Trap: Assuming a Universal OpenSearch Serverless OCU Floor

A startup provisions an Amazon OpenSearch Serverless collection for a development/testing Knowledge Base that only holds 50 small documents. At the end of the month, they are surprised by an unexpected bill. OpenSearch Serverless capacity and minimums now depend on collection generation and configuration; current NextGen collection groups can support a minimum of zero for scale-to-zero. Check the current capacity documentation rather than assuming a universal 4-OCU floor. For low-volume development testing, Aurora Serverless v2 with pgvector or Pinecone Serverless can be significantly more economical.