1) Role Summary

The Infrastructure Architect designs, guides, and governs the technical infrastructure foundations that applications and platforms run on—across cloud, on‑premises (when applicable), networking, identity, compute, storage, and operational tooling. The role translates business and product needs into resilient, secure, scalable, and cost-effective infrastructure architectures, then partners with engineering and operations teams to implement and continuously improve those designs.

This role exists in software and IT organizations to ensure infrastructure decisions are intentional, standardized where appropriate, and aligned to reliability, security, and cost objectives—rather than emerging ad hoc from project-by-project delivery. The Infrastructure Architect creates business value by reducing outages, accelerating delivery through reusable patterns, improving security posture, and optimizing spend while enabling teams to scale.

• Role horizon: Current (widely established in modern software/IT operating models)
• Seniority (inferred conservatively): Senior Individual Contributor (IC) architect level (often equivalent to “Senior Architect” scope without the title marker)
• Typical interactions: Platform Engineering, SRE/Operations, Security, Network Engineering, Application Architects, DevOps, Data/Analytics platforms, Product Engineering, IT Service Management (ITSM), Finance/FinOps, Procurement/Vendor Management, and Compliance/Risk

2) Role Mission

Core mission:
Design and evolve the organization’s infrastructure architecture—cloud and/or hybrid—so that product and IT delivery teams can build and operate services that meet agreed targets for availability, performance, security, scalability, compliance, and cost.

Strategic importance to the company:
Infrastructure is a force multiplier. The Infrastructure Architect enables faster product iteration and safer operations by establishing platform standards, reference architectures, and guardrails that reduce cognitive load and variability across teams. This role is also a key control point for risk management: identity, network segmentation, encryption, disaster recovery, and change governance are infrastructure-led concerns with direct business impact.

Primary business outcomes expected: – Reduced incident frequency and severity through standardized, well-tested infrastructure patterns – Faster delivery and onboarding through reusable infrastructure building blocks and automation – Improved security posture and compliance auditability via secure-by-design architecture and policy-as-code guardrails – Measurable reduction or control of infrastructure cost through right-sizing, lifecycle management, and FinOps alignment – Increased system scalability and resilience to support growth, seasonal load, and regional expansion

3) Core Responsibilities

Strategic responsibilities

1. Define target-state infrastructure architecture aligned to business strategy, product roadmap, and service reliability objectives (SLOs/SLAs).
2. Create and maintain reference architectures (e.g., multi-tier apps, microservices platform baseline, data platform baseline, internal tooling baseline) with clear decision criteria.
3. Establish infrastructure standards and principles (e.g., network segmentation, identity boundaries, encryption requirements, backup retention, container baseline, approved services).
4. Drive infrastructure modernization (e.g., data center exit strategy, cloud adoption, containerization, infrastructure-as-code maturity, platform standardization).
5. Partner with FinOps and leadership on cost strategy (e.g., reserved capacity approach, tagging strategy, budget guardrails, cost allocation model).

Operational responsibilities

6. Architect for operability: logging, monitoring, alerting, backup/restore, DR testing, capacity planning, and operational runbooks.
7. Support major incident reviews (post-incident analysis, root cause themes, corrective action architecture) and ensure durable fixes are implemented.
8. Perform architecture reviews for key initiatives and identify infrastructure risks, dependencies, and sequencing constraints.
9. Guide environment strategy across dev/test/stage/prod including access, data handling, isolation, and promotion processes.
10. Assess and improve change management practices for infrastructure changes (deployment strategies, change windows, automated validation).

Technical responsibilities

11. Design cloud/hybrid network topology: VPC/VNet structure, subnets, routing, DNS, ingress/egress, connectivity to on‑prem, segmentation, and firewall strategy.
12. Design identity and access architecture: IAM model, role boundaries, privileged access management integration, federation/SSO, service identities, secrets management.
13. Define compute and runtime strategy: VMs, containers (Kubernetes), serverless, autoscaling approaches, OS/hardening baselines, golden images.
14. Define data protection architecture: encryption in transit/at rest, key management strategy, backup/restore and retention, immutable backups, DR tiers.
15. Set infrastructure automation patterns: infrastructure-as-code modules, CI/CD for IaC, policy-as-code, configuration management, and drift detection.
16. Evaluate and select infrastructure technologies: cloud services, service mesh, load balancers, WAF, CDNs, observability tooling, and automation frameworks.
17. Ensure performance and scalability by design: capacity models, load testing collaboration, edge caching strategy, and bottleneck remediation.

Cross-functional or stakeholder responsibilities

18. Translate architecture into implementation plans with delivery teams: epics, milestones, acceptance criteria, and measurable outcomes.
19. Align with Security and Compliance on control requirements; provide evidence-ready designs and support audits with technical artifacts.
20. Coach engineering teams on infrastructure patterns and tradeoffs; raise overall architecture literacy through enablement and documentation.

Governance, compliance, or quality responsibilities

21. Run or contribute to Architecture Review Board (ARB) / design reviews: ensure consistent decision-making and manage exceptions with documented risk acceptance.
22. Maintain technology lifecycle guidance (approved/conditional/deprecated) for infrastructure components and services.
23. Define resiliency tiers and DR standards and ensure systems are classified and built to the correct tier.
24. Establish baseline security controls and verify adoption: network controls, identity boundaries, encryption, patching expectations, vulnerability remediation workflows.

Leadership responsibilities (IC-appropriate)

25. Technical leadership without direct reports: influence priorities, align teams, resolve disputes with data, and lead by producing high-quality architecture artifacts.
26. Mentor engineers and junior architects through reviews, pairing on designs, and sharing reusable patterns.
27. Lead cross-team working groups (e.g., cloud landing zone evolution, Kubernetes platform governance, observability standardization).

4) Day-to-Day Activities

Daily activities

• Review architecture/design questions from engineering teams (Slack/Teams, tickets, pull requests for IaC modules).
• Validate that upcoming changes align with standards (network/IAM patterns, tagging, encryption, logging).
• Consult on active delivery work: environment buildouts, connectivity, Kubernetes cluster changes, database platform dependencies, CI/CD for IaC.
• Triage architecture debt and decide what needs immediate mitigation vs backlog prioritization.
• Participate in incident/escalation threads when infrastructure architecture is implicated (routing, DNS, IAM, capacity, cluster issues).

Weekly activities

• Conduct 1–3 formal design/architecture reviews (new service onboarding, major platform changes, DR design, connectivity designs).
• Work with Platform/SRE teams on roadmap items: platform reliability improvements, observability, backup/DR test outcomes, cluster upgrades.
• Review cost and capacity signals with FinOps: top spend drivers, anomalous growth, underutilized resources.
• Update reference documentation and patterns based on lessons learned (e.g., a new standard module for private endpoints).
• Sync with Security: new vulnerabilities, policy changes, audit findings, threat modeling outcomes.

Monthly or quarterly activities

• Refresh target-state architecture roadmaps and dependency maps (landing zone changes, network segmentation phases, identity modernization).
• Participate in quarterly planning (PI planning or equivalent) to align architecture work with product/platform priorities.
• Review platform posture: reliability trends, change failure rate, mean time to recover (MTTR), patch/vulnerability status, DR test results.
• Vendor and tool evaluations as needed (RFP input, PoC oversight, selection criteria, cost/risk analysis).
• Run/participate in architecture governance: ARB cadence, exception reviews, technology lifecycle updates.

Recurring meetings or rituals

• Architecture Review Board (weekly/biweekly)
• Platform Engineering/SRE roadmap review (weekly)
• Security risk review / controls alignment (biweekly/monthly)
• FinOps cost review (weekly/monthly depending on spend maturity)
• Incident review / problem management review (weekly)

Incident, escalation, or emergency work (when relevant)

• Join Severity 1–2 incident bridges when infrastructure is suspected (IAM, network, DNS, Kubernetes control plane, cloud provider disruptions).
• Provide rapid options analysis: rollback vs mitigation, blast radius reduction, safe-mode designs.
• Lead or co-lead technical problem statements for post-incident corrective actions (architecture-level fixes, not just tactical patches).
• Trigger emergency change governance when architectural controls must be updated (e.g., rotating compromised credentials, emergency segmentation).

5) Key Deliverables

Infrastructure Architects are measured by what they make clearer, safer, faster, and more repeatable. Common deliverables include:

Architecture artifacts

• Target-state infrastructure architecture (current vs future state, principles, sequencing)
• Reference architectures for common workload types (web/API services, event-driven, data processing, internal tools)
• Cloud landing zone architecture documentation (accounts/subscriptions, network structure, identity model, guardrails)
• Resiliency and DR architecture (RTO/RPO tiers, failover patterns, testing plans, runbooks)
• Network architecture diagrams (segmentation, connectivity, ingress/egress, DNS, firewall policies)
• Identity and access architecture (RBAC patterns, role boundaries, service identities, PAM integration)

Standards, policies, and governance

• Infrastructure standards and design principles (must/should/may)
• Policy-as-code baseline (guardrails for tagging, encryption, public exposure, logging)
• Architecture decision records (ADRs) for major choices and tradeoffs
• Exception/risk acceptance records with expiry and compensating controls
• Technology lifecycle catalog (approved, conditional, deprecated)

Implementation-enabling assets

• Infrastructure-as-code modules (Terraform modules, Helm charts, reusable pipelines)
• Golden path templates (service scaffolds, baseline monitoring, baseline network/IAM)
• Operational runbooks for core platform components (Kubernetes, ingress, secrets, DNS, IAM)
• Observability standards (logging schema, metrics conventions, alerting policies)
• Capacity and cost models (baseline sizing guidance, scaling rules, cost allocation approach)

Reporting and improvement

• Architecture compliance dashboards (adoption of standards, drift, exceptions)
• Reliability improvement plans (prioritized backlog, measurable goals, timeline)
• Post-incident architectural corrective action plans and verification evidence
• Training materials (brown-bags, onboarding guides, playbooks for teams)

6) Goals, Objectives, and Milestones

30-day goals (onboarding and baseline)

• Understand business priorities, major systems, and reliability/security posture.
• Inventory current infrastructure landscape: cloud accounts/subscriptions, network topology, Kubernetes clusters, CI/CD, observability, identity.
• Establish working relationships with Platform/SRE, Security, and key product engineering leads.
• Review top recurring incidents and infrastructure-related problem tickets for patterns.
• Identify and document top 5 architecture risks (e.g., overly permissive IAM, flat network, no DR testing, inconsistent tagging).

60-day goals (early influence and quick wins)

• Produce an initial infrastructure architecture assessment: what’s working, what’s risky, what’s blocking delivery.
• Publish or refresh baseline reference architectures for the top workload types.
• Deliver 2–3 practical improvements:
• Standard IaC module improvements (networking, IAM, tagging)
• Improved guardrails (policy-as-code) with a low-friction developer experience
• Observability baseline improvements (standard dashboards/alerts)
• Implement a lightweight process for architecture reviews and ADRs (if missing or inconsistent).

90-day goals (operationalization)

• Align stakeholders on a target-state architecture and roadmap with sequenced initiatives and measurable outcomes.
• Establish clear resiliency tiers (SLO-aligned) and ensure critical systems are correctly classified with DR requirements.
• Reduce architecture drift: adopt standards in at least one high-impact domain (e.g., IAM boundaries or network segmentation).
• Demonstrate measurable improvement in at least one metric area (e.g., reduced misconfigurations, faster environment provisioning, improved audit evidence readiness).

6-month milestones (standardization and scale)

• Landing zone/guardrails maturity:
• Consistent account/subscription structure
• Standardized network patterns and connectivity
• Policy-as-code guardrails covering common risk domains
• Service onboarding “golden path” adopted by most new services.
• DR testing cadence established for Tier-1 systems with documented results and remediation.
• Cost allocation and tagging compliance improved materially; top cost drivers addressed via right-sizing and lifecycle policies.
• Architecture governance functioning: ARB cadence, ADR discipline, exception management with expiries.

12-month objectives (business outcomes)

• Reliability uplift attributable to infrastructure improvements (fewer Sev1/Sev2 incidents; faster recovery).
• Security posture uplift (reduced critical misconfigurations, better least privilege, improved audit outcomes).
• Faster delivery with reduced cycle time for environment provisioning and platform onboarding.
• Standardized platform components: fewer bespoke patterns, better reuse, lower operational burden.
• Demonstrated cost efficiency improvements (unit cost reduction, reduced waste, improved spend predictability).

Long-term impact goals (sustained architectural advantage)

• Infrastructure becomes a product-like platform with clear interfaces, self-service, and guardrails.
• Architecture decisions are documented, repeatable, and resilient to team churn.
• The organization can expand (regions, scale, acquisitions) with predictable infrastructure integration patterns.
• Technical risk is proactively managed through lifecycle and governance, not reactively via incidents.

Role success definition

The Infrastructure Architect is successful when delivery teams can ship and operate services faster and safer because infrastructure patterns are clear, reusable, secure-by-default, and operationally sound—and when leadership has confidence that infrastructure risk and spend are actively managed.

What high performance looks like

• Creates pragmatic standards that teams adopt voluntarily because they are easier than bespoke alternatives.
• Anticipates scaling, compliance, and operability needs before they become incidents or audit findings.
• Produces architecture artifacts that are actionable (tied to modules, runbooks, and roadmaps), not just diagrams.
• Builds strong cross-functional trust and reduces friction between Security, Operations, and Engineering.
• Uses data (incidents, cost, performance, adoption) to prioritize work and demonstrate impact.

7) KPIs and Productivity Metrics

The framework below balances architecture “output” (artifacts and enablement) with measurable “outcomes” (reliability, security, speed, cost). Targets vary by maturity; example benchmarks are illustrative.

Metric name	What it measures	Why it matters	Example target / benchmark	Frequency
Reference architecture adoption rate	% of new workloads using approved patterns/modules	Indicates standardization and reduced bespoke risk	70–90% of new services follow golden path	Monthly
IaC module reuse ratio	Reuse vs custom per team/project	Higher reuse lowers defects and speeds delivery	60%+ infra changes via shared modules	Monthly
Architecture review throughput	# of reviews completed with decisions recorded	Ensures governance without becoming a bottleneck	10–25 reviews/month with ADRs	Monthly
ADR completeness and freshness	ADRs exist for major decisions and are up to date	Reduces tribal knowledge and rework	90% of major decisions have ADRs	Quarterly
Infrastructure change failure rate	% of infra changes causing incidents/rollbacks	Strong proxy for architecture quality and testing	<5–10% (maturity dependent)	Monthly
Mean time to recover (MTTR) for infra incidents	Time to restore service when infra-related incidents occur	Measures resilience and operability	Improve by 20–30% YoY	Monthly/Quarterly
Sev1/Sev2 incident rate attributable to infrastructure	Count and trend of major incidents with infra root causes	Direct business reliability impact	Downward trend quarter-over-quarter	Monthly
Policy compliance rate (guardrails)	% resources compliant with required controls (encryption, tags, public exposure)	Reduces security/compliance risk	90%+ compliance for critical controls	Weekly/Monthly
Critical misconfiguration rate	# of critical findings (e.g., public storage, overly permissive IAM)	Prevents breaches and audit failures	Near-zero; time-boxed remediation	Weekly
Vulnerability remediation lead time (infra components)	Time from critical CVE to patch/mitigation in images/clusters	Reduces exploitability	<7–14 days for critical issues	Weekly
DR test pass rate (Tier-1)	% of DR tests meeting RTO/RPO	Validates resilience assumptions	90%+ pass; gaps tracked to closure	Quarterly
Backup restore success rate	Success and time to restore representative datasets	Confirms backups are usable	>95% restore success in testing	Monthly/Quarterly
Environment provisioning lead time	Time to provision compliant environments (accounts, network, baseline tooling)	Delivery speed and onboarding efficiency	Hours/days vs weeks; trend down	Monthly
Cloud cost variance vs budget	Actual vs expected spend for tagged cost centers	Spend predictability and governance	Within ±5–10% for mature orgs	Monthly
Unit cost indicator (context-specific)	Cost per request, per tenant, per build minute, etc.	Enables scalable growth without runaway cost	Improve by 10–20% YoY	Monthly/Quarterly
% spend properly allocated (tagging)	Portion of spend attributed to owners/services	Enables FinOps action	90–95% spend allocated	Monthly
Platform availability (shared services)	Availability of critical platform components (DNS, ingress, CI runners)	Platform reliability multiplier	99.9%+ depending on tier	Monthly
Observability coverage	% critical services with standard metrics/logs/alerts	Faster detection and recovery	80–90% coverage for tiered services	Quarterly
Stakeholder satisfaction (engineering)	Surveyed satisfaction with platform/architecture support	Ensures architecture is enabling, not blocking	≥4.2/5 satisfaction	Quarterly
Security stakeholder satisfaction	Confidence in guardrails and evidence readiness	Audit and risk outcomes	Positive trend; fewer exceptions	Quarterly
Architecture exception backlog	# exceptions past expiry / without mitigation	Measures governance effectiveness	<5% exceptions overdue	Monthly
Delivery predictability impact (qual/quant)	Reduced delays due to infra blockers	Demonstrates business enablement	Fewer escalations; improved lead time	Quarterly
Knowledge enablement	# sessions, playbooks, onboarding assets delivered	Scales architectural capability	1–2 enablement events/month	Monthly

Notes on measurement: – Where possible, connect metrics to existing telemetry: ticketing systems, CI/CD logs, cloud security posture tools, incident management, and cost dashboards. – Targets should be set by maturity baseline; the architect should first measure, then improve.

8) Technical Skills Required

Must-have technical skills

Skill	Description	Typical use in the role	Importance
Cloud infrastructure architecture	Designing infrastructure on major clouds (AWS/Azure/GCP) including networking, compute, storage	Landing zones, reference architectures, migrations	Critical
Networking fundamentals and cloud networking	Routing, DNS, load balancing, TLS, firewalls, segmentation, private connectivity	VPC/VNet design, ingress/egress, hybrid connectivity	Critical
Identity and access management (IAM)	Role design, least privilege, federation, service identities, secrets	Secure access patterns, guardrails, incident response	Critical
Infrastructure-as-Code (IaC)	Declarative provisioning, modularization, state management, drift control	Terraform/CloudFormation/Bicep modules, pipelines	Critical
Kubernetes and container platform basics	Core concepts: clusters, ingress, networking, security contexts, scaling	Advising platform standards, reviewing cluster designs	Important (often Critical in container-heavy orgs)
Observability fundamentals	Metrics/logs/traces, alerting design, SLI/SLO concepts	Ensuring operability, standard dashboards, incident readiness	Critical
Security-by-design	Threat modeling mindset, encryption, key mgmt, secure defaults	Guardrails, baseline architectures, risk reviews	Critical
Reliability engineering fundamentals	HA patterns, redundancy, failover, capacity planning, DR	Resiliency tiers, RTO/RPO, incident prevention	Critical
Systems design and performance	Bottlenecks, scaling strategies, caching/CDN, queuing	Non-functional requirements and design validation	Important

Good-to-have technical skills

Skill	Description	Typical use in the role	Importance
Hybrid connectivity	VPN, Direct Connect/ExpressRoute, on-prem integration	Data center coexistence, migration phases	Important (context-specific)
Configuration management	OS hardening, patch orchestration, baseline config	Golden images, compliance baselines	Optional to Important
CI/CD for infrastructure	Automated testing/validation for IaC, GitOps patterns	Safe change management for infrastructure	Important
Policy-as-code	Codifying controls (e.g., OPA, cloud-native policy)	Guardrails, audit evidence, preventing misconfigurations	Important
Service mesh / ingress architecture	Traffic management, mTLS, routing, rate limiting	Platform networking and security patterns	Optional (context-specific)
Storage architecture	Block/object/file, lifecycle policies, performance tiers	Data durability, cost optimization	Important
Windows/Linux administration baseline	OS internals, patching, troubleshooting	Root cause analysis and hardening	Important
Disaster recovery orchestration	Failover automation, runbooks, DR drills	Meeting RTO/RPO in practice	Important

Advanced or expert-level technical skills

Skill	Description	Typical use in the role	Importance
Large-scale cloud network design	Multi-account/subscription segmentation, shared services, transitive routing, multi-region	Enterprise landing zone evolution	Important to Critical (scale-dependent)
Advanced Kubernetes operations	Multi-cluster strategy, upgrades, security posture, network policies	Platform governance and resilience	Optional to Important
Zero Trust and identity-centric design	Beyond perimeter security; continuous verification	Segmentation, access patterns, sensitive systems	Important
High-availability and multi-region design	Active-active, active-passive, data replication patterns	Tier-1 services, global expansion	Important
FinOps engineering	Unit economics, cost allocation, optimization levers	Designing cost-aware architectures	Important
Architecture governance models	ARB design, exception management, standards lifecycle	Operating model excellence	Important
Complex incident analysis	Cross-domain infra debugging, systemic fixes	Preventing recurrence, reducing MTTR	Important

Emerging future skills for this role (next 2–5 years)

Skill	Description	Typical use in the role	Importance
Platform engineering product mindset	Treating infrastructure as a product with SLAs, roadmaps, DX metrics	Golden paths, self-service platforms	Important
Confidential computing / advanced workload isolation	Hardware-backed enclaves and sensitive workload patterns	Regulated workloads, key protection	Optional (industry-dependent)
Supply chain security for infrastructure	Provenance, signing, artifact integrity for IaC/images	Reducing tampering risk	Important
Automated compliance evidence pipelines	Continuous controls monitoring and evidence generation	Audit readiness at scale	Important
AI-assisted ops and architecture analytics	Pattern detection, anomaly detection, AI copilots for infra	Faster triage and design iteration	Optional to Important

9) Soft Skills and Behavioral Capabilities

Systems thinking and tradeoff judgment

• Why it matters: Infrastructure architecture is a web of dependencies (network, identity, runtime, tooling). Local optimizations often create systemic risk.
• How it shows up: Identifies second-order effects (e.g., tighter IAM impacts CI pipelines; segmentation impacts latency and troubleshooting).
• Strong performance looks like: Makes explicit tradeoffs (cost vs resilience; speed vs control), documents rationale, and creates reversible decisions where possible.

Executive-ready communication

• Why it matters: Infrastructure investments must be justified in business terms (risk, reliability, cost, delivery speed).
• How it shows up: Presents options clearly, with impact, timelines, and cost/risk framing.
• Strong performance looks like: Produces concise narratives and diagrams that leadership can act on; avoids jargon-only explanations.

Influencing without authority

• Why it matters: Architects often don’t “own” teams; they align and enable them.
• How it shows up: Builds coalitions, negotiates standards, handles objections, and moves work forward through shared incentives.
• Strong performance looks like: Standards are adopted because they reduce friction and improve outcomes, not because of mandates.

Pragmatism and delivery orientation

• Why it matters: Pure “ivory tower” architecture fails; teams need implementable patterns.
• How it shows up: Pairs architecture docs with modules, examples, and migration paths.
• Strong performance looks like: Incremental improvements that compound; avoids “big bang” rewrites unless required.

Risk management mindset

• Why it matters: Infrastructure choices define the organization’s attack surface and outage modes.
• How it shows up: Surfaces risks early, proposes mitigations, sets expiry dates on exceptions.
• Strong performance looks like: Fewer surprise audit findings and fewer preventable incidents.

Conflict resolution and facilitation

• Why it matters: Security, Ops, and Product teams have competing priorities.
• How it shows up: Runs productive reviews, keeps discussions evidence-based, and finds workable compromises.
• Strong performance looks like: Disagreements end in documented decisions and aligned next steps.

Coaching and enablement

• Why it matters: Architecture scales through people, not documents.
• How it shows up: Mentors engineers, runs enablement sessions, and creates learning assets.
• Strong performance looks like: Teams independently apply patterns correctly; fewer repetitive questions over time.

Operational calm under pressure

• Why it matters: Major incidents require clarity, speed, and safe decision-making.
• How it shows up: Provides crisp guidance during incidents; avoids speculative changes that increase blast radius.
• Strong performance looks like: Faster restoration and durable corrective actions post-incident.

10) Tools, Platforms, and Software

Tools vary by organization; the list below reflects common enterprise patterns for Infrastructure Architects. Items are labeled Common, Optional, or Context-specific.

Category	Tool, platform, or software	Primary use	Commonality
Cloud platforms	AWS / Microsoft Azure / Google Cloud	Core infrastructure hosting and managed services	Common (at least one)
Cloud management	AWS Organizations / Azure Management Groups	Multi-account/subscription governance	Common
Networking	Cloud native networking (VPC/VNet), Transit Gateway / Virtual WAN	Segmentation, routing, shared connectivity	Common
DNS	Route 53 / Azure DNS / Cloud DNS	Name resolution, routing policies	Common
Load balancing	ALB/NLB / Azure Load Balancer / GCLB	L4/L7 traffic distribution	Common
CDN / Edge	CloudFront / Azure Front Door / Cloud CDN	Performance and DDoS resilience	Optional (context-specific)
WAF / DDoS	AWS WAF/Shield / Azure WAF/DDoS	Perimeter protection	Common in internet-facing contexts
Containers	Kubernetes (EKS/AKS/GKE)	Container orchestration platform	Common
Container tooling	Helm, Kustomize	Kubernetes packaging and configuration	Common
GitOps (optional)	Argo CD / Flux	Declarative deployment workflows	Optional
IaC	Terraform	Provisioning infrastructure with reusable modules	Common
IaC alternatives	CloudFormation / Bicep / Pulumi	Native or alternative IaC approaches	Context-specific
CI/CD	GitHub Actions / GitLab CI / Jenkins / Azure DevOps	Automated build/deploy for apps and IaC	Common
Source control	GitHub / GitLab / Bitbucket	Version control for IaC, ADRs, docs	Common
Observability	Prometheus, Grafana	Metrics collection and visualization	Common
Observability suites	Datadog / New Relic / Dynatrace	Unified monitoring/APM	Optional (context-specific)
Logging	ELK/Elastic, OpenSearch, CloudWatch/Log Analytics	Centralized logs and queries	Common
Tracing	OpenTelemetry	Standardized traces and instrumentation	Common (in modern stacks)
Incident mgmt	PagerDuty / Opsgenie	On-call and incident coordination	Common
ITSM	ServiceNow / Jira Service Management	Change, incident, request workflows	Context-specific (more enterprise)
Security posture	Wiz / Prisma Cloud / Defender for Cloud	CSPM, misconfiguration detection	Optional to Common (scale-dependent)
Secrets mgmt	HashiCorp Vault / AWS Secrets Manager / Azure Key Vault	Secret storage and access patterns	Common
Key management	KMS / Key Vault / Cloud KMS, HSM	Encryption keys, rotation, compliance	Common
Policy-as-code	OPA/Gatekeeper, Conftest	Admission control and policy testing	Optional
Cloud policy	AWS Config / SCPs / Azure Policy	Guardrails and compliance	Common
Vulnerability scanning	Trivy, Snyk, Qualys	Image/host scanning and reporting	Context-specific
Collaboration	Confluence / SharePoint / Notion	Architecture documentation and standards	Common
Diagramming	Lucidchart / Visio / Draw.io	Architecture and network diagrams	Common
Project tracking	Jira	Roadmaps, epics, backlog	Common
FinOps	CloudHealth / Apptio / native cost tools	Cost allocation, optimization	Optional (context-specific)
Automation/scripting	Python, Bash, PowerShell	Glue automation, investigations, tooling	Common

11) Typical Tech Stack / Environment

Infrastructure Architects operate across multiple layers. A “typical” modern environment may include:

Infrastructure environment

• Cloud-first with possible hybrid elements:
• Multi-account/subscription structure (dev/test/prod separation; shared services)
• Centralized networking (hub/spoke or shared VPC/VNet patterns)
• Private connectivity (VPN or dedicated links) if enterprise integration is needed
• Mix of compute:
• Kubernetes clusters for microservices
• VM-based workloads for legacy or specialized needs
• Serverless for event-driven or lightweight services (context-dependent)
• Storage and data services:
• Object storage for logs/artifacts/backups
• Managed databases (RDS/Aurora, Cloud SQL, Cosmos DB, etc.) and managed cache (Redis)

Application environment (as it relates to infrastructure)

• Microservices and APIs with ingress controllers and API gateways (context-specific)
• CI/CD pipelines with environment promotion practices (dev → stage → prod)
• Runtime security baselines and standard telemetry (logs/metrics/traces)

Data environment (infrastructure interface)

• Data lake/warehouse platforms (context-specific)
• Streaming/messaging services (Kafka/managed equivalents)
• Backup/restore integration and retention policies aligned to data classification

Security environment

• Identity provider integration (Okta/Azure AD or similar)
• Central secrets management and key management
• CSPM tooling and continuous controls monitoring
• Network segmentation, WAF/DDoS, and zero trust patterns where applicable

Delivery model

• Platform Engineering and/or SRE partnered model:
• Platform teams provide paved roads (golden paths), modules, and shared services
• Product teams consume via self-service, with guardrails and governance
• Infrastructure Architect works as:
• A design authority and enabler
• A reviewer for high-impact changes
• A contributor to shared modules and operational standards

Agile or SDLC context

• Agile delivery with quarterly planning is common
• Change control varies:
• Heavier enterprise ITSM controls for regulated environments
• Lighter, automation-heavy governance for product organizations

Scale or complexity context

• Typically supports:
• Multiple product teams
• Multiple environments
• High availability requirements for customer-facing services
• Audit or customer assurance needs (SOC 2/ISO 27001 patterns), depending on market

Team topology

• Works closely with:
• Platform Engineering (cloud foundations, Kubernetes, CI/CD enablement)
• SRE/Operations (reliability, incident response)
• Security Engineering (controls, threat modeling, vulnerability response)
• Network engineering (if separate)
• Application and solution architects

12) Stakeholders and Collaboration Map

Internal stakeholders

• Head of Architecture / Chief Architect (likely manager line): alignment to enterprise architecture direction, governance, portfolio priorities.
• Director/Head of Infrastructure or Platform Engineering: roadmaps, standard modules, operational priorities, reliability outcomes.
• SRE / Operations leaders: operability requirements, incident learnings, on-call readiness, change management.
• Security Engineering / CISO org: security standards, risk assessments, audit evidence, guardrails, exception handling.
• Product Engineering Managers & Tech Leads: workload needs, delivery timelines, adoption of patterns, constraints and tradeoffs.
• ITSM / Service Management: change controls, incident/problem processes (enterprise contexts).
• FinOps / Finance partners: budgets, chargeback/showback, cost optimization priorities.
• Compliance / Risk / Internal Audit: control requirements and evidence readiness.
• Procurement / Vendor Management: tool selection, licensing, contracts, risk reviews.

External stakeholders (as applicable)

• Cloud providers / TAMs: best practices, support escalations, architecture validations.
• Vendors (observability, security, networking): product capabilities, roadmaps, licensing constraints.
• External auditors / customer assurance: SOC2/ISO evidence, customer security questionnaires.

Peer roles

• Application Architect / Solution Architect
• Security Architect
• Data Architect
• Enterprise Architect
• Network Architect (in larger orgs)
• Platform Product Manager (in platform-as-product orgs)

Upstream dependencies

• Business strategy and product roadmap
• Security policies and risk appetite
• Budget constraints and procurement lead times
• Existing platform capabilities and technical debt constraints

Downstream consumers

• Product engineering squads delivering services
• Platform teams implementing shared capabilities
• SRE/Operations teams supporting on-call and reliability
• Security/compliance teams relying on controls and evidence

Nature of collaboration

• Consultative + governance: helps teams design, then ensures critical controls and standards are met.
• Hands-on enablement: contributes to IaC modules and templates to reduce adoption friction.
• Escalation support: joins incidents and high-severity escalations where infrastructure is implicated.

Typical decision-making authority

• Recommends and sets standards within architecture governance scope
• Approves designs for critical/shared components (often via ARB)
• Provides risk-based exceptions with documented mitigations (often requiring security sign-off)

Escalation points

• Director/Head of Architecture: unresolved cross-team conflicts, priority tradeoffs, standard exceptions with broad impact
• CISO/Security leadership: high-risk exceptions, control deviations, incident-related security decisions
• Infrastructure/Platform leadership: major platform changes, capacity risk, vendor/tool investments

13) Decision Rights and Scope of Authority

Decision rights vary by operating model; the following is a realistic enterprise pattern for an Infrastructure Architect (senior IC).

Decisions the role can typically make independently

• Recommend and publish reference architectures and implementation guidance (within established standards).
• Define IaC module design patterns (structure, inputs/outputs, versioning approach) in collaboration with platform teams.
• Choose tactical implementation details inside an approved architecture (e.g., subnet sizing approach, naming conventions).
• Set documentation standards for diagrams, ADRs, and operational readiness checklists.
• Propose deprecation guidance and migration paths for outdated patterns (subject to governance acceptance).

Decisions requiring team or peer approval (platform/security/ARB)

• Network segmentation changes affecting multiple domains or teams.
• IAM model changes affecting access boundaries, federation, or privilege management.
• Kubernetes baseline changes (admission policies, ingress standards, cluster architecture).
• Observability standards that alter alerting policies or on-call load.
• Policy-as-code guardrails that may block deployments (need alignment on developer experience).

Decisions requiring manager/director/executive approval

• Material cloud architecture shifts (multi-region strategy, provider strategy, landing zone restructure).
• Vendor selection and contract commitments (security tools, observability platforms, SD-WAN).
• Budget-impacting changes exceeding thresholds (e.g., new shared services, major DR investments).
• Exception approvals with high risk or customer impact (often requires CISO or risk sign-off).
• Organization-wide mandates (e.g., forced migration timelines, platform standardization enforcement).

Budget, vendor, delivery, hiring, and compliance authority

• Budget: typically influences through business cases; may own small discretionary PoC spend (context-specific).
• Vendor: participates in evaluation and technical due diligence; rarely final signatory.
• Delivery: shapes technical scope and sequencing; does not “own” product delivery dates but can escalate risks.
• Hiring: may interview and evaluate platform/SRE candidates; rarely owns headcount decisions.
• Compliance: accountable for providing architecture artifacts/evidence; final compliance sign-off usually rests with Security/Risk.

14) Required Experience and Qualifications

Typical years of experience

• 8–12 years in infrastructure engineering, SRE, cloud engineering, platform engineering, or systems/network engineering
• 2–5 years operating at an architecture/design-lead level (formal title may vary)

Education expectations

• Bachelor’s degree in Computer Science, Engineering, Information Systems, or equivalent practical experience (common expectation).
• Advanced degrees are optional; not typically required.

Certifications (relevant but not mandatory)

Certifications can help validate baseline knowledge; real-world design and operational experience remains the strongest signal.

• Common (helpful):
• AWS Solutions Architect – Associate/Professional
• Azure Solutions Architect Expert
• Google Professional Cloud Architect
• Optional (context-specific):
• Kubernetes certifications (CKA/CKAD) if Kubernetes-heavy
• Security certifications (e.g., CISSP) if role is security-adjacent
• HashiCorp Terraform certification (useful but not definitive)
• ITIL Foundation (enterprise ITSM contexts)

Prior role backgrounds commonly seen

• Senior Cloud Engineer / Cloud Platform Engineer
• SRE / Senior SRE
• Systems Engineer / Infrastructure Engineer (with cloud transition experience)
• Network Engineer/Architect (with cloud networking depth)
• DevOps Engineer (with strong infra foundation, not only CI/CD)
• Platform Engineering Lead (IC track)

Domain knowledge expectations

• Software/IT context with production systems and on-call realities
• Experience supporting customer-facing services with uptime and performance needs
• Understanding of compliance drivers (SOC 2/ISO 27001/HIPAA/PCI) is valuable but varies by company

Leadership experience expectations (IC role)

• Proven ability to lead cross-team initiatives without direct authority
• Mentoring and enablement experience (reviews, guidance, templates)
• Clear communication to both engineers and non-technical stakeholders

15) Career Path and Progression

Common feeder roles into this role

• Senior Infrastructure Engineer / Senior Cloud Engineer
• Senior SRE or SRE lead (IC)
• Senior Platform Engineer
• Network Engineer transitioning into cloud architecture
• DevOps Engineer with strong infra depth and governance mindset

Next likely roles after this role

• Principal Infrastructure Architect (broader scope, multi-domain authority, longer horizon)
• Lead/Principal Platform Architect (platform-as-product, golden paths at scale)
• Enterprise Architect (broader portfolio, business capability mapping)
• Security Architect (if deep specialization in identity/network security emerges)
• Director of Platform/Infrastructure (management track; depends on leadership aptitude and org needs)

Adjacent career paths

• SRE leadership track (Reliability Architect, Head of SRE)
• Cloud FinOps Architect / Cost Optimization Lead
• Network Architect (deep specialization)
• Resilience/DR Architect (BCP/DR specialization)
• Observability/Telemetry Architect

Skills needed for promotion (Infrastructure Architect → Principal)

• Owns multi-year target-state across multiple domains (network + IAM + runtime + governance).
• Demonstrates measurable business outcomes (incident reduction, faster onboarding, cost/unit reduction).
• Establishes and runs governance mechanisms that scale (ARB maturity, exception lifecycle, standards adoption).
• Coaches other architects; raises architecture quality across the organization.
• Handles executive-level tradeoffs and influences investment decisions.

How this role evolves over time

• Early: focus on stabilizing foundations, standardizing patterns, and reducing major risks.
• Mid: mature the platform into self-service and increase automation/policy-as-code.
• Later: optimize for global scale, multi-region resilience, and continuous compliance with strong developer experience.

16) Risks, Challenges, and Failure Modes

Common role challenges

• Balancing standardization with team autonomy: too much control slows delivery; too little creates sprawl and risk.
• Legacy constraints: inherited network designs, flat IAM, or inconsistent environments create migration complexity.
• Hidden dependencies: fragile integrations (DNS, identity federation, shared CI runners) can derail planned changes.
• Conflicting priorities: Security wants tighter controls; Product wants speed; Finance wants cost reductions.
• Cloud complexity: service limits, multi-region tradeoffs, and managed-service nuances require deep expertise.

Bottlenecks

• Architecture review process becoming a gate rather than an enablement function
• Lack of reusable modules causing repeated bespoke implementation work
• Limited platform team bandwidth to implement architectural improvements
• Procurement delays for essential tooling
• Incomplete ownership model for shared services

Anti-patterns

• Diagram-only architecture: no modules, no runbooks, no enforcement; results in low adoption.
• One-size-fits-all mandates: forcing every workload into the same pattern despite different needs.
• Over-engineering: excessive multi-region complexity for non-critical services, increasing cost and failure modes.
• Under-engineering: weak IAM or flat networking that later blocks compliance and increases breach risk.
• Exception sprawl: too many “temporary” exceptions that become permanent, eroding standards.

Common reasons for underperformance

• Doesn’t understand operational reality (on-call, incident patterns, maintenance constraints).
• Communicates in abstractions; fails to provide actionable guidance.
• Creates friction with rigid governance without providing paved roads.
• Lacks influence skills; cannot align stakeholders or drive adoption.
• Neglects cost and treats cloud spend as “someone else’s problem.”

Business risks if this role is ineffective

• Increased outages and longer recovery times
• Security incidents from misconfigurations and weak access controls
• Audit failures or inability to close control gaps
• Runaway cloud spend and poor cost allocation visibility
• Slower product delivery due to inconsistent environments and repeated infra reinvention
• Vendor/tool sprawl and fragmented operational tooling

17) Role Variants

Infrastructure Architect scope changes materially by organizational context.

By company size

• Small company / startup:
• More hands-on building (writing Terraform, managing clusters directly)
• Less formal governance; architecture reviews are lightweight
• Faster iteration, but higher risk of ad hoc patterns
• Mid-size scale-up:
• Mix of hands-on enablement and formalization
• Strong focus on standardization, landing zone maturity, and platform team enablement
• Cost and reliability become board-level concerns
• Large enterprise:
• More stakeholders, heavier compliance, more formal ARB/ITSM
• Hybrid and complex network/identity landscapes are common
• Role may specialize (Network Architect, IAM Architect, DR Architect)

By industry

• Regulated (finance/healthcare/critical infrastructure):
• Stronger emphasis on evidence, controls, segregation of duties, audit trails
• More formal DR/BCP requirements and testing
• More constraints on data residency and encryption/key management
• SaaS / digital-native:
• High emphasis on multi-tenant resilience, scalability, automation, and developer experience
• Strong observability and SLO-driven operations
• Internal IT / enterprise platforms:
• Greater focus on identity, endpoint/network integration, ITSM, and service catalog patterns

By geography

• Regions may influence:
• Data residency requirements (e.g., EU/UK) and encryption key locality
• Vendor availability and cloud region coverage
• On-call coverage models and operational handoffs Rather than assuming one geography, strong practice is to design architecture that supports regional expansion with clear controls and repeatable landing zone patterns.

Product-led vs service-led company

• Product-led: optimize for self-service, paved roads, platform SLAs, developer productivity metrics.
• Service-led / consultancy / MSP: more client-specific architectures, stronger documentation deliverables, and broader vendor/tool exposure.

Startup vs enterprise

• Startup: bias toward speed and minimal viable controls; architect must prevent irreversible shortcuts.
• Enterprise: bias toward risk management and process; architect must prevent governance from stalling delivery.

Regulated vs non-regulated

• Regulated: continuous controls monitoring, audit evidence pipelines, stricter change management.
• Non-regulated: lighter governance, but security and reliability still matter; focus on guardrails that enable speed.

18) AI / Automation Impact on the Role

Tasks that can be automated (now or near-term)

• Drafting and maintaining documentation: first-pass architecture docs, ADR templates, runbook scaffolds (human review required).
• Policy enforcement and compliance checks: policy-as-code with automated drift detection and remediation workflows.
• Cost anomaly detection: AI-assisted detection of spend spikes and unused resources.
• Operational noise reduction: alert correlation, deduplication, and suggested runbooks.
• Infrastructure testing: automated validation of IaC, security scanning, and environment conformance checks.

Tasks that remain human-critical

• Tradeoff decisions tied to business context (risk appetite, customer expectations, roadmap constraints).
• Stakeholder alignment and influencing across Security, Engineering, and Finance.
• Architecture strategy and sequencing (what to standardize first, how to migrate safely).
• Complex incident leadership where ambiguity is high and decisions carry risk.
• Exception handling with compensating controls and accountability.

How AI changes the role over the next 2–5 years

• Faster architecture iteration: architects will spend less time producing first drafts and more time validating, aligning, and ensuring implementation quality.
• Higher expectations for continuous compliance: AI/automation will make it more feasible to continuously validate controls; auditors and customers will increasingly expect this maturity.
• Shift toward platform product management behaviors: as automation increases, the differentiator becomes designing “paved roads” with great developer experience and measurable adoption.
• Increased governance sophistication: automated evidence, automated guardrails, and automated exception expiry enforcement become standard.

New expectations caused by AI, automation, or platform shifts

• Ability to evaluate AI-driven ops tools critically (false positives, trust boundaries, data handling).
• Stronger emphasis on policy-as-code, software supply chain integrity, and secure automation (who/what can change infrastructure).
• Architects will be expected to define and measure developer experience outcomes of infrastructure choices (time-to-first-deploy, onboarding time, self-service success rate).

19) Hiring Evaluation Criteria

What to assess in interviews

1. Architecture depth across network, IAM, compute, and operations – Can the candidate design a secure, scalable landing zone and explain tradeoffs?
2. Reliability and operability mindset – Do they design with SLOs, failure modes, and incident learnings in mind?
3. Security-by-design – Can they reason about least privilege, segmentation, encryption, secrets, and threat modeling?
4. Infrastructure-as-code maturity – Can they design reusable modules, manage state safely, and implement validation?
5. Governance that enables delivery – Can they run reviews without becoming a bottleneck? How do they handle exceptions?
6. Cost awareness (FinOps) – Do they incorporate cost into design decisions and propose measurable optimizations?
7. Communication and influence – Can they align teams and communicate to executives?

Practical exercises or case studies (recommended)

Case Study A: Landing Zone + Workload Onboarding Design (60–90 minutes) – Prompt: Design an AWS/Azure landing zone for a SaaS product with dev/stage/prod, multiple teams, and compliance expectations. – Evaluate: – Account/subscription structure, network segmentation, IAM model – Logging/monitoring baseline – Guardrails/policy-as-code approach – Onboarding workflow and reusable modules

Case Study B: Resilience and DR Design (45–60 minutes) – Prompt: Define RTO/RPO tiers and propose DR architecture for a Tier-1 API and a Tier-3 internal service. – Evaluate: – Correct tiering, cost tradeoffs, testing approach – Data replication and failover strategy – Runbooks and validation

Case Study C: Incident-driven Architecture Improvement (30–45 minutes) – Prompt: Given a summary of repeated outages (DNS misconfig + IAM drift), propose durable architecture changes. – Evaluate: – Root cause themes, guardrails, change management improvements – Metrics to validate improvement

Strong candidate signals

• Provides clear, structured designs with explicit tradeoffs and assumptions.
• Demonstrates real production experience: incidents, migrations, scaling challenges.
• Understands how to make standards adoptable (modules, templates, documentation, enablement).
• Shows security fluency beyond “enable encryption” (keys, rotation, identity boundaries).
• Uses metrics and feedback loops (cost dashboards, compliance posture, incident trends).
• Communicates crisply to both technical and non-technical stakeholders.

Weak candidate signals

• Only theoretical knowledge; cannot discuss real operational failure modes or incident learnings.
• Focuses solely on tooling rather than principles and outcomes.
• Proposes heavy processes without automation; or automation without governance.
• Ignores cost considerations or treats them as afterthoughts.
• Cannot explain IAM and network segmentation clearly.

Red flags

• Advocates for pervasive admin access or overly permissive policies as the norm.
• Dismisses compliance/security requirements instead of designing workable controls.
• Cannot describe how they would test DR assumptions (only “we have backups”).
• Recommends major architectural rewrites without migration strategy or risk controls.
• Consistently blames other teams; shows low collaboration maturity.

Scorecard dimensions

Use a standardized scorecard to reduce bias and ensure consistent evaluation.

Dimension	What “meets bar” looks like	What “exceeds” looks like
Cloud architecture	Sound baseline designs; correct service selection	Multi-region, multi-account strategy with strong rationale
Networking	Correct segmentation, routing, ingress/egress patterns	Designs for scale, troubleshooting, and least exposure
IAM & secrets	Clear least-privilege patterns	Strong governance + automation + PAM integration concepts
IaC & automation	Modular IaC, safe workflows	Testing, policy-as-code, drift remediation strategy
Reliability/DR	Clear tiers and practical DR approach	Testing cadence, automation, measurable outcomes
Observability	Standard metrics/logs/alerts approach	SLO-driven design and noise reduction strategies
Security-by-design	Threat-aware design	Proactive controls, continuous compliance thinking
FinOps	Basic cost awareness	Unit economics + allocation strategy + optimization roadmap
Communication	Clear explanation and documentation	Executive-ready narratives and facilitation strength
Collaboration/influence	Works well cross-functionally	Proven adoption and governance success without friction

20) Final Role Scorecard Summary

Category	Summary
Role title	Infrastructure Architect
Role purpose	Design and govern secure, scalable, reliable, and cost-effective infrastructure architectures (cloud/hybrid), enabling delivery teams to build and run services with confidence.
Top 10 responsibilities	1) Define target-state infrastructure architecture and roadmap 2) Create reference architectures and golden paths 3) Design network topology and segmentation 4) Design IAM and secrets patterns 5) Establish IaC standards and reusable modules 6) Ensure operability (observability, runbooks, on-call readiness) 7) Define resiliency tiers and DR architectures 8) Run architecture reviews/ADRs and manage exceptions 9) Partner with Security/Compliance on controls and audits 10) Drive cost-aware architecture with FinOps alignment
Top 10 technical skills	1) Cloud architecture (AWS/Azure/GCP) 2) Cloud networking (routing, DNS, LB, segmentation) 3) IAM/least privilege 4) IaC (Terraform or equivalent) 5) Kubernetes fundamentals 6) Observability (metrics/logs/traces, SLOs) 7) Security-by-design (encryption, secrets, threat mindset) 8) Reliability/DR patterns (RTO/RPO) 9) CI/CD for infrastructure 10) Cost optimization/FinOps fundamentals
Top 10 soft skills	1) Systems thinking 2) Tradeoff judgment 3) Influencing without authority 4) Executive communication 5) Pragmatism/delivery orientation 6) Risk management mindset 7) Facilitation/conflict resolution 8) Coaching and enablement 9) Operational calm under pressure 10) Stakeholder empathy and partnership
Top tools or platforms	Cloud platform (AWS/Azure/GCP), Terraform, Kubernetes (EKS/AKS/GKE), GitHub/GitLab, CI/CD (Actions/Jenkins/Azure DevOps), Observability (Prometheus/Grafana and/or Datadog), Logging (ELK/OpenSearch), Secrets/KMS (Vault/Key Vault/KMS), Cloud policy (Azure Policy/SCPs/AWS Config), Jira/Confluence + Lucidchart/Visio
Top KPIs	Reference architecture adoption, IaC module reuse, infrastructure change failure rate, Sev1/Sev2 infra incident trend, MTTR, policy compliance rate, critical misconfiguration rate, DR test pass rate, environment provisioning lead time, % spend allocated/tag compliance
Main deliverables	Target-state architecture + roadmap, landing zone designs, reference architectures, ADRs, standards/principles, IaC modules/templates, policy-as-code guardrails, DR designs and runbooks, observability standards, architecture compliance dashboards
Main goals	First 90 days: assess, publish baseline patterns, implement quick wins, operationalize reviews. 6–12 months: mature landing zone and guardrails, improve DR testing, reduce incidents/misconfigurations, improve cost allocation and spend control, increase platform onboarding speed.
Career progression options	Principal Infrastructure Architect, Platform Architect, Enterprise Architect, Security Architect (adjacent), Reliability/DR Architect, Director of Platform/Infrastructure (management track)