DEV Community

Cover image for AZ-104 vs AZ-305: admin vs architect (responsibilities, mindset, deliverables)
Boris Gigovic
Boris Gigovic

Posted on

AZ-104 vs AZ-305: admin vs architect (responsibilities, mindset, deliverables)

People compare AZ-104 and AZ-305 like they’re “level 1” and “level 2.” They represent two different jobs.

  • AZ-104 (Azure Administrator) is about operating Azure: keeping services healthy, secure, and consistent day-to-day.
  • AZ-305 (Azure Solutions Architect) is about designing Azure: making tradeoffs, creating patterns, and producing architecture that survives scale, change, and risk.

If you’re planning training (or mapping a team’s roles), the best question isn’t “which is harder?” It’s: Are you responsible for running the platform or for designing what the platform should be?

The simplest framing: operator vs designer

AZ-104: “Make it work, keep it working”

You’re responsible for:

  • implementing resources correctly
  • enforcing baseline governance
  • monitoring and responding to incidents
  • maintaining consistency across subscriptions and environments
  • troubleshooting real issues under time pressure

AZ-305: “Make it make sense”

You’re responsible for:

  • designing the target architecture
  • aligning technical choices with business requirements
  • balancing cost, security, resilience, and delivery speed
  • producing artifacts others can implement and operate
  • creating patterns that scale across teams and time

Responsibilities: what you own in the real world

AZ-104 responsibilities (day-2 operations ownership)

Common ownership areas:

  • Identity and access implementation (RBAC assignments, access hygiene)
  • Resource provisioning and configuration (compute, storage, networking)
  • Backup and recovery operations
  • Monitoring, alerting, and incident response
  • Patch/update processes (where applicable)
  • Cost visibility and basic cost controls
  • Standard runbooks and operational documentation
  • Troubleshooting: “why is this failing right now?”

Success metric: stability, uptime, predictable operations, fewer incidents, faster recovery.

AZ-305 responsibilities (architecture ownership)

Common ownership areas:

  • Requirements translation (business → technical constraints)
  • Landing zone / subscription strategy (management groups, policies, identity model)
  • Network architecture (hub-spoke, segmentation, connectivity patterns)
  • Security architecture (defense-in-depth, identity boundaries, key management)
  • Resilience design (availability zones, DR strategy, RTO/RPO decisions)
  • Data and integration patterns (where data lives, how it moves, how it’s protected)
  • Cost model design (not just “reduce cost,” but “design for cost predictability”)
  • Governance model (guardrails that enable teams without chaos)
  • Architecture documentation and decision records

Success metric: systems that can be implemented and operated safely, with clear tradeoffs and fewer “surprises” later.

Mindset shift: what changes when you move from AZ-104 to AZ-305

1. From “tasks” to “tradeoffs”

Admins execute tasks. Architects make tradeoffs.
Example tradeoffs architects must own:

  • speed vs control (self-service vs approvals)
  • cost vs resilience (single region vs multi-region)
  • simplicity vs flexibility (standard patterns vs bespoke solutions)
  • security vs usability (tight boundaries vs operational friction)

The architect’s job is not to pick the “best” option. It’s to pick the right option for the constraints and document why.

2. From “fixing” to “preventing”

Admins are often measured by how quickly they fix issues.
Architects are measured by how rarely the same class of issue happens again.
That means designing:

  • consistent identity boundaries
  • predictable network routing
  • standardized deployment patterns
  • guardrails that stop risky configurations early

3. From “my subscription” to “the organization”

AZ-104 can be executed within a subscription scope.
AZ-305 thinks across:

  • multiple subscriptions
  • multiple environments (dev/test/prod)
  • multiple teams with different maturity levels
  • long-term operations and ownership

Deliverables: what you produce (and what others depend on)

AZ-104 deliverables (operational outputs)

Typical deliverables:

  • configured resources (VMs, storage, VNets, NSGs, etc.)
  • operational runbooks (“how to restore,” “how to rotate,” “how to respond”)
  • monitoring dashboards and alert rules
  • incident notes and remediation steps
  • baseline documentation for what exists and how it’s managed

These deliverables are execution-focused.

AZ-305 deliverables (architecture outputs)

Typical deliverables:

  • reference architectures (diagrams + rationale)
  • landing zone design (management groups, policies, identity integration)
  • network topology decisions (hub-spoke, DNS strategy, egress control)
  • security model (identity boundaries, key vault usage, logging strategy)
  • resilience plan (DR approach, RTO/RPO targets, failover design)
  • cost model assumptions and guardrails
  • architecture decision records (ADRs) and standards

These deliverables are decision-focused—and they shape how everyone else works.

“What breaks first?” - the admin to architect reality check

If you’ve only done AZ-104 work, the first surprises when stepping into AZ-305 are usually:

Networking complexity (routing, DNS, hybrid connectivity, egress control)

  • Identity boundaries (who owns what, how access is delegated safely)
  • Governance at scale (policies, standardization, exceptions management)
  • Operational ownership (who supports it at 2am, and how that changes design)
  • Cost predictability (not just cost cutting—cost design)

Architects who ignore operations create beautiful diagrams that fail in production.
Admins who ignore architecture create stable systems that don’t scale cleanly.
The best teams connect both.

Who should take which (practical guidance)

AZ-104 is a fit if you:

  • implement and manage Azure resources daily
  • respond to incidents and operational tickets
  • maintain monitoring, backups, and access controls
  • need strong “how Azure works in production” fundamentals

AZ-305 is a fit if you:

  • design solutions and set standards for others
  • own cross-team architecture decisions
  • are accountable for security, governance, and resilience design
  • need to justify tradeoffs to technical and non-technical stakeholders

The common path

Many professionals do:

  1. AZ-104 to build operational credibility
  2. AZ-305 to formalize architecture thinking and decision-making

Train for the role you want to perform

If you’re building an operator foundation, AZ-104 is the right training anchor. If you’re moving into design ownership, AZ-305 is where the mindset shifts.

Related readings

FAQ

Can I do AZ-305 without AZ-104?

You can, but you’ll be weaker in operational realism. AZ-305 decisions land better when you understand what admins will have to run and troubleshoot.

Is AZ-305 just “more Azure services”?

Not really. It’s more about designing systems: governance, networking, identity, resilience, and cost models plus documenting decisions.

Which one helps more for career growth?

AZ-104 strengthens execution roles (admin, cloud ops, platform ops). AZ-305 strengthens design roles (architect, platform architect, cloud lead). The fastest growth usually comes from being able to speak both languages.

Top comments (0)