Senior Data Engineer, AWS Data Engineer, Cloud Architect, Solutions Architect, Data Platform Architect, and Technical Lead interviews.

Interviewers will usually ask questions in 5 dimensions:

1. Project Overview
2. Architecture & Design Decisions
3. AWS Services Deep Dive
4. Leadership & Solution Architecture
5. Real-Time Production Challenges

Below are some of the highest-probability questions along with detailed interview-ready answers.

1. Tell Me About Your Project

Q1. Can you explain your project architecture end-to-end?

Answer

I worked as a Cloud Data Platform Architect and Technical Lead for a global healthcare management platform called VERSO.

The platform served as the central data hub for Life Sciences operations globally.

The architecture consisted of:

Data Sources

• Clinical systems
• Healthcare applications
• CRM systems
• Vendor systems
• On-prem databases
• External partner systems

Ingestion Layer

• AWS DMS
• AWS DataSync
• SFTP
• API integrations

Storage Layer

• Amazon S3 as Data Lake
• Aurora PostgreSQL
• DynamoDB

Processing Layer

• AWS Glue
• AWS Lambda
• Python

Analytics Layer

• Amazon Redshift
• QuickSight
• SageMaker
• ElasticSearch

DevOps Layer

• CloudFormation
• GitHub Actions
• Jenkins

Security Layer

• IAM
• Secrets Manager
• KMS
• VPC Security Groups

The platform processed healthcare operational data and provided near real-time reporting and analytics to global business users.

2. Architecture Design Questions

Q2. Why did you choose AWS Aurora instead of RDS PostgreSQL?

Answer

Aurora was selected because:

For mission-critical healthcare applications requiring high availability and disaster recovery, Aurora was the better choice.

Q3. Why use DynamoDB when Aurora already exists?

Answer

Different workloads required different database patterns.

Aurora

Used for:

• Transactional workloads
• Complex joins
• ACID transactions

Examples:

• User management
• Healthcare records

DynamoDB

Used for:

• Session data
• Metadata
• High-volume key-value lookups

Examples:

• Application configuration
• User preferences
• Workflow status tracking

DynamoDB provided millisecond latency at scale.

Q4. Why Redshift?

Answer

Redshift was used as the enterprise data warehouse.

Reasons:

• Columnar storage
• Massively Parallel Processing (MPP)
• Fast aggregation
• Cost-effective analytics

Business users needed complex reports involving billions of records.

Aurora was not suitable for large-scale analytical queries.

3. Data Pipeline Questions

Q5. Explain your AWS Glue architecture.

Answer

AWS Glue was the primary ETL engine.

Flow:

Source Systems
↓
S3 Landing Zone
↓
Glue Crawlers
↓
Glue Data Catalog
↓
Glue ETL Jobs (Python/PySpark)
↓
S3 Curated Layer
↓
Redshift

Glue jobs handled:

• Data cleansing
• Standardization
• Validation
• Transformations
• Aggregations

Q6. Why replace batch processing with event-driven architecture?

Answer

Traditional batch processing had:

• Long wait times
• Delayed reports
• Resource wastage

Event-driven architecture provided:

• Near real-time processing
• Faster reporting
• Better scalability
• Lower operational costs

Example:

When a healthcare record arrived in S3:

S3 Event
↓
Lambda Trigger
↓
Glue Workflow
↓
Redshift Load

Processing started immediately.

Q7. How did you improve throughput?

Answer

We implemented:

Parallel Processing

Glue workers executed jobs concurrently.

Partitioning

Data partitioned by:

• Year
• Month
• Region

Pushdown Predicates

Reduced unnecessary reads.

Incremental Loads

Processed only changed data.

These changes significantly improved throughput.

4. AWS Lambda Questions

Q8. Explain the password reset automation solution.

Answer

Previously:

DBA teams manually reset database accounts.

Workflow:

User Request
↓
Service Portal
↓
Lambda
↓
Secrets Manager
↓
Aurora/Postgres/Redshift
↓
Password Update
↓
Notification

Benefits:

• Zero manual intervention
• Faster turnaround
• Improved security
• Auditability

Q9. Why Lambda instead of EC2?

Answer

Reasons:

Serverless

No infrastructure management.

Cost Efficient

Pay only when invoked.

Auto Scaling

Scales automatically.

Fast Deployment

Simple CI/CD integration.

The automation workloads were event-driven and ideal for Lambda.

Q10. What Lambda limitations did you face?

Answer

Common limitations:

• 15-minute timeout
• Memory constraints
• Cold starts

Solutions:

• Increased memory allocation
• Optimized package size
• Used Step Functions for longer workflows

5. CloudFormation Questions

Q11. Why Infrastructure as Code?

Answer

Benefits:

Consistency

Same infrastructure across environments.

Repeatability

Automated provisioning.

Version Control

Stored templates in GitHub.

Compliance

Approved architectures enforced automatically.

Q12. What resources were managed using CloudFormation?

Answer

Examples:

• VPC
• Subnets
• IAM Roles
• Lambda
• S3 Buckets
• Glue Jobs
• Redshift
• Security Groups
• CloudWatch

Q13. How do you handle CloudFormation rollbacks?

Answer

Best practices:

• Change Sets
• Stack Policies
• Nested Stacks
• Automated validation

If deployment failed:

CloudFormation automatically reverted to last stable state.

6. CI/CD Questions

Q14. Explain your CI/CD pipeline.

Answer

Pipeline:

Developer Commit
↓
GitHub
↓
GitHub Actions
↓
Unit Testing
↓
Code Quality Scan
↓
CloudFormation Validation
↓
Build
↓
Jenkins Deployment
↓
AWS Environment

Q15. Why GitHub Actions and Jenkins both?

Answer

GitHub Actions:

• Source control integration
• Pull Request validation
• Unit tests

Jenkins:

• Complex deployment orchestration
• Legacy integrations
• Multi-stage deployments

Together they provided flexibility.

Q16. What TDD practices were implemented?

Answer

Before deployment:

• Unit tests
• Mock testing
• Integration tests
• Regression tests

Benefits:

• Fewer production defects
• Faster deployments
• Higher code quality

7. Data Migration Questions

Q17. Explain AWS DMS usage.

Answer

AWS DMS migrated data from on-prem databases to AWS.

Flow:

Source Database
↓
DMS Replication Instance
↓
S3 / Aurora / Redshift

Used for:

• Initial migration
• Continuous replication
• CDC (Change Data Capture)

Q18. What is CDC?

Answer

CDC captures only changed records.

Instead of:

Reading 100 million rows

We only process:

• Inserts
• Updates
• Deletes

Benefits:

• Lower latency
• Reduced costs
• Faster synchronization

Q19. Why DataSync?

Answer

DataSync was used for:

• Large file migrations
• NFS
• SMB
• On-prem file systems

Benefits:

• Encrypted transfer
• High speed
• Scheduling support
• Integrity verification

8. Analytics Questions

Q20. How was QuickSight used?

Answer

QuickSight provided:

• Executive dashboards
• Clinical reporting
• Operational KPIs
• Financial insights

Data Source:

Redshift

↓

QuickSight

Benefits:

• Serverless BI
• Pay-per-session
• Fast dashboard delivery

Q21. How was SageMaker used?

Answer

Used for predictive analytics:

Examples:

• Patient trend analysis
• Forecasting
• Risk scoring

Workflow:

S3
↓
SageMaker Training
↓
Model Endpoint
↓
Predictions

Q22. Why ElasticSearch?

Answer

Used for:

• Full-text search
• Log analytics
• Operational dashboards

Advantages:

• Near real-time indexing
• Fast search capability
• Flexible querying

9. Security Questions

Q23. How did you secure healthcare data?

Answer

Implemented:

Encryption

• KMS
• S3 Encryption
• Redshift Encryption
• Aurora Encryption

IAM

Least privilege access.

Secrets Manager

Credential management.

Network Security

• VPC
• Private Subnets
• Security Groups

Auditing

• CloudTrail
• CloudWatch Logs

Q24. How did you handle HIPAA-style requirements?

Answer

Key controls:

• Encryption at rest
• Encryption in transit
• Audit logging
• Role-based access
• Data masking
• Access reviews

10. Leadership Questions

Q25. How did you lead a team of 15 engineers?

Answer

Responsibilities:

• Architecture governance
• Code reviews
• Sprint planning
• Solution design
• Technical mentoring

I ensured alignment between architecture standards and business goals while supporting Agile delivery.

Q26. How do you perform trade-off analysis?

Answer

I evaluate:

Cost

Infrastructure expenses.

Performance

Latency and throughput.

Scalability

Future growth.

Security

Compliance requirements.

Operational Complexity

Maintenance effort.

Example:

For real-time ingestion, we compared:

• Batch ETL
• Event-driven architecture

Event-driven architecture provided lower latency and better scalability.

11. FinOps Questions

Q27. Explain the Resource Utilization Reporting solution.

Answer

We built a Lambda-based inventory solution.

Workflow:

Lambda
↓
AWS SDK (Boto3)
↓
Cross-Account Role Assumption
↓
Inventory Collection
↓
S3
↓
Athena
↓
QuickSight Dashboard

Collected:

• EC2
• RDS
• Lambda
• S3
• Redshift
• Glue

Benefits:

• Cost visibility
• Unused resource detection
• FinOps governance

Q28. How did you reduce AWS costs by 20%?

Answer

Methods:

Rightsizing

Reduced oversized instances.

Storage Optimization

Lifecycle policies on S3.

Reserved Capacity

Aurora and Redshift optimization.

Removing Redundant Pipelines

Eliminated duplicate processing.

Auto Scaling

Dynamic resource allocation.

12. Most Difficult Interview Question

Q29. What was the biggest challenge in the project?

Answer

The biggest challenge was modernizing legacy batch pipelines while ensuring zero disruption to healthcare reporting.

Challenges:

• Multiple source systems
• Data quality inconsistencies
• Strict compliance requirements
• Limited downtime windows

Solution:

• Introduced CDC using DMS
• Event-driven Glue workflows
• Incremental migration strategy
• Parallel validation framework

Result:

• Near real-time reporting
• Improved throughput
• Reduced operational overhead
• No business disruption

Q30. Why should we hire you for a Senior AWS Data Architect role?

Answer

I bring a combination of:

• AWS Solution Architecture expertise
• Data Engineering experience
• Cloud Migration leadership
• CI/CD automation
• Infrastructure as Code
• Team leadership
• FinOps optimization

I have designed and delivered enterprise-scale healthcare data platforms handling mission-critical workloads while balancing scalability, security, compliance, reliability, and cost optimization. This enables me to contribute not only as an engineer but also as an architecture and technical leadership resource.

1. Architecture & Design Decisions

Q1: Why did you choose a multi-database strategy (RDS Aurora, Redshift, DynamoDB) instead of a single database?
A1:
Each database serves a distinct purpose in the VERSO platform:

• Aurora (PostgreSQL-compatible) handles transactional (OLTP) workloads from the healthcare management platform — fast inserts/updates of patient or operational data.
• Redshift is for analytical (OLAP) queries — aggregating large datasets for enterprise reporting.
• DynamoDB stores metadata, session states, or high-velocity lookup data (e.g., user preferences, job statuses) with millisecond latency.
  This polyglot persistence approach optimizes both cost and performance.

Q2: How did you reduce infrastructure spend by ~20%?
A2:
We performed a rightsizing exercise using AWS Trusted Advisor and custom RU (Resource Utilization) reports:

• Downsized over-provisioned RDS and Redshift nodes.
• Removed redundant data pipelines where the same data was transformed twice.
• Replaced idle EC2 with Lambda for event-driven tasks.
• Scheduled non-production environments to shut down during off-hours.

2. Data Pipeline Modernization

Q3: What does “replacing batch processes with near-real-time event-driven flows” mean technically?
A3:
Previously, we ran hourly or daily Glue jobs. After modernization:

• S3 uploads trigger Lambda → which triggers Glue workflows.
• DynamoDB Streams push changes to Lambda → updates Redshift via COPY or streaming ingestion.
  This reduced reporting latency from hours to sub-5 minutes, improving clinical decision-making.

Q4: Why AWS Glue over other ETL tools?
A4:

• Serverless — no cluster management.
• Python-native (PySpark) aligns with our team’s skills.
• Integrates natively with the AWS Lake Formation and Data Catalog.
• Cost-effective for medium-volume healthcare data (~TB scale) compared to fully-managed ETL appliances.

3. Serverless Automation (Lambda + Self-Service Portals)

Q5: How did you enable “automated account management and password reset for RDS/Redshift”?
A5:
We built a self-service portal (internal website) that calls API Gateway → Lambda. The Lambda:

• Validates user identity via IAM and corporate SSO.
• Executes ALTER USER or stored procedures on Aurora/Redshift.
• Rotates passwords securely and stores hashes in Secrets Manager.
  This eliminated ticket-based ops, saving 60% manual effort.

Q6: What security measures did you implement in that automation?
A6:

• Least-privilege IAM roles for Lambda.
• VPC-attached Lambda to reach RDS without internet exposure.
• Secrets Manager for database master credentials.
• Audit logging via CloudTrail + CloudWatch Logs.
• Temporary passwords with expiration enforced by application logic.

4. Infrastructure as Code (CloudFormation)

Q7: How did you standardize Dev/Test/Prod environments using CloudFormation?
A7:
We created parameterized templates with:

• Environment-specific variables (instance size, backup retention, alarm thresholds).
• Nested stacks for networking, compute, and databases.
• StackSets to deploy across multiple AWS accounts.
  Changes were peer-reviewed and deployed via CI/CD, ensuring governance and repeatability.

Q8: How did you handle secrets (passwords, API keys) in CloudFormation?
A8:
We never hard-coded secrets. Instead:

• Used DynamicReference to fetch from Secrets Manager.
• Passed parameter store paths as parameters.
• Encrypted environment variables using AWS KMS.
  This kept templates safe for Git.

5. CI/CD & Testing (GitHub Actions + Jenkins)

Q9: Why both GitHub Actions and Jenkins?
A9:

• GitHub Actions for lightweight CI: linting, unit tests, and Glue script validation.
• Jenkins for heavy CD: multi-stage deployments across Dev → Test → Prod, approvals, and integration with legacy on-prem systems.
  This hybrid model leveraged GitHub’s simplicity and Jenkins’ flexibility for compliance-heavy workflows.

Q10: How did you implement TDD (Test-Driven Development) for infrastructure?
A10:
We used taskcat (CloudFormation testing) and pytest for Lambda functions:

• Write failing test (e.g., “Lambda should return 200 for valid password reset”).
• Implement minimal code.
• Refactor.
• Automated tests ran on every PR, preventing broken IaC or business logic from merging.

6. Analytics Architecture (QuickSight, SageMaker, ElasticSearch)

Q11: How do QuickSight, SageMaker, and ElasticSearch work together in your platform?
A11:

• QuickSight provides dashboards for clinical and commercial KPIs (e.g., patient enrollment trends).
• SageMaker runs predictive models (e.g., patient churn, drug efficacy forecasts) using Redshift data.
• ElasticSearch (OpenSearch) indexes logs and clinical trial documents for search and anomaly detection.
  Data flows from S3/Redshift to each service based on use case — not a single monolithic BI tool.

Q12: How did you secure sensitive healthcare data in analytics?
A12:

• Redshift row-level security + column-level masking.
• QuickSight integration with AWS Lake Formation for fine-grained access.
• ElasticSearch with Cognito authentication and field-level security.
• All data encrypted at rest (KMS) and in transit (TLS).

7. Data Migration (DMS, DataSync, SFTP)

Q13: When would you use DMS vs DataSync vs SFTP?
A13:

• DMS — for live database migration with minimal downtime (on-prem Oracle → Aurora).
• DataSync — for moving files (e.g., CSV, images) from on-prem NFS/DFS to S3 with built-in checksums and bandwidth limiting.
• SFTP — for external partners who cannot use AWS native tools; we used AWS Transfer Family to maintain an SFTP endpoint.

Q14: How did you ensure data auditability during migration?
A14:

• DMS validation task to compare row counts and checksums.
• DataSync verification after each transfer.
• CloudTrail + S3 server access logs.
• Each file processed included metadata tags: source, timestamp, migration-batch-id.

8. Resource Utilization (FinOps & Governance)

Q15: What is the “Resource Utilization (RU) reporting solution” built with Lambda?
A15:
A scheduled Lambda (cron) that:

1. Calls AWS Resource Groups & Tagging API to list all services across accounts (RDS, Redshift, Lambda, S3, etc.).
2. Fetches CloudWatch metrics (CPU, IOPS, storage used).
3. Writes results to S3 (Parquet) and updates an Aurora table.
4. Triggers QuickSight SPICE ingestion for dashboards.
   This gave finance and engineering weekly visibility into underutilized resources.

Q16: How did this improve FinOps governance?
A16:
We could:

• Identify idle NAT gateways and unattached EBS volumes.
• Rightsize Redshift based on query queue depth.
• Alert teams when their sandbox costs exceeded $500/month.
• Show business stakeholders cost-per-pipeline for chargeback.

9. Team & Agile (SAFe, Cross-functional)

Q17: How did you govern architectural standards for a 15-engineer team?
A17:

• Weekly Architecture Review Board (ARB) for any new service or major pipeline change.
• Maintained a living “Well-Architected Review” document.
• Mandated CloudFormation and TDD for all infrastructure.
• Used pull request templates with security and cost checklists.

Q18: How did you align with SAFe/Agile while delivering cloud architecture?
A18:
We participated in:

• PI Planning (Program Increment) for quarterly roadmap.
• System Demos every 2 weeks.
• Story-level definition: each CloudFormation module or Lambda function was a story with acceptance criteria.
• Built an Architectural Runway (e.g., Lambda foundation, Glue job templates) ahead of feature teams to enable fast delivery.

10. Business & Stakeholder Collaboration

Q19: How did you translate business needs into technical strategies?
A19:
Example: Business wanted “real-time patient safety alerts.”
We translated to:

• DynamoDB stream → Lambda → publish to SNS/SQS.
• Latency SLA: < 5 seconds.
• Cost estimate: $0.01 per 1000 alerts.
• Trade-off: true real-time requires Kinesis (higher cost). We chose near-real-time with Lambda + SQS to balance cost and need.

Q20: How did you estimate effort for new cloud initiatives?
A20:
Used a three-point method:

• Optimistic: reusable CloudFormation templates exist.
• Most likely: minor modifications.
• Pessimistic: new integration (e.g., on-prem firewall changes, compliance review).
  We tracked historical velocity — building a Lambda + API Gateway averaged 5 story points (2 days).

1. Project Overview & High-Level Questions

Q1. Can you walk us through your VERSO project end-to-end? Answer: VERSO was a global Life Sciences Healthcare Management Platform acting as the central data hub for enterprise-wide data processing, analytics, and reporting. I served as the Cloud Data Platform Architect and Technical Lead in a 15-member cross-functional team.

Key Layers:

• Sources: Clinical systems, CRM, vendor systems, on-prem databases, external partners.
• Ingestion: AWS DMS, DataSync, SFTP, API integrations.
• Storage: S3 Data Lake (landing/curated), Aurora PostgreSQL, DynamoDB, Redshift.
• Processing: AWS Glue (Python/PySpark), Lambda for orchestration and automation.
• Analytics: Redshift (warehouse), QuickSight (BI), SageMaker (ML), ElasticSearch (search/logs).
• DevOps & Governance: CloudFormation (IaC), GitHub Actions + Jenkins (CI/CD), IAM/Secrets Manager/KMS/VPC.
• Automation: Serverless Lambda workflows for account management and password resets.

The platform enabled near real-time reporting while maintaining strict healthcare compliance.

Q2. What was the business impact of this platform? Answer: It became the single source of truth for clinical and commercial teams. Key wins included ~20% infrastructure cost reduction, 60% reduction in manual ops effort for database management, significantly faster reporting latency through event-driven pipelines, and improved FinOps visibility via automated resource utilization reporting.

Q3. What was your specific role and scope? Answer: I owned end-to-end architecture, solution design, trade-off analysis, IaC strategy, and technical leadership. I collaborated with business/product leaders on requirements and roadmaps while governing standards across the 15-engineer team in a SAFe/Agile environment.

2. Architecture & Design Decisions

Q4. Why did you choose this multi-database architecture (Aurora + DynamoDB + Redshift)? Answer: Each service was chosen for its strengths:

• Aurora PostgreSQL: Transactional workloads, complex joins, ACID compliance (user accounts, healthcare records).
• DynamoDB: High-scale, low-latency key-value operations (session data, metadata, workflow status).
• Redshift: Analytical workloads with columnar storage and MPP for complex aggregations over billions of rows.

This polyglot persistence approach optimized performance and cost.

Q5. How did you design for scalability and cost efficiency? Answer:

• Rightsized services and implemented auto-scaling.
• Used S3 lifecycle policies and storage tiering.
• Replaced redundant batch pathways with event-driven flows.
• Leveraged serverless (Lambda, Glue) for variable workloads.
• Result: ~20% reduction in spend.

Q6. Explain your data pipeline modernization strategy. Answer: Migrated from legacy batch to event-driven near-real-time:

• S3 events → Lambda triggers → Glue workflows → Redshift.
• Used partitioning, pushdown predicates, and incremental (CDC) loads.
• Benefits: Reduced latency, higher throughput, lower costs, and better resource utilization.

Q7. How did you handle different environments (Dev/Test/Prod)? Answer: CloudFormation templates + parameters for environment-specific configurations ensured consistency, repeatability, and governance. CI/CD pipelines promoted changes safely through environments.

3. AWS Services Deep Dive

Q8. Explain your AWS Glue architecture and usage. Answer: Glue served as the core ETL engine. Crawlers discovered schemas → Data Catalog → Python/PySpark jobs performed cleansing, standardization, validation, transformation, and aggregation. Jobs wrote to curated S3 zones before loading into Redshift. Workflows were orchestrated via event triggers for near real-time processing.

Q9. Why and how did you use AWS Lambda? Answer: For serverless automation:

• Password/account reset workflows integrated with self-service portals.
• Triggered by API Gateway or S3 events.
• Interacted with Secrets Manager to update credentials across Aurora, PostgreSQL, and Redshift.
• Reduced manual ops by 60%.

Q10. What are the limitations of Lambda you faced and how did you overcome them? Answer:

• 15-min timeout: Broke long tasks using Step Functions or moved heavy work to Glue.
• Cold starts/memory: Allocated higher memory and optimized code/packages.
• Used provisioned concurrency where needed for critical paths.

Q11. Describe your use of AWS DMS and DataSync. Answer:

• DMS: For database migration and CDC (Change Data Capture) from on-prem to cloud with minimal downtime.
• DataSync: For high-speed, secure file migrations (NFS/SMB) with scheduling and integrity checks.

Q12. How did you implement analytics architecture? Answer:

• QuickSight: Serverless BI dashboards for KPIs, clinical, and financial reporting.
• SageMaker: Predictive models (patient trends, risk scoring, forecasting).
• ElasticSearch: Full-text search, log analytics, and operational dashboards.

Q13. Explain your CloudFormation (IaC) strategy. Answer: Modular, nested templates for VPC, networking, IAM, databases, Glue jobs, Lambda, etc. Stored in GitHub, validated in CI/CD. Enabled consistent, auditable, and compliant provisioning across environments.

4. CI/CD, Automation & DevOps

Q14. Walk through your CI/CD pipeline. Answer: Developer commit → GitHub Actions (unit tests, code quality, CloudFormation validation) → Jenkins (orchestration, multi-stage deployment to AWS). Practiced TDD with comprehensive unit, integration, and regression tests.

Q15. Why both GitHub Actions and Jenkins? Answer: GitHub Actions for fast PR validation and lightweight tasks; Jenkins for complex deployment orchestration and legacy system integrations. The combination provided flexibility and reliability.

5. Leadership, Collaboration & Governance

Q16. How did you lead a team of 15 engineers? Answer:

• Architecture governance and design reviews.
• Mentorship and knowledge sharing.
• Sprint planning aligned with SAFe/Agile.
• Ensured technical decisions supported business priorities.

Q17. How did you perform trade-off analysis? Answer: Evaluated Cost, Performance, Scalability, Security/Compliance, and Operational Complexity. Example: Chose event-driven over batch for lower latency despite higher initial design effort.

Q18. How did you collaborate with non-technical stakeholders? Answer: Translated business requirements into technical roadmaps, provided effort estimates, presented architecture diagrams, and demonstrated value through prototypes and ROI metrics (cost savings, latency improvements).

6. Security, Compliance & FinOps

Q19. How did you ensure security and compliance (HIPAA-like)? Answer:

• Encryption at rest/transit (KMS).
• Least-privilege IAM + Secrets Manager.
• VPC, private subnets, security groups.
• Full auditing with CloudTrail and CloudWatch.
• Data masking and access reviews.

Q20. Explain your automated Resource Utilization (RU) reporting solution. Answer: Lambda (Boto3) with cross-account roles inventoried all resources (EC2, RDS, S3, etc.) → S3 → Athena → QuickSight dashboard. Improved FinOps visibility and helped identify optimization opportunities.

Q21. How did you achieve ~20% cost reduction? Answer: Rightsizing, storage optimization, Reserved Instances/Savings Plans, removal of redundant pipelines, auto-scaling, and better visibility via the RU reporting tool.

7. Challenges & Behavioral Questions

Q22. What was the biggest challenge and how did you overcome it? Answer: Modernizing legacy batch pipelines without disrupting critical healthcare reporting. Approach: Phased migration using CDC, parallel run validation, event-driven Glue workflows, and incremental cutovers. Result: Near real-time capabilities with zero business disruption.

Q23. Tell me about a time you had to make a difficult architectural decision. Answer: Deciding between fully managed services vs. more custom solutions. Chose serverless-heavy architecture for cost and ops efficiency while ensuring it met performance and compliance needs through careful testing and fallback plans.

Q24. How do you handle production incidents or data quality issues? Answer: Implemented monitoring (CloudWatch), alerting, data validation in Glue jobs, and rollback capabilities in CloudFormation. Used CDC for quick recovery and maintained audit trails for compliance.

Q25. Why are you a strong fit for a Senior AWS Data Architect / Technical Lead role? Answer: I combine deep hands-on AWS data services expertise, end-to-end architecture ownership, migration experience, automation leadership, FinOps optimization, and team governance skills — all proven in a regulated healthcare environment delivering measurable business impact.