Modern DBA and ACS: how to lodge cloud database and data engineering work
The challenge facing the modern DBA at ACS
The DBA (Database Administrator) role today has changed considerably from what it was ten years ago. Alongside the traditional DBA (managing on-premise Oracle, SQL Server, MySQL), there are now:
- Cloud DBA: managing managed database services (RDS, Azure SQL, Cloud SQL, Aurora)
- Data Engineer: building data pipelines, ETL, data warehouses, lakehouses
- Database Developer / Backend Developer with a heavy database focus
- Database Architect: designing schemas and data models for complex systems
A common question: if I work as a cloud DBA or data engineer, will ACS assess me as ANZSCO 262111?
The answer: it depends on the actual content of your work and how your time is split across each type of task.
ANZSCO 262111 — what does Database Administrator cover?
Under the ANZSCO classification, Database Administrator (262111) covers:
- Installing, configuring and managing the database management system (DBMS)
- Monitoring performance and tuning queries (query tuning, index optimisation)
- Managing backup, recovery and business continuity for the database
- Database security: access control, encryption, audit
- Designing and implementing schemas and data models
- Handling database migration and version management
This description is broad enough to include the cloud DBA — because managing RDS or Azure SQL Database still involves all of the tasks above, just in a cloud environment.
Cloud DBA: is it recognised as 262111?
Yes — a cloud DBA is recognised if the content of the work includes enough of the DBA characteristics under ANZSCO 262111. The key point is that ACS assesses what you do, not where the database runs.
Cloud DBA work that usually counts towards 262111:
- Deploying and managing RDS/Aurora, Azure SQL Database, Cloud SQL
- Configuring performance parameters, monitoring slow queries, optimising indexes
- Designing and implementing a backup strategy and point-in-time recovery
- Managing IAM permissions for the database, setting up encryption at rest and in transit
- Taking part in database migration (on-premise → cloud, or between cloud providers)
Cloud DBA work that counts less towards 262111 (ACS may assess it under a different code):
- Mainly ETL pipeline development and data transformation — this is closer to Developer (261312)
- Mainly BI reporting and dashboards — closer to Business Analyst or Data Analyst
- Mainly data infrastructure provisioning unrelated to database management — closer to DevOps (261316)
Data Engineer vs DBA: an important boundary
“Data Engineer” is a common job title, but it has no dedicated ANZSCO code at present. When lodging with ACS, someone holding a Data Engineer title usually has to work out which code best fits the work:
| Main work | Likely code |
|---|---|
| Database management, query tuning, backup, schema | 262111 — Database Administrator |
| Building ETL pipelines and data pipelines in Python/SQL | 261312 — Developer Programmer |
| Designing and building data warehouse architecture | 262111 or 261313 depending on the depth |
| BI tool development (Power BI, Tableau, Looker) | May fall outside the ICT skill set ACS assesses |
A practical rule: look at the three tasks you do most often in a normal week. The right ANZSCO code is the one that accurately describes those tasks.
Common mistakes in a DBA application
Mistake 1: Describing a “Data Engineer” title without making clear the work is DBA ACS does not recognise “Data Engineer” as an ANZSCO term. If you lodge under 262111, describe the work in DBA language: schema management, backup, performance tuning, security — not just pipelines and ETL.
Mistake 2: Emphasising data pipelines and ETL over database management If your application spends 80% of its description on ETL/pipelines and 20% on database management, ACS may assess you as a Developer rather than a DBA.
Mistake 3: Failing to demonstrate experience with any specific DBMS ACS needs to see evidence that you have worked with at least one specific DBMS (MySQL, PostgreSQL, SQL Server, Oracle, MongoDB and so on). An application that is vague about “working with databases” is not enough.
Mistake 4: Leaving backup and recovery out of the description Backup, recovery and disaster recovery are core DBA duties under ANZSCO. If your application does not mention that you have managed a backup strategy and tested restores, ACS may find the application does not fit the DBA profile.
How to present a DBA application effectively
A structure for describing each DBA position:
-
System and scale: which DBMS (PostgreSQL, MySQL, Oracle, RDS and so on), on-premise or cloud, scale (number of databases, estimated volume, number of users)
-
Performance management: what did you monitor and optimise? (query execution plans, index tuning, autovacuum config, partitioning strategy)
-
Backup and recovery: the strategy and the actual outcomes — not just “performed backups”
-
Security: access control, privilege management, audit logging
-
Migration or upgrade: were there any migrations or major version upgrades?
If you also do data pipeline/ETL work, mention it briefly, but do not let it dominate the description — unless you intend to lodge as a Developer.