DES-2T13 Cloud Infrastructure Architect: Retired Dell Cloud Design Skills and the Modern Design Track

DES-2T13 was a Dell Technologies Specialist – Cloud Architect exam for Cloud Infrastructure. Dell retired it on February 2, 2024 and migrated the discipline to D-CI-DS-23, Dell Cloud Infrastructure Design 2023. Candidates preparing today should therefore use the current Dell Cloud Infrastructure Design materials associated with D-CI-DS-23 rather than trying to schedule DES-2T13.

The old exam is still useful because cloud architecture is fundamentally a requirements-and-tradeoffs discipline. DES-2T13 asked candidates to reason about cloud design project phases, workload requirements, service models, virtualization, converged and hyperconverged infrastructure, networking, storage, security, availability, disaster recovery, automation, orchestration, and operational considerations.

The older DEA-2TT4 Cloud Infrastructure and Services exam provides historical foundation context, while cloud deployment models become directly relevant when the discussion reaches public, private, hybrid, and multi-cloud choices. Both topics support the architectural reasoning that underlies Dell’s current cloud-infrastructure design track.

Cloud design starts by translating business outcomes into measurable technical requirements

An architect should begin with the workload and organization rather than a preferred product. Capture availability targets, performance, data sensitivity, regulatory constraints, growth, geographic requirements, recovery objectives, integration dependencies, operating model, and budget. Those requirements determine which cloud patterns are viable.

Nonfunctional requirements need numbers where possible. “Highly available” is not a design input until the team defines acceptable downtime. “Fast” is similarly vague without latency, throughput, or transaction targets. Clear metrics make tradeoffs reviewable and prevent technology choices from being defended only by preference.

Design assumptions should be recorded separately from confirmed facts. If the project assumes a certain growth rate or network latency, that assumption can later be tested. Hidden assumptions are a common source of cloud designs that look complete on paper but fail during implementation.

Deployment and service models should match control, elasticity, and responsibility needs

Public, private, hybrid, and multi-cloud approaches distribute ownership differently. The right choice depends on where workloads can run, what level of control is required, how quickly capacity must scale, and which team is responsible for infrastructure operations. No model is automatically more mature than another.

IaaS, PaaS, and SaaS also change the responsibility boundary. Moving upward in the service stack can reduce infrastructure management but may constrain customization, portability, or low-level controls. Architects should map each requirement to the layer that will satisfy it instead of assuming that “cloud” removes operational responsibility.

Hybrid designs add integration costs that should be explicit: identity, networking, observability, data movement, security policy, and governance must work across environments. The architecture should justify those costs with a real business need.

Workload placement is a decision about characteristics, not organizational fashion

Applications differ in latency sensitivity, data gravity, licensing, hardware dependencies, elasticity, and modernization potential. A good cloud assessment groups workloads by these characteristics before deciding whether to retain, rehost, replatform, refactor, replace, or retire them.

Data-intensive workloads may be constrained by transfer time and egress cost. Legacy applications may depend on fixed network assumptions or unsupported operating systems. Bursty services may benefit from elastic infrastructure. These differences should appear in the placement decision rather than being flattened into a single migration rule.

Architecture documentation should state why each workload belongs where it does and what would cause that decision to change. This makes later optimization possible when costs, technology, or business priorities shift.

Compute, storage, and network designs must be balanced as one capacity system

Cloud infrastructure capacity is multidimensional. CPU and memory sizing can fail if storage latency or network throughput is ignored. Likewise, overprovisioning compute does not fix a storage bottleneck. Architects should model the application path end to end.

Virtualization, converged infrastructure, and hyperconverged systems create different scaling units. Some designs scale compute and storage together, while others allow them to grow independently. This affects both economics and operational flexibility, especially when workload growth is uneven.

Network design includes segmentation, routing, bandwidth, load balancing, east-west traffic, north-south connectivity, and management access. Capacity models should include failure scenarios so the environment remains viable when a link, node, or site is unavailable.

Availability and disaster recovery require explicit failure-state design

High availability protects against expected component or service failures inside an environment, while disaster recovery addresses larger events that require restoration or site transition. They overlap but are not the same. Architects should define which failures the primary design absorbs automatically and which invoke a recovery plan.

RPO and RTO influence replication mode, backup frequency, recovery infrastructure, automation, and cost. A workload needing seconds of data loss tolerance cannot use the same protection pattern as a service that can lose several hours of transactions. Recovery objectives therefore need application-owner approval.

Testing is part of architecture. A failover plan that has never been exercised is an assumption. Schedule recovery tests, define success criteria, and feed the results back into the design.

Security architecture should follow identities, data, and control planes across environments

Cloud security is not a perimeter added after the infrastructure diagram is complete. Identity, privileged access, encryption, key management, segmentation, logging, vulnerability management, and policy enforcement need to be designed alongside compute and network services.

Shared-responsibility boundaries should be documented for every service model. Teams need to know which controls belong to the provider, platform team, application team, and security function. Gaps often appear when each group assumes another group owns the same control.

Data classification can drive placement, encryption, retention, and residency decisions. Treat sensitive data requirements as architectural constraints early, because retrofitting them after migration can be expensive.

Automation and orchestration turn architecture into a repeatable operating model

Cloud designs gain value when provisioning, configuration, scaling, and policy can be executed consistently. Infrastructure as code, templates, orchestration workflows, and configuration management reduce drift and make environments reproducible, but only if versioning and review are part of the process.

Automation should include guardrails. A fast workflow that can deploy insecure or oversized resources simply accelerates mistakes. Policy checks, approved modules, secrets handling, cost controls, and audit logging help automation remain safe at scale.

Operational observability is equally important. Metrics, logs, traces, events, and capacity data should be available from the start so teams can validate whether the deployed environment matches the performance and availability assumptions in the design.

Use DES-2T13 to practice cloud architecture reasoning, then verify against current Dell scope

The lasting value of DES-2T13 is its design method: collect requirements, assess workloads, select service and deployment models, design infrastructure capacity, plan availability, integrate security, and define operations. Those activities remain relevant even as platforms and credential codes evolve.

Current Dell candidates should use the active cloud-infrastructure design materials associated with the modern framework rather than trying to schedule DES-2T13. The old exam can still be useful for scenario practice, especially when questions require choosing between technically plausible designs based on business constraints.

Architects should also revisit designs after deployment. Actual utilization, incident history, cost, and user experience provide evidence that can confirm or challenge the original assumptions. Architecture is strongest when it is treated as a lifecycle rather than a one-time document.

Cloud economics deserves explicit treatment in every design review. Estimate steady-state and peak resource consumption, licensing, data transfer, support, and operational staffing rather than comparing only hardware or subscription line items. A technically elegant design can still be unsuitable if its cost model does not match the workload.

Finally, avoid using cloud terminology as a substitute for architecture. Labels such as hybrid or multi-cloud describe placement, not quality. The value comes from a design that can explain responsibilities, dependencies, recovery, security, and operational evidence in measurable terms.

Governance is part of cloud infrastructure design because self-service can multiply inconsistency faster than traditional provisioning. Architects should define naming, tagging, ownership, approved regions or locations, identity standards, network patterns, logging, backup expectations, and cost-accountability rules before large-scale adoption. Guardrails make the desired path easier than the unsafe path.

A service catalog can turn architecture standards into repeatable choices. Instead of asking every project to design networking, resilience, and monitoring from scratch, platform teams can publish approved patterns for common workloads. This improves consistency while still allowing exceptions when a workload has a justified requirement the standard pattern cannot meet.

Application lifecycle matters after deployment. Environments need patching, image or template maintenance, capacity review, certificate and secret rotation, backup testing, vulnerability remediation, and eventual retirement. A cloud design that focuses only on initial provisioning creates operational debt that becomes visible months later.

Observability should be designed for both platform and application teams. Infrastructure metrics can prove resource health while application telemetry explains user experience. Correlating logs, traces, events, and configuration changes allows teams to determine whether a problem originates in the workload, platform, network, dependency, or deployment change.

Architecture reviews should include failure injection or scenario analysis. Ask what happens when a zone, network connection, identity provider, storage service, DNS dependency, or automation pipeline fails. This exposes hidden shared dependencies and gives operations teams concrete recovery steps before an outage.

Finally, every cloud design needs an exit or portability story proportional to risk. That does not mean every workload must move easily between providers, but teams should understand which services create strong coupling, how data can be exported, how long a migration would take, and what contractual or technical constraints would appear if strategy changes.

Architecture traceability is another useful discipline to carry forward from the DES-2T13 era. A design decision should be traceable to a stated requirement, constraint, risk, or operational objective, and significant tradeoffs should record the alternatives that were rejected. That record becomes valuable when cost, compliance, performance, or business priorities change because reviewers can see whether the original rationale still holds. It also makes implementation reviews more rigorous: teams can test whether the deployed environment actually satisfies the requirement that justified the design rather than simply confirming that the components were installed.