Home Lab Access & Prerequisites

Lab Access & Prerequisites

Managing your lab environment and technical prerequisites
By Restu Muzakir and 2 others
• 19 articles

Lab Access Duration

🚀 Quick Summary: - 📚 Most courses: 60 days lab access - 🎯 CCSE & CSC: 30 days lab access - 🎥 Videos available for 3 years - ➕ Extensions available if needed ​ ⏱️ Calibrated Access Periods Lab access duration is carefully calibrated for each certification to provide sufficient time for comprehensive hands-on practice while maintaining focused learning momentum: ​ 📚 Standard Certifications (60 days) - 🎓 CDP - Certified DevSecOps Professional - 🔧 CDE - Certified DevSecOps Expert - 🏗️ CAISP - Certified AI Security Professional - 🤖 CASP - Certified API Security Professional - 🔧 CCNSE: Certified Cloud Native Security Expert - 🎓 CTMP: Certified Threat Modeling Professional - 🎓 CSSE: Certified Software Supply Chain Security Expert ​Why 60 days? This two-month period is optimal for: - 📖 Work through all exercises thoroughly - 🧪 Experiment with different approaches - 💪 Build confidence in practical skills 🎯 Specialized Certifications (30 days) - 🐳 CCSE - Container Security Expert - 🛡️ CSC - Security Champion Why 30 days? Reflects: - 🎯 More focused scope - 🏗️ Assumes foundational knowledge - ⚡ Intensive, specialized training 🎥 Long-Term Learning Support While labs are time-limited, videos are accessible long-term: - 📹 3 full years of video access - 📚 Use as ongoing reference library - 🔄 Return when facing work challenges - 📈 Perfect combination: intensive practice + long-term support

Last updated on Dec 18, 2025

Lab Extensions

🚀 Quick Summary: - 🎛️ Available through course portal - 📊 Various duration(30/60/90 days) options available - 🔄 Common for refreshing the knowledge prior to exam - 📅 Plan extension timing carefully ​ 🛡️ Safety Net for Life's Challenges Despite careful planning, sometimes life circumstances require more time to complete your hands-on training. We offer lab extensions as a safety net: - 🎛️ Access through dedicated student portal page (https://portal.practical-devsecops.training/pricing) - 📋 Straightforward process to extend the labs - 📊 Various duration options to match your needs 💰 Affordable Pricing Structure Designed to be affordable while encouraging efficient use: - $200 for 30 days - popular choice for most students - $350 for 60 days - better value for extended preparation - $450 for 90 days - best daily rate for comprehensive review - 💸 Longer extensions = better daily value - 🎯 Especially if you've made significant progress already - One can buy the additional labs during the initial purchase itself 🤔 Choosing the Right Extension Evaluate before selecting: - 📈 Current progress level - ⏰ Available study time - 🎯 Proximity to exam readiness 📋 Common Extension Scenarios - 💼 Unexpected work projects demanding immediate attention - 👨‍👩‍👧‍👦 Family obligations - 🤒 Health issues - 📚 Underestimating time needed for thorough lab completion - 🔄 Post-exam retake preparation - practice areas where you struggled 💡 Bottom Line: Extensions ensure temporary setbacks don't derail your certification journey! Common Questions: Q1: I extended my lab for 30 days, but it's still showing lab as expired A: Could you email trainings@practical-devsecops.com with your preferred start date for the lab extension?

Last updated on Jan 27, 2026

Lab Environment

🚀 Quick Summary: - ☁️ Cloud-based, browser access - 🚫 No local installation needed - 🛠️ All tools pre-installed - 💻 Works on any OS - 🌐 Requires stable internet - 🎯 Realistic practice scenarios ​ ☁️ Cloud-Based Excellence Our lab environment represents one of the most valuable aspects of Practical DevSecOps training: - 🏗️ Built entirely on cloud infrastructure - 🚫 No local installation or configuration needed - 🌐 Access through your web browser - 🛠️ All necessary tools pre-installed and ready - ⚖️ Identical environments for everyone - 💻 Works regardless of personal hardware/OS 🌍 Practice Anywhere Ultimate flexibility with consistent access: - 🏠 Home, office, or traveling - always accessible - 🌐 Just need stable internet connection - 🔧 Complete tool suite included: - 📦 Container platforms - 🚀 CI/CD pipelines - 🔍 Security scanning tools - 📊 Monitoring solutions - 💰 Setup would be costly and time-consuming to replicate independently 🎬 Lab Experience Previews See the labs in action in our interactive lab environments: - CSSE:- https://app.arcade.software/share/JoTK7BbBuxHP9o1ydbr7 - CDP:- https://app.arcade.software/share/FOxYpxO9lo55UlatTjdf - CCNSE:- https://app.arcade.software/share/E1CPm9vGKUGruKofj7GD - CASP:- https://app.arcade.software/share/GJFO0sdo0Or1a88hhSFT - CAISP:- https://app.arcade.software/share/FKtHApJ3ppvpOfUY8CZl ⚡ Performance & Reliability Engineered for professional-grade work: - 🏃‍♂️ Handles security testing demands without lag - 🤖 Supports complex automation workflows - 🚫 No resource constraints of local VM setups - 💾 Regular backups protect your work - 💡 Pro tip: Keep your own copies of important scripts! 🎯 Authentic Learning Experience - 🔐 Realistic scenarios and vulnerabilities - ✅ Safe, legal environment for security testing - 🛠️ Authentic experience in identifying and fixing issues - 📈 Significant value component of your course investment

Last updated on Dec 22, 2025

Prerequisites and Foundations

🚀 Quick Summary - ✅ No strict prerequisites required - 🐧 Basic Linux familiarity is helpful but not mandatory - 💻 Basic computer skills are sufficient - 📚 Foundational DevOps concepts are taught as part of the course - 💪 Commitment, curiosity, and consistency matter most - 👥 Full support available for beginners Course-Specific Prerequisites Certified DevSecOps Professional (CDP) - Basic Linux commands (ls, cd, mkdir, etc.) - Basic understanding of application security practices (e.g., OWASP Top 10) - No prior DevOps experience required Certified DevSecOps Expert (CDE) - Must hold the Certified DevSecOps Professional (CDP) certification - Basic understanding of application security practices (SAST, DAST, etc.) Certified AI Security Professional (CAISP) - Basic Linux commands - Familiarity with a scripting language (Python, Golang, Ruby) is helpful but not required Certified Cloud-Native Security Expert (CCNSE) - Basic Linux commands - Understanding of OWASP Top 10 vulnerabilities - Familiarity with containers and Kubernetes is helpful but not mandatory Certified Container Security Expert (CCSE) - Basic Linux commands Certified Threat Modeling Professional (CTMP) - Knowledge of security fundamentals (Confidentiality, Integrity, Availability) - Basic knowledge of application development (preferred, not mandatory) Certified API Security Professional (CASP) - Basic Linux commands - Understanding of OWASP Top 10 - Basic knowledge of application development (preferred, not mandatory) Certified Software Supply Chain Security Expert (CSSE) - Basic Linux commands - Familiarity with Git, CI/CD pipelines, containers, and cloud platforms - Understanding of OWASP Top 10 vulnerabilities - Familiarity with a scripting language (Python, Golang, Ruby) is helpful but not required Certified Security Champion (CSC) - Foundational knowledge of the software development life cycle (SDLC) - Understanding of developing or testing web applications ✅ No Barrier to Entry Many learners ask: “Do I have enough background?” 🎯 The answer: Yes. You don’t need advanced expertise to start. - DevSecOps blends multiple disciplines, and few professionals come in with complete knowledge. - We provide the necessary foundations so everyone begins at the same level. 🚀 Helpful (But Not Required) Background These can speed up your learning: - 🐧 Linux commands (we provide references for newcomers) - 💻 Basic software development concepts (version control, programming logic) - ☁️ Cloud computing awareness 🎯 What REALLY Matters The most successful students share these qualities: - 🤔 Curiosity about security and modern development practices - 🧪 Willingness to experiment and learn from mistakes - 👷 Active participation in hands-on labs - 📈 Dedication to continuous professional growth 🎆 Success From All Backgrounds 💡 With the right mindset and our structured learning path: - Students from diverse technical and non-technical backgrounds achieve certification - Attitude and consistency matter more than prior experience - 💪 Your growth mindset is the true prerequisite

Last updated on Dec 18, 2025

Course Content Access

🚀 Quick Summary: - 📅 3-year video access from start date - ⏰ Course duration: 24–36 hours (depending on certification) - 📱 Streaming only (always updated) - 📚 PDF manuals for offline use - 📈 Progress tracking available - 📱 Mobile-friendly for videos 🎬 Extended Video Library Access Your learning experience extends far beyond traditional lectures: - 📅 3 full years of video access from course start - 🔄 Revisit concepts as you encounter real-world applications - 🎥 Professionally produced with clear audio - 📊 Helpful visualizations bring complex concepts to life - 🔄 Streaming-only ensures access to the most current content - 🆙 Updated automatically when tools/practices evolve 📚 Comprehensive Study Materials PDF manuals serve dual purposes: - 📚 Study guides for structured learning - 🔍 Professional references for ongoing work 📦 What's included in manuals: - 🧠 Key concepts and frameworks - ⌨️ Command references - 🎨 Architectural diagrams - 📝 Additional context enriching video content - 📱 Quick reference during lab work - 🖨️ Many students print sections for offline study ⏰ Course Duration (Mandatory Syllabus Completion Time) - 🎓 Certified DevSecOps Professional (CDP) – 36 hours - 🎓 Certified DevSecOps Expert (CDE) – 36 hours - 🎓 Certified AI Security Professional (CAISP) – 36 hours - 🎓 Certified Cloud Native Security Expert (CCNSE) – 36 hours - 🎓 Certified Container Security Expert (CCSE) – 24 hours - 🎓 Certified API Security Professional (CASP) – 36 hours - 🎓 Certified Threat Modeling Professional (CTMP) – 24 hours - 🎓 Certified Software Supply Chain Security Expert (CSSE) – 36 hours - 🎓 Certified Security Champion (CSC) – 24 hours FAQ (Frequently Asked Question) 1. Where is my manual course? You can find the course PDF manual in the email with the subject line [CourseName] Course Material and other important details. Replace CourseName with your course name (e.g., CDP, CASP, CCSE). Alternatively, search for the manual with the subject line [CourseName] PDF Manual. The link expires after one week, so download the manual and save a copy to your cloud storage for future access. Contact our support team if you can’t download the file. 💡 Pro Tip: The combination of videos, manuals, and structured timelines creates a complete learning ecosystem. Learners who dedicate consistent time to labs and theory finish faster and retain knowledge more effectively.

Last updated on Dec 22, 2025

Managing Lab Access: Reactivation Timing, Pause Limits, and Best Practices

Managing Lab Access: Reactivation Timing, Pause Limits, and Best Practices Whether you’re preparing for a DevSecOps certification or completing a hands‑on course, understanding how and when you can pause or reactivate your lab environment is essential. This guide explains the lab re‑activation timeline after an exam, the maximum pause duration, and why the pause feature is limited to a single use. Follow the steps and tips below to keep your lab access smooth and avoid unexpected interruptions. Table of Contents 1. What Happens After Your Certification Exam? 2. Pausing Your Lab Access: How Long Is It Allowed? 3. Why the Pause Can Be Used Only Once 4. Step‑by‑Step: Managing Lab Reactivation & Pauses 5. Common Questions & Quick Answers 6. Tips for a Seamless Lab Experience What Happens After Your Certification Exam? Lab Reactivation Timeline - Typical wait time: ≈ 48 hours after the exam‑related lab expires. - What to expect: Your lab course automatically switches from “expired” back to “active” once the 48‑hour window closes. Why the 48‑Hour Delay? - System processing: The platform needs a short buffer to verify exam completion, update your entitlement, and provision resources. - Fair access: This interval prevents immediate re‑use that could bypass exam integrity checks. What If You Don’t See Reactivation? 1. Confirm access: Log into the lab portal and verify that the status shows “Active.” 2. Check your email: Look for a confirmation message from the training team. 3. Reach out: If the lab remains inactive after 48 hours, please request assistance to with real agent Pausing Your Lab Access: How Long Is It Allowed? Maximum Pause Duration - Allowed pause: Up to 60 days (≈ 2 months). - Automatic re‑activation: After the 60‑day window elapses, the system restores lab access without any action required from you. How to Initiate a Pause 1. Go to the members portal at this link: https://members.practical-devsecops.training/pause-course 2. If the status is still showing as Provisioning please wait until it changes to Started. This is when the Pause The Lab button will appear. 3. Then, click on the Pause The Lab button. What Happens When the Pause Ends? - The lab status flips back to “Active” automatically. - All previously saved work, snapshots, and configurations remain intact (provided you followed the platform’s snapshot guidelines). Why the Pause Can Be Used Only Once The single‑use restriction is a preventive measure designed to: - Limit abuse: Prevent users from repeatedly pausing labs to extend the overall subscription period without paying. - Maintain fairness: Ensure all learners have comparable access windows, especially when labs are tied to time‑sensitive certifications. - Simplify administration: One pause per enrollment reduces the overhead of tracking multiple extensions and potential conflicts. If you anticipate needing more than one pause, plan ahead and use the full 60‑day window the first time. Step‑by‑Step: Managing Lab Reactivation & Pauses Reactivating After an Exam (48‑Hour Process) | Step | Action | Details | |------|--------|---------| | 1 | Wait 48 hours | No manual steps required; the system handles re‑activation. | | 2 | Verify status | Log in to the lab portal; look for “Active” badge. | | 3 | Contact support if needed | Use Chat with support option and then request to real agent | Pausing Your Lab (One‑Time, Up to 60 Days) 1. Open members portal → Click Pause Lab. 2. Confirm → System records the pause and shows the new expiration date. 3. Resume work after the pause automatically ends. Example Scenario: You finish a DevSecOps certification exam on March 1 and your lab expires on March 2. You need a break to attend a conference from March 10‑15. You pause the lab on March 5 for 10 days. Then you can reactivate it again when you want using the same page that you use to pause Common Questions & Quick Answers | Question | Answer | |----------|--------| | Can I extend the pause beyond 60 days? | No. The platform enforces a hard 60‑day limit per enrollment. | | What if I need a second pause? | Plan to use the full 60‑day window the first time; a second pause isn’t permitted. | | Will my lab data be lost during a pause? | No. All snapshots, containers, and configurations remain saved, provided you follow the recommended backup procedures. | | How do I know when the pause ends? | The Lab Management page displays the exact re‑activation date. You’ll also receive an email reminder 24 hours before the pause expires. | | Is the 48‑hour re‑activation window the same for all certifications? | Yes. All certification‑linked labs share the same 48‑hour post‑exam re‑activation policy. | Tips for a Seamless Lab Experience - Set calendar reminders for both the 48‑hour re‑activation window and the end of any pause period. - Take a final snapshot before pausing to guarantee a clean restore point. - Check connectivity (VPN, firewall rules) after re‑activation; sometimes network settings reset after long idle periods. - Leverage Mattermost for rapid support - you can request a real agent - Document your workflow (e.g., which scripts you ran, environment variables) in a shared notebook; this speeds up recovery after any pause or re‑activation. By understanding the 48‑hour re‑activation rule, the 60‑day single‑pause limit, and the reasoning behind these policies, you can confidently manage your lab environment throughout your DevSecOps certification journey. Keep this guide handy, and you’ll avoid unexpected downtime while staying focused on mastering hands‑on skills. Happy hacking!

Last updated on Mar 13, 2026

Accessing Lab Demos, Course Videos, and Post‑Lab Resources in Your DevSecOps Training

Accessing Lab Demos, Course Videos, and Post‑Lab Resources in Your DevSecOps Training Welcome to the DevSecOps learning hub! Whether you’re just starting the “Full Enterprise‑Grade DevSecOps Pipeline” demo or you’ve completed the hands‑on labs, you’ll need clear guidance on how to log in, what resources remain available after the lab period ends, and how to troubleshoot common video‑playback issues. This article consolidates the most frequently asked questions, provides step‑by‑step instructions, and offers practical tips so you can focus on mastering DevSecOps concepts instead of hunting for credentials or fighting firewalls. Table of Contents 1. Logging into GitLab for the “Full Enterprise‑Grade DevSecOps Pipeline” Demo 2. What Happens to Your Access After the Lab Expires? 3. Fixing the “Sorry, because of its privacy settings, this video cannot be played here” Error 4. Quick Reference Checklist 5. Additional Tips & Best Practices 1. Logging into GitLab for the “Full Enterprise‑Grade DevSecOps Pipeline” Demo Why the confusion? The introductory labs introduce the platform but do not provide the GitLab credentials used in the later “Full Enterprise‑Grade DevSecOps Pipeline” demo. Those credentials are supplied only in the dedicated Lab Guide for that specific module. How to obtain the credentials 1. Open the Lab Guide - Navigate to the Learning Path → Modules → Full Enterprise‑Grade DevSecOps Pipeline. - Click Download Lab Guide (PDF) or view it directly in the browser. 2. Locate the “GitLab Access” section - It is usually highlighted in the guide (see the screenshot in the original question for reference). - The section lists a username and a temporary password that are valid for the duration of the lab (typically 60 days). 3. Log in to GitLab - Go to https://gitlab.<your‑training‑domain>.com. - Enter the provided username and password. - You will be prompted to change the password on first login—choose a strong, memorable passphrase. What to do if you can’t find the credentials - Check the “Resources” tab on the course landing page – the Lab Guide is often duplicated there. - Contact Support via the Chatwoot and request a real agent for help you. 2. What Happens to Your Access After the Lab Expires? | Resource | Access Duration | What You Keep | How to Preserve It | |----------|----------------|---------------|--------------------| | Course Videos | 3 years from enrollment (subject to change) | Unlimited streaming of all recorded lectures | No action needed; videos remain in your account. | | Hands‑On Labs | 60 days from first login | Access to the live lab environment ends after 60 days. | Export any artefacts (e.g., pipeline YAML, Docker images) before the expiration date. | | PDF Manual / Lab Guide | Permanent (once downloaded) | The PDF stays on your device forever. | Save a copy to a personal cloud drive or local backup. | Steps to Secure Your Work Before Lab Expiration 1. Download artefacts – Use the “Export” button in the lab UI or run git clone to pull repositories locally. 2. Snapshot your environment – If you used a cloud‑based lab, take a snapshot or export the Docker images (docker save). 3. Document your pipeline – Save the .gitlab-ci.yml file and any custom scripts to a personal repository. 3. Fixing the “Sorry, because of its privacy settings, this video cannot be played here” Error This error is usually caused by network restrictions, corporate firewalls, or regional content blocks. Follow the troubleshooting flow below: Step‑by‑Step Troubleshooting 1. Use a Personal Device - Company‑issued laptops often have security agents that block external video streams. - Switch to a personal computer or a personal tablet for testing. 2. Check Your Network - Verify that you are on a stable, unrestricted Wi‑Fi or wired connection. - Avoid public Wi‑Fi that requires captive portals (e.g., coffee‑shop login pages). 3. Try an Alternate Network - If possible, connect via a mobile hotspot or a different ISP to rule out ISP‑level blocking. 4. Use a VPN - A reputable VPN can route traffic through a region where the video host is not blocked. - Ensure the VPN complies with your organization’s security policy. 5. Clear Browser Cache & Cookies - Old session data can interfere with embedded video players. - In Chrome/Edge: Settings → Privacy and security → Clear browsing data. 6. Disable Browser Extensions - Ad‑blockers or privacy extensions may block the video iframe. - Temporarily disable them and reload the page. 7. Test in an Incognito/Private Window - This bypasses most extensions and cached data. 8. Contact Support if All Else Fails - Provide a screenshot of the error, your device OS, browser version, and network type. - Reach out to real agent by request it in the Chatwoot(chatbot) Quick FAQ - Q: Do I need a corporate VPN to watch the videos? A: Only if your corporate firewall blocks the video CDN. A personal VPN works as an alternative. - Q: Can I download the videos for offline viewing? A: Yes. Each video page includes a “Download” button for learners with a valid subscription. 4. Quick Reference Checklist - Before Starting the Full Pipeline Demo - ☐ Download the Lab Guide PDF. - ☐ Locate GitLab credentials in the guide. - ☐ Log in and change the temporary password. - During the Lab (First 60 Days) - ☐ Export repositories and pipeline definitions daily. - ☐ Snapshot any custom Docker images. - After Lab Expiration - ☐ Verify you still have access to course videos (3‑year window). - ☐ Keep the PDF manual saved locally. 5. Additional Tips & Best Practices - Bookmark Key URLs: - GitLab: https://gitlab.<your‑domain>.com - Course Videos: https://learn.<your‑platform>.com/videos - Version Control Your Lab Work: Even though the lab environment is temporary, treat your code as production‑grade. Commit often and push to a personal GitHub or GitLab account. - Document Network Requirements: Keep a note of any required ports (e.g., 443 for HTTPS, 22 for SSH) and share it with your IT department if you encounter connectivity issues. By following the guidance above, you’ll smoothly navigate the GitLab login process, retain valuable learning assets after the lab period, and overcome video‑playback hurdles. If you run into any other roadblocks, remember that the Chatwoot and our dedicated support team are just a message away. Happy learning, and enjoy building your enterprise‑grade DevSecOps pipeline!

Last updated on Mar 03, 2026

Extending Lab Access, Unlocking Exercises, and Understanding Discount Options in Practical DevSecOps Training

Extending Lab Access, Unlocking Exercises, and Understanding Discount Options in Practical DevSecOps Training Introduction Hands‑on labs are the heart of any DevSecOps certification program. They let you apply theory, experiment with tools, and build confidence before you sit for the exam. However, real‑world learners often wonder how to manage lab time, whether they can unlock specific exercises, and if any discounts are available for extensions. This article walks you through how to extend your lab timer, why individual exercises can’t be unlocked separately, and the correct process for renewing or extending lab access. By the end, you’ll know exactly what steps to take to keep your learning momentum uninterrupted. 1. Extending the Lab Timer 1.1 What triggers the timer prompt? - Default duration: Most Practical DevSecOps labs are provisioned for 30 minutes of continuous use. - Prompt timing: When you reach the 20‑minute mark, a non‑intrusive banner appears, offering you the chance to extend the current session. - One‑time offer per exercise: The prompt is displayed once per lab exercise; after you accept or dismiss it, the option will not reappear for that same exercise. 1.2 How to extend the timer 1. Click the “Extend Lab” button on the prompt. 2. Confirm the extension (typically an additional 10–15 minutes, depending on your subscription). 3. Continue working without losing any progress—your environment stays exactly as you left it. Example: You’re midway through the “Secure CI/CD Pipeline” exercise and the timer hits 20 minutes. The prompt appears; you click Extend Lab, gaining an extra 15 minutes to finish the pipeline configuration and run the security scans. 1.3 When the prompt does not appear If you do not see the extension banner, it may be because: - You have already used the one‑time extension for that exercise. - Your lab subscription has expired, in which case you need to renew the entire lab access (see Section 3). 2. Unlocking Specific Lab Exercises 2.1 Why individual exercises can’t be unlocked Practical DevSecOps structures each course as a single, cohesive lab environment. All exercises share the same underlying resources (virtual machines, containers, and network configurations). Because of this architecture: - Partial unlocking would break dependencies between exercises. - Progress tracking relies on a linear flow, ensuring you master prerequisite concepts before moving forward. 2.2 What you can do instead - Complete the current exercise within the allotted time and move to the next one. - Request a full lab extension (Section 3) if you need more time for the entire set of exercises. 3. Extending or Renewing Lab Access 3.1 No discounts for extensions At this time, Practical DevSecOps does not offer discounts for lab extensions or renewals. All extensions are billed at the standard rate displayed on the pricing page. 3.2 Step‑by‑step process to extend your lab 1. Visit the Lab Pricing Portal: https://portal.practical-devsecops.training/pricing/ 2. Select the appropriate extension plan (e.g., 1‑month, 3‑month). 3. Complete the purchase using your preferred payment method. 4. Email the support team at trainings@practical-devsecops.com with: - Your account email - The desired start date for the extension (usually “immediately” or a specific future date) - Any special instructions (e.g., need for a particular lab environment). 5. Confirmation: You’ll receive a confirmation email with the new expiration date and a link to re‑activate your labs. Tip: Initiate the extension before your current lab expires to avoid any downtime. 3.3 Extending labs on the fly If you are already in a lab session and notice the timer winding down, you can still: - Navigate to the pricing portal in a new browser tab. - Purchase an extension (the system will automatically apply the extra time to your active session). 4. Frequently Asked Questions | Question | Answer | |----------|--------| | Can I extend a lab for only one exercise? | No. Extensions apply to the entire lab environment for the duration you purchase. | | Will the extension prompt appear multiple times? | The prompt appears once per exercise. After you accept or decline, it will not reappear for that same exercise. | | Are there any promotional codes or bulk‑purchase discounts? | Currently, no discount codes are available for lab extensions. Bulk purchases for corporate teams may have custom pricing—contact sales for details. | | What happens if my lab expires while I’m in the middle of an exercise? | Your environment will be frozen. You must renew the lab to regain access and continue where you left off. | | Can I get a refund if I extend but don’t use the extra time? | Refunds are handled case‑by‑case. Reach out to support within 7 days of purchase for assistance. | 5. Practical Tips for Managing Lab Time - Plan ahead: Review the lab agenda and allocate approximate time blocks for each exercise. - Use the 20‑minute reminder: Treat the extension prompt as a cue to either finish the current task or request more time. - Save your work: Periodically export configuration files or screenshots, especially before the timer expires. - Leverage community resources: The Practical DevSecOps forum often shares shortcuts and scripts that can speed up repetitive steps. Conclusion Effective lab management is essential for mastering DevSecOps concepts and passing certification exams. While you cannot unlock individual exercises or receive discounts on extensions, the platform offers a straightforward extension workflow that keeps your learning uninterrupted. By following the steps outlined above and applying the practical tips, you’ll maximize your lab time, stay on track with your study plan, and confidently progress through the Practical DevSecOps curriculum. Happy hacking!

Last updated on Jan 07, 2026

Lab Access on Mobile Devices & Practice Exam Availability: What You Need to Know

Lab Access on Mobile Devices & Practice Exam Availability: What You Need to Know Accessing hands‑on labs and practice exams is a core part of any DevSecOps certification journey. While most learners prefer a desktop or laptop, many wonder whether a smartphone, tablet, or iPad can provide the same experience. This article explains how mobile devices interact with lab environments, outlines the best practices for a smooth workflow, and clarifies how long practice‑exam labs remain available. Table of Contents 1. Using Mobile Devices for Hands‑On Labs 2. Desktop vs. Mobile: What to Expect 3. Practice Exam Lab Availability 4. Practical Scenarios & Tips 5. Common Questions (FAQ) Using Mobile Devices for Hands‑On Labs Supported Devices - Smartphones (iOS, Android) - Tablets (iPad, Android tablets) - Hybrid devices (Surface Pro, Chrome OS tablets) All of these platforms can launch the browser‑based lab environment, provided they meet the minimum browser requirements (latest Chrome, Edge, Safari, or Firefox). How It Works 1. Open the lab URL in your mobile browser. 2. Log in with your course credentials. 3. Launch the lab – the same virtual machines (VMs) and web interfaces appear as on a desktop. 4. Interact with each VM through the built‑in console or web UI. Note: The underlying infrastructure is cloud‑hosted, so the device you use only needs a stable internet connection and a supported browser. Desktop vs. Mobile: What to Expect | Feature | Desktop/Laptop | Mobile/Tablet | |---------|----------------|---------------| | Screen Real Estate | Large, multiple monitors enable side‑by‑side view of several VMs. | Smaller screens often require vertical scrolling and frequent zooming. | | Tab Switching | Seamless with keyboard shortcuts (Ctrl+Tab, Cmd+Tab). | Touch‑based tab switching can be slower, especially when juggling three or more machines. | | Keyboard Input | Full‑size keyboard, copy‑paste, and shortcut keys. | On‑screen keyboards lack many shortcuts; external keyboards improve usability. | | Mouse Precision | Precise pointer control for UI elements. | Touch gestures may be less accurate for tiny UI controls. | | Performance | Typically higher CPU/RAM, smoother rendering. | Dependent on device specs; older phones may lag with heavy console output. | Recommendation - Primary Learning: Use a desktop or laptop for the majority of lab work. - Supplemental Access: Mobile devices are fine for quick checks, reviewing lab instructions, or performing simple tasks that involve a single VM. Practice Exam Lab Availability - Duration Tied to Lab Access: The practice exam remains accessible for the entire period you have lab access. - No Separate Expiration: There is no independent countdown; once your lab subscription expires, the practice exam will also become unavailable. - Renewal Impact: Extending your lab subscription automatically extends practice‑exam access. Example: If you purchase a 90‑day lab package, you will have 90 days of both hands‑on labs and the associated practice exam. Practical Scenarios & Tips Scenario 1 – Quick Review on the Go You’re commuting and need to verify a configuration step you performed earlier. Open the lab on your phone, locate the specific VM console, and confirm the setting. This is a perfect use case for mobile access. Scenario 2 – Multi‑Machine Workflow Your lab requires you to configure three VMs simultaneously (e.g., a CI server, a scanning tool, and a vulnerable web app). On a desktop, you can tile windows side‑by‑side. On a tablet, consider: - External Keyboard + Mouse (Bluetooth) to mimic desktop shortcuts. - Split‑Screen Mode (iPadOS or Android) to view two VMs at once, then toggle the third. Tips for a Smoother Mobile Experience - Use a modern browser and keep it updated. - Enable “Desktop Site” mode in the browser to avoid mobile‑specific UI changes. - Connect a physical keyboard (Bluetooth or USB‑C) for faster command entry. - Close unnecessary tabs to free up memory and reduce lag. - Prefer Wi‑Fi over cellular data for a stable, low‑latency connection. Common Questions (FAQ) Q1: Can I complete the entire lab suite on a phone? Answer: Technically yes, but the experience will be slower and more cumbersome, especially when multiple consoles are involved. For full efficiency, a desktop is strongly recommended. Q2: Do I need any special software on my tablet? Answer: No. The labs run entirely in the browser. Ensure your tablet’s OS and browser are up to date. Q3: What happens to my practice exam if I lose lab access before the exam date? Answer: Access to the practice exam ends simultaneously with lab access. Renew your lab subscription to retain practice‑exam availability. Q4: Is there a way to download lab materials for offline use on mobile? Answer: Lab environments are cloud‑based and cannot be downloaded. However, you can download PDFs of lab guides for reference. Q5: Will using a mobile device affect my exam performance? Answer: The exam itself is usually taken on a desktop or a proctored environment. Mobile access is only for lab practice; it does not impact the actual certification exam. Bottom Line Mobile devices offer a convenient way to peek into your DevSecOps labs, but they are best suited for lightweight tasks or quick reviews. For full‑scale, multi‑machine exercises, a desktop or laptop remains the optimal platform. Remember, your practice exam stays available for as long as your lab access does, so keep your subscription current to maximize study time. Happy learning, and may your labs run smoothly—whether on a desktop or on the go!

Last updated on Jan 07, 2026

Lab Access Troubleshooting: Resetting Machines, Faster Provisioning, and Resolving GitLab 404 Errors

Lab Access Troubleshooting: Resetting Machines, Faster Provisioning, and Resolving GitLab 404 Errors Managing your Practical DevSecOps lab environment should be smooth and predictable. Whether you’re a beginner launching your first lab or an experienced practitioner spinning up multiple scenarios, understanding how to reset machines, speed up provisioning, and access GitLab correctly will save you time and frustration. This guide walks you through the most common lab‑access issues, offers step‑by‑step solutions, and provides handy tips to keep your learning journey on track. Table of Contents 1. Do I Need to Delete Old Machines? 2. Why Is Lab Provisioning Slow and How Can I Fix It? 3. GitLab Returns a 404 Page Not Found – What to Do 4. Quick Access: Lab Portal URL 5. Best‑Practice Tips & Frequently Asked Questions Do I Need to Delete Old Machines? Short answer: No, you don’t have to delete machines after each lab. When you should consider resetting a machine - Encountering unexpected errors (e.g., services failing to start, broken network configuration). - Configuration drift after experimenting with system settings or installing additional packages. - Resource constraints on the shared lab infrastructure (rare, but possible during peak usage). How to reset a machine safely 1. Log in to the Lab Portal – navigate to the Machines section. 2. Locate the specific instance you want to reset. 3. Click “Reset” (or “Re‑provision”) and confirm the action. 4. Wait a few minutes while the platform rebuilds the VM to its original snapshot. Pro tip: Resetting restores the machine to a clean state without permanently deleting any of your lab data. You can always re‑run the lab instructions from the beginning. Why Is Lab Provisioning Slow and How Can I Fix It? Provisioning delays are often caused by network hiccups, browser cache issues, or temporary load on the lab infrastructure. Step‑by‑step troubleshooting checklist 1. Reset the machines first – a fresh start eliminates hidden configuration problems. 2. Test your network connectivity using the built‑in diagnostic tool: https://portal.practical-devsecops.training/machines/test-connection - The test checks DNS resolution, latency, and port accessibility required for the labs. 3. Clear browser cache & cookies or try an incognito/private window. 4. Switch browsers – Chrome, Edge, and Firefox are all supported; Safari may have occasional quirks. 5. Verify VPN or corporate firewall settings – ensure outbound traffic to *.lab.practical-devsecops.training on ports 80/443 is allowed. Example scenario You’ve attempted to provision a “Vulnerability Scanning” lab three times, each attempt taking over 10 minutes. Solution: Reset the lab machine, run the connection test (which shows “All checks passed”), then re‑provision. The lab should now spin up in under 2 minutes. If provisioning still takes longer than 5 minutes after these steps, contact support with the machine ID and a screenshot of the connection test results. GitLab Returns a 404 Page Not Found – What to Do A 404 error typically means you’re trying to reach the wrong GitLab instance URL or you haven’t logged in with the correct credentials. Correct URL format https://gitlab-ce-<machine_id>.lab.practical-devsecops.training - Replace <machine_id> with the identifier shown on your Lab Portal (e.g., gitlab-ce-42). Logging in successfully 1. Open the URL in your browser. 2. Use the username/password supplied in the Basic CI/CD chapter of the lab guide. - These credentials are unique per lab and are listed under the “Credentials” section of the exercise. - Default credentials for the Gitlab is username: "root" password: "pdso-training" 3. After logging in, you should land on the GitLab dashboard where you can clone repositories, create pipelines, and explore the CI/CD features. Common pitfalls | Symptom | Likely cause | Fix | |---------|--------------|-----| | 404 error after entering URL | Typo in machine ID or missing “https://” | Double‑check the URL format and copy‑paste directly from the portal. | | Login page appears, but credentials are rejected | Using credentials from a different lab | Refer back to the Basic CI/CD chapter for the correct set. | | Page loads but shows “Repository not found” | Trying to access a repo that hasn’t been created yet | Follow the lab steps to create the repository first. | Quick Access: Lab Portal URL All lab management actions (reset, provision, network test, and credential lookup) are performed through the central portal: **🔗 **https://portal.practical-devsecops.training/ Bookmark this link and keep it handy throughout your training. Best‑Practice Tips & Frequently Asked Questions Tips for a Smooth Lab Experience - Always reset before a new lab if you suspect leftover configuration from a previous exercise. - Run the network test after any major change to your local environment (new Wi‑Fi network, VPN activation, etc.). - Use a dedicated browser profile for labs to avoid cookie conflicts with personal accounts. Frequently Asked Questions | Question | Answer | |----------|--------| | Do I need to delete a machine after each lab? | No. Deleting is unnecessary; resetting is sufficient. | | What if the connection test fails? | Note the specific error (DNS, latency, blocked port) and adjust your network or firewall settings accordingly. | | Can I access GitLab from a mobile device? | Yes, but a desktop browser provides a better experience for pipeline configuration. | | Where do I find the credentials for GitLab? | In the Basic CI/CD chapter of the lab guide, under the “Credentials” subsection. | | What should I do if provisioning never finishes? | Reset the machine, run the network test, clear your browser cache, and if the issue persists, open a request to real agent with the machine ID. | Closing Thoughts Effective lab management is a cornerstone of successful DevSecOps training. By resetting machines when needed, verifying network health before provisioning, and using the correct GitLab URL and credentials, you’ll minimize downtime and maximize learning. Keep this guide bookmarked, and refer back whenever you encounter access issues—your labs will run like a well‑orchestrated pipeline!

Last updated on Feb 09, 2026

Initial Lab Setup for DevSecOps: Git Configuration, Credential Management, and YAML Snippets

Initial Lab Setup for DevSecOps: Git Configuration, Credential Management, and YAML Snippets Introduction Setting up a clean, repeatable environment is the first step toward success in any DevSecOps lab or certification exam. Whether you are working through cloud‑based labs, preparing for a proctored exam, or simply practicing on your own machine, you will repeatedly encounter three core tasks: 1. Configuring your Git identity (global email and username). 2. Understanding when and how to use the credentials provided by the lab platform. 3. Copy‑pasting YAML snippets correctly without triggering “command not found” errors. This article walks you through each of these tasks, explains the underlying rationale, and offers practical tips you can apply instantly. By the end, you’ll know exactly what values to use for Git, when to add allow_failure: true to a job, and how to work with copy‑ready code snippets in the lab UI. 1. Configuring Git Global Email and Username Why It Matters Git tracks who makes each commit. In a lab environment the Git identity does not affect grading, but a consistent configuration prevents confusion when you push changes to shared repositories or when you review commit logs later. What Values to Use | Context | Recommended Email | Recommended Username | |---------|-------------------|----------------------| | Exam (proctored or remote) | Any valid email address (e.g., yourname@example.com). It can be a personal or corporate address – the system does not validate it. | Any string without spaces (e.g., yourname). | | Course Labs | The email shown in the DevSecOps Gospel section of the course manual (around page 57). | The username listed alongside the email in the same section. | Tip: If you are unsure, simply run the commands below with placeholder values; the lab will accept them: git config --global user.email "student@example.com" git config --global user.name "student" How to Set the Values # Set global email git config --global user.email "your.email@domain.com" # Set global username git config --global user.name "yourusername" These settings are stored in ~/.gitconfig and apply to all repositories you interact with during the exam or lab. 2. Adding allow_failure: true to a GitLab CI Job What Is allow_failure? In a .gitlab-ci.yml file, allow_failure: true tells the pipeline to continue even if the job fails. The job will be marked as “failed (allowed)” but subsequent stages still run. When to Use It | Scenario | Reason to Add allow_failure | |----------|-------------------------------| | Exploratory or non‑critical checks (e.g., linting, static analysis) | Failure should not block the rest of the pipeline. | | Learning labs where the focus is on syntax, not on passing every test | Keeps the lab flow moving for the learner. | | Optional security scans that may produce false positives in a controlled environment | Prevents unnecessary pipeline aborts. | When Not to Use It - Critical security gates (e.g., container image scanning that must pass before deployment). - Production‑grade pipelines where any failure should halt promotion. Reference Guidance The best‑practice guidance for allow_failure is documented in the GitLab CI/CD pipeline configuration guide and reiterated in the DevSecOps Gospel (see course manual, page 57‑58). Use the following decision checklist: 1. Is the job required for a successful deployment? → No: consider allow_failure. 2. Is the job only providing additional insight? → Yes: add allow_failure. 3. Does the exam explicitly test the job’s success? → No: avoid allow_failure unless instructed. 3. Working with YAML Snippets in the Lab UI The “Command Not Found” Misunderstanding Lab portals often display YAML or shell snippets with a “Click to copy” button. The copied text is intended for a file, not for direct execution in the terminal. Pasting it into a shell will naturally produce a command not found error because the terminal tries to interpret YAML as a command. Correct Workflow 1. Click the copy icon next to the snippet. The text will jiggle, confirming it’s on the clipboard. 2. Open the appropriate file in the lab environment (e.g., gitlab-ci.yml). 3. Paste the snippet into the file using a text editor (vim, nano, or the web UI). 4. Save the file and commit the changes if required. Example # Click → copy this block stages: - build - test build_job: stage: build script: - echo "Building..." allow_failure: true # optional, see Section 2 Do not paste the block directly into the terminal; instead, edit gitlab-ci.yml and insert it there. Quick Tip: Verify the Paste # After pasting, you can check the file content cat .gitlab-ci.yml If the file displays the YAML correctly, you’re ready to run the pipeline. 4. Using Lab‑Provided Credentials Where to Find Them Credentials are displayed in a table format on the lab dashboard (often under a “Credentials” tab). They may include: - SSH keys for VM access - API tokens for cloud services - Username/password pairs for internal tools How to Apply Them 1. Locate the table that matches the resource you need (e.g., “GitLab Runner” or “Kubernetes Cluster”). 2. Copy the relevant row (username, password, or token). 3. Use the credentials in the appropriate command or configuration file. Example: SSH Access | Host | Username | Password | SSH Key | |---------------|----------|----------|---------| | lab‑web‑01 | labuser| P@ssw0rd! | ssh-rsa AAA… | ssh labuser@lab-web-01 # or, if using the provided key ssh -i ~/.ssh/lab_key labuser@lab-web-01 Best Practice - Never hard‑code passwords in scripts; use environment variables or secret management tools. - Delete or rotate any temporary credentials after the lab session ends. Common Questions & Tips | Question | Answer | |----------|--------| | Do I need a corporate email for Git config in the exam? | No. Any syntactically valid email works. | | When should I skip allow_failure? | If the job is a gating step for security or deployment. | | Why does pasting a YAML snippet into the terminal give an error? | Because the terminal expects shell commands, not YAML. Paste into a file instead. | | Where are credentials stored after I copy them? | They remain on your clipboard until overwritten. Paste them promptly into the appropriate field or command. | Additional Tips - Run git config --list after setting email/username to confirm the values. - Validate your .gitlab-ci.yml with gitlab-ci-lint (available in GitLab UI) before committing. - Keep a notebook of credential tables for each lab; it speeds up navigation. Conclusion Proper lab setup—configuring Git, handling credentials responsibly, and correctly using YAML snippets—lays the groundwork for a smooth DevSecOps learning experience and a successful certification exam. By following the guidelines above, you’ll avoid common pitfalls, adhere to best practices, and focus your energy on mastering the security‑focused pipelines that define modern DevOps. Happy hacking!

Last updated on Jan 07, 2026

Lab Machine Provisioning, Access, and URL Configuration in DevSecOps Training

Lab Machine Provisioning, Access, and URL Configuration in DevSecOps Training Welcome to the practical side of DevSecOps! Whether you’re preparing for a certification exam or simply exploring the hands‑on labs, understanding how your lab machines are provisioned, accessed, and referenced is essential. This guide walks you through the entire lifecycle—from automatic provisioning to downloading files, constructing the correct URLs, and reporting any hiccups you encounter. Table of Contents 1. What Happens When a Lab Starts? 2. Downloading Files from Your DevSecOps Box 3. Constructing the Correct Lab URL 4. How to Report a Lab Issue 5. Dependency‑Check 404 Errors – Quick Fix 6. Tips & Best Practices 7. Frequently Asked Questions What Happens When a Lab Starts? Short answer: If you see a running machine and a live application, everything is working as intended. - Automatic provisioning – As soon as you launch an exercise, the platform spins up a dedicated VM (the DevSecOps Box) and deploys the required services. - Health check – The system verifies that the VM is reachable, the network is configured, and the sample application is up. A healthy machine means you can move straight to the hands‑on tasks. - No manual setup required – You do not need to install anything before the lab begins; the environment is pre‑configured for you. Downloading Files from Your DevSecOps Box Sometimes you’ll need to fetch binaries, logs, or configuration files from the lab VM. The simplest method is to start a temporary HTTP server inside the box. Step‑by‑Step Instructions 1. Open a terminal on your DevSecOps Box (SSH or the integrated console). 2. Run the built‑in Python server (listening on port 80): python3 -m http.server 80 3. Locate your Machine ID – the unique identifier appears in the welcome banner or can be retrieved by asking the lab bot: “What is my Machine ID?” Example ID: dzwrlgdj 4. Open a browser on your local workstation and navigate to: https://devsecops-box-<MACHINE_ID>.lab.practical-devsecops.training Replace <MACHINE_ID> with the value from step 3. You’ll see a directory listing of the folder where you started the HTTP server. Click any file to download it. Tip: Keep the terminal session running while you download; stopping the server will make the URL return a 404 error. Constructing the Correct Lab URL The platform exposes each VM under a predictable naming scheme. Understanding the pattern helps you quickly switch ports or share links with teammates. URL Pattern devsecops-box-<MACHINE_ID>[-<PORT>].lab.practical-devsecops.training | Component | Example | Meaning | |-----------|---------|---------| | Hostname | devsecops-box-dzwrlgdj | Fixed prefix + your Machine ID | | Port suffix (optional) | -8000 | Indicates the service runs on port 8000 (omit for port 80) | | Domain | lab.practical-devsecops.training | Shared domain for all labs | Common Port Variants | Port | Full URL (replace <MACHINE_ID>) | |------|-----------------------------------| | 80 | https://devsecops-box-<MACHINE_ID>.lab.practical-devsecops.training | | 8000 | https://devsecops-box-<MACHINE_ID>-8000.lab.practical-devsecops.training | | 8080 | https://devsecops-box-<MACHINE_ID>-8080.lab.practical-devsecops.training | Example: If your Machine ID is dzwrlgdj and you need the service on port 8000, open: https://devsecops-box-dzwrlgdj-8000.lab.practical-devsecops.training How to Report a Lab Issue Encountered a glitch? Reporting it promptly helps the support team fix problems and improves the learning experience for everyone. 1. Locate the “Report Issue” button – it appears in the top‑right corner of the lab UI. 2. Provide a concise description – include the exercise name, the step you were on, and any error messages. 3. Submit – the ticket is automatically routed to the DevSecOps support engineers. Dependency‑Check 404 Errors – Quick Fix When running the OWASP Dependency‑Check tool, you might see a 404 while it tries to fetch the latest NVD (National Vulnerability Database) CVE feed for 2024. Why It Happens - The NVD endpoint may have been temporarily unavailable. - A cached URL in the tool could be outdated. Resolution Steps 1. Retry the scan – many transient 404s resolve on a second attempt. dependency-check.sh --project my-app --scan . 2. Update the tool – ensure you’re using the latest Dependency‑Check version, which includes refreshed NVD URLs. sudo apt-get update && sudo apt-get install dependency-check 3. Manually download the CVE feed (if the problem persists): wget https://nvd.nist.gov/feeds/xml/cve/1.1/nvdcve-1.1-2024.xml.gz -P ~/.dependency-check/data/ 4. Rerun the scan – the tool will now use the locally cached feed. If the error continues after these steps, use the “Report Issue” button and attach the console output. Tips & Best Practices - Keep the terminal open when serving files; closing it stops the HTTP server. - Bookmark your lab URLs for quick access across different ports. - Copy the Machine ID to a sticky note or a text file; you’ll need it for every URL you construct. - Regularly update tools (Python, Dependency‑Check, Docker) inside the lab to avoid compatibility problems. - Take screenshots of error messages before reporting; visual context speeds up troubleshooting. Frequently Asked Questions | Question | Answer | |----------|--------| | My machine shows “running” but I can’t reach the URL. | Verify you used the correct Machine ID and port. Check that the Python HTTP server is still active. | | Do I need to open any firewall ports on my local network? | No. All traffic is tunneled through the lab platform’s reverse proxy; just ensure outbound HTTPS is allowed. | | Can I use a different port than 80, 8000, or 8080? | Only the three ports listed are exposed by the environment. Choose whichever matches the lab instructions. | | What if the “Report Issue” button is missing? | Open the chat widget on the right side of the screen and type “I need help with my lab”. A support agent will respond. | | Is the Python HTTP server secure? | It’s intended for temporary, internal file sharing only. Do not expose sensitive credentials and stop the server when you’re done. | By mastering machine provisioning, URL construction, and quick troubleshooting, you’ll spend less time wrestling with the environment and more time focusing on the core DevSecOps concepts that matter for your certification and real‑world projects. Happy hacking!

Last updated on Jan 07, 2026

Testing DevSecOps Tools Locally and Configuring Cloud Labs on Your Machine

Testing DevSecOps Tools Locally and Configuring Cloud Labs on Your Machine Introduction Preparing for a DevSecOps certification often means juggling multiple environments—cloud‑based labs, local virtual machines, and the official training images. You may wonder whether you can practice the same tools on your own workstation, replicate the cloud labs locally, or use the hysnsec Docker images during the exam. This article consolidates the official guidance into a clear, step‑by‑step guide so you can train efficiently, stay compliant with exam rules, and avoid unnecessary roadblocks. 1. Testing Lab Tools in a Local Environment 1.1 Is it allowed? Yes. You are free to install and run the tools provided in the training labs on your personal computer as long as you can achieve the same objectives defined for each exam challenge. The certification body does not require you to use the cloud‑hosted instance; the focus is on demonstrating the required tactics and techniques. 1.2 Why practice locally? - Faster iteration – No latency from a remote lab. - Customizable setup – Add plugins, scripts, or extra utilities that help you learn. - Exam readiness – The practice exam in the course mirrors the real test; reproducing it locally reinforces the workflow. 1.3 Recommended local practice workflow 1. Identify the challenge goal (e.g., “enumerate containers”, “extract a secret from a Kubernetes pod”). 2. Choose a compatible tool (K9s, kubectl, Trivy, etc.). 3. Run the tool against a local test environment (Docker Desktop, Minikube, Kind, etc.). 4. Validate the output matches the expected result from the lab instructions. 2. Replicating Cloud Labs on Your Machine 2.1 What the Cloud Labs provide The hosted labs come pre‑installed with: - Ubuntu 20.04 LTS (or later) base OS - Required DevSecOps utilities (e.g., kubectl, helm, docker, trivy, gitleaks) - Pre‑configured network settings and vulnerable images for exploitation Because everything is pre‑wired, you can focus on technique rather than environment setup. 2.2 Why a local replica is challenging - Dependency management – Matching exact version numbers across tools can be time‑consuming. - Network topology – Cloud labs simulate multi‑node clusters, which may require additional configuration locally. - Support limitations – The training team does not officially support custom local installations. 2.3 Practical steps to build a local lab (if you still want to) | Step | Action | Details | |------|--------|---------| | 1 | Install a virtualization platform | VirtualBox (free) or VMware Workstation Player. | | 2 | Create an Ubuntu VM | Use Ubuntu 20.04 LTS (or the version mentioned in the course). Allocate at least 4 GB RAM and 2 CPU cores. | | 3 | Install core tools | bash sudo apt update && sudo apt install -y docker.io kubectl helm git | | 4 | Pull the training images | bash docker pull hysnsec/lab‑image:latest (or any other image you plan to use). | | 5 | Set up a local Kubernetes cluster (optional) | Use Kind or Minikube: kind create cluster or minikube start. | | 6 | Verify connectivity | Run kubectl get nodes and ensure the vulnerable pods are reachable. | | 7 | Replicate lab scenarios | Follow the lab guide step‑by‑step, substituting cloud URLs with your local IPs. | Tip: Keep a snapshot of the clean VM state. If a lab corrupts the environment, you can revert instantly. 3. Using the hysnsec Images 3.1 Are you required to use the official images? No. The exam does not mandate the use of the hysnsec Docker images. You may work with: - The official hysnsec images (recommended for consistency). - Any other Docker or VM image that contains the same vulnerable components. 3.2 When to prefer hysnsec images - Alignment with course material – The labs and practice exam reference specific file paths and configurations present in the hysnsec images. - Reduced troubleshooting – Using the same image eliminates version mismatches that could cause unexpected errors. 3.3 Example: Scanning a vulnerable container # Pull the image (if not already present) docker pull hysnsec/vuln‑app:1.2 # Run the container docker run -d --name vuln-app hysnsec/vuln‑app:1.2 # Scan with Trivy trivy image hysnsec/vuln‑app:1.2 The output should list known CVEs, matching the lab’s expected results. 4. Tips & Best Practices - Document your setup – Keep a Markdown file with all commands you run; it becomes a personal cheat‑sheet for the exam. - Version lock – Use apt-mark hold <package> or Docker tags to freeze tool versions. - Network isolation – Run vulnerable containers on a separate Docker network to avoid accidental exposure. - Practice time‑boxing – Simulate exam conditions by giving yourself a strict time limit for each challenge. - Backup your work – Export your Docker images or VM snapshots to an external drive before major changes. 5. Common Questions | Question | Answer | |----------|--------| | Can I use the practice exam as my only study material? | Yes, the practice exam mirrors the real test objectives. Combine it with hands‑on labs for deeper understanding. | | Do I need to reinstall tools before every exam attempt? | Not necessary, but ensure your environment matches the tool versions listed in the exam guide. | | What if my local VM crashes during a lab? | Restore from the snapshot you created in Step 7 of the “Replicating Cloud Labs” table. | | Is it okay to use other Linux distributions (e.g., Fedora)? | Technically possible, but you may encounter missing dependencies. Ubuntu is the safest choice. | | Can I mix hysnsec images with my own custom images? | Absolutely, as long as the combined environment lets you meet the challenge objectives. | 6. Conclusion Testing DevSecOps tools locally and, if desired, recreating cloud labs on your own machine gives you flexibility, speed, and deeper insight into the security techniques you’ll need for certification. While the official cloud labs are fully equipped and supported, a well‑configured Ubuntu VM (or Docker environment) paired with the hysnsec images can provide an equally effective practice ground. Follow the step‑by‑step guide, keep your environment tidy, and you’ll be well‑prepared to ace the exam. Happy hacking!

Last updated on Jan 07, 2026

Lab Environment Essentials: Access Duration, Setup Commands, and Managing Image Updates

Lab Environment Essentials: Access Duration, Setup Commands, and Managing Image Updates Everything you need to know about lab access windows, installing tools on Alpine Linux, and handling outdated images in DevSecOps training environments. Introduction When you enroll in a DevSecOps course or certification, you’ll be given a sandboxed lab environment where you can practice scanning, hardening, and automating security controls. Understanding how long you have access, how to provision required utilities, and what to do when base images are out‑of‑date is critical for a smooth learning experience and a successful exam. This article breaks down those three core topics, provides step‑by‑step examples, and answers the most common questions you’ll encounter. 1. Lab Access Duration – What the 60‑Day Countdown Means 1.1 Fixed 60‑Day Window - Provisioning date = the moment you receive your lab credentials (usually via email or the learning portal). - Expiration = exactly 60 calendar days after provisioning, regardless of how often you log in or whether you use the lab at all. Key point: The timer does not decrement per‑lab or per‑exercise. It’s a simple, fixed countdown that starts once the environment is created. 1.2 Why a Fixed Window? - Resource planning: The cloud infrastructure that powers the labs is allocated on a per‑student basis. A predictable 60‑day lease helps the provider manage capacity and cost. - Security hygiene: Periodic teardown reduces the risk of lingering vulnerable containers or misconfigurations after the course ends. 1.3 How to Track Your Remaining Time | Method | Steps | |--------|-------| | Portal dashboard | Log in to the https://portal.practical-devsecops.training/courses/ → Your enrollment course → view “Expires on” date. | | Calendar reminder | Add the expiration date to your personal calendar as a recurring reminder 7 days before the deadline. | 2. Installing Python Packages on Alpine Linux – The apk add py-pip py-requests Command Alpine Linux is a lightweight distribution commonly used for container bases. Its package manager, apk, works similarly to apt (Debian) or yum (RHEL) but with a syntax optimized for minimal images. 2.1 Command Breakdown apk add py-pip py-requests | Segment | Meaning | |---------|---------| | apk | Alpine Package Keeper – the CLI tool for installing, upgrading, or removing packages. | | add | Sub‑command that tells apk to install one or more packages. | | py-pip | The Alpine package that provides pip, Python’s official package installer. | | py-requests | The Alpine package for the requests library, a popular HTTP client for Python. | 2.2 When to Use This Command - Preparing a lab container that needs to download additional Python modules (e.g., pip install -r requirements.txt). - Running quick scripts that interact with REST APIs, where requests is the go‑to library. 2.3 Practical Example # 1️⃣ Update the package index (always a good habit) apk update # 2️⃣ Install pip and the requests library apk add py-pip py-requests # 3️⃣ Verify installation pip --version # should show pip version python -c "import requests; print(requests.__version__)" Tip: If you need a newer version of requests than the one in Alpine’s repository, install pip first (apk add py-pip) and then run pip install --upgrade requests. 3. Dealing with Out‑of‑Date Images and Tool Versions 3.1 Why Some Lab Images Appear Out‑of‑Date - Pre‑built images are frozen at a specific snapshot to guarantee reproducibility across all students. - Security tools (SCA, SAST, DAST) may have newer releases that are not yet baked into the base image. 3.2 Exam Policy on Tool Versions - Official stance: The lab team strives to ship the latest stable version of each tool or a version that is known to work with the exercise. - If a tool fails because of an older version, you are encouraged to raise a ticket in the dedicated exam support channel. The support team can either: 1. Provide a temporary upgrade command, or 2. Confirm that the current version is acceptable for scoring. 3.3 Recommended Workflow 1. Before the exam, run toolname --version for each required utility and note the output. 2. Document any version discrepancies in your exam report (e.g., “Tool X version 2.3 used; production version is 2.5 – upgrade recommended”). 3. If needed, upgrade within the lab using the tool’s official upgrade method (often a simple pip install --upgrade toolname or a package manager command). Example: Upgrading Trivy (SCA scanner) # Check current version trivy --version # Upgrade via the official script wget https://github.com/aquasecurity/trivy/releases/latest/download/trivy_$(uname -s)_$(uname -m).tar.gz tar -xzf trivy_*.tar.gz -C /usr/local/bin trivy chmod +x /usr/local/bin/trivy # Verify upgrade trivy --version 3.4 Best Practices - Keep a cheat sheet of common upgrade commands for the tools you’ll use. - Never modify the base image (e.g., by committing changes) unless explicitly allowed; it can invalidate the exam environment. - Use the support channel early—waiting until the last minute can jeopardize your exam timeline. 4. Common Questions & Quick Tips 4.1 Frequently Asked Questions | Question | Answer | |----------|--------| | Will my lab time be extended if I finish early? | No. The 60‑day period is fixed and cannot be extended or shortened. | | Can I install additional OS packages besides Python tools? | Yes, as long as you use apk add (or the appropriate package manager) and you do not break the lab’s baseline configuration. | | What if a required tool is missing from the image? | Check the lab documentation for a “pre‑install” script. If none exists, request assistance via the exam support channel. | | Is it okay to note “out‑of‑date tool” in my final report? | Absolutely. Including version information demonstrates awareness of real‑world maintenance practices. | 4.2 Quick Tips for a Smooth Lab Experience - Set a reminder 7 days before the 60‑day expiry to back up any important scripts or findings. - Run apk update && apk upgrade at the start of each session to pull the latest security patches for the base OS (unless the lab explicitly forbids it). - Create a reusable script (setup.sh) that installs all your required Python packages and upgrades tools—run it each time you spin up a fresh container. - Document every command you execute (copy‑paste into a markdown file). This log becomes part of your exam evidence and helps reviewers understand your methodology. 5. Conclusion Mastering the lab access timeline, basic Alpine Linux commands, and the procedure for handling outdated images equips you to focus on the core DevSecOps concepts rather than getting stuck on environment quirks. By following the guidelines and best practices outlined above, you’ll maximize the value of your lab time, stay compliant with exam policies, and demonstrate a professional approach to security tooling—both in training and in real‑world deployments. Happy hacking, and good luck on your certification!

Last updated on Feb 11, 2026

Navigating GitLab Projects and CI/CD in Your DevSecOps Lab

Navigating GitLab Projects and CI/CD in Your DevSecOps Lab Whether you’re new to GitLab or transitioning from an older version, understanding where to find your projects, how to interpret CI/CD status, and what branch conventions to follow can make your lab experience smoother and more productive. This guide walks you through the most common hurdles you might encounter in a DevSecOps lab environment, complete with step‑by‑step instructions, practical examples, and a handy FAQ. Table of Contents 1. Finding Your GitLab Project 2. Viewing CI/CD Status in GitLab 17.x 3. Branch Naming: main vs. master 4. Lab Layout: Instructions vs. Lab Environment 5. Tips for a Seamless Lab Experience 6. Common Questions (FAQ) Finding Your GitLab Project Why the UI changed - GitLab 16.x displayed all of your projects automatically on the dashboard right after login. - GitLab 17.x introduced a cleaner home page; you now need to click Explore projects to see the full list. Step‑by‑step guide (GitLab 17.x) 1. Log in to your GitLab instance. 2. In the left‑hand navigation bar, locate the Explore icon (a compass). 3. Click Explore → Projects. 4. Use the search bar or filters (e.g., Owned by me, Group, Visibility) to locate the lab project you need. Pro tip: Bookmark the “Explore projects” URL (e.g., https://gitlab.example.com/explore/projects) for quick access in future sessions. Viewing CI/CD Status in GitLab 17.x What changed? In earlier releases, the CI/CD pipeline’s pass/fail badge appeared directly on the project cards. GitLab 17.x now shows the status only after you open the project. How to see the pipeline result 1. After locating your project (see the previous section), click the project name to open its overview page. 2. The CI/CD widget near the top will display the latest pipeline status: - ✅ Passed – all jobs succeeded. - ❌ Failed – one or more jobs did not complete successfully. 3. Click the pipeline badge to drill down into individual job logs if you need to troubleshoot. Example scenario You just pushed a change to the repository and wonder if the security scan passed. - Open the project → CI/CD widget shows ❌ Failed. - Click the failed pipeline → identify the Static Application Security Testing (SAST) job that flagged an issue. - Fix the code, push again, and verify the status turns green. Branch Naming: main vs. master Historical context - GitHub switched its default branch name from master to main in 2020 to promote inclusive terminology. - Many organizations, including our DevSecOps labs, have adopted the same convention. Can you still use master? - Yes. The lab pipelines are configured to run on any branch you push, including master. - Recommendation: Use main for new repositories to stay aligned with industry standards and avoid confusion when collaborating with external teams. Quick command to rename a local branch # Rename local master to main git branch -m master main # Push the renamed branch and set upstream git push -u origin main # (Optional) Delete the old remote branch git push origin --delete master Lab Layout: Instructions vs. Lab Environment Current limitation The learning platform does not support splitting the lab instructions and the interactive environment across two separate screens or windows. Work‑around suggestions - Dual‑monitor setup: Open the instructions in a browser tab on one monitor and the lab environment (e.g., VS Code, terminal, or GitLab UI) on the other. - Browser windows: Drag the instruction tab to the left side of the screen and the lab tab to the right, using the OS’s split‑view feature. While not a native feature, these approaches give you a quasi‑split view that can improve focus and reduce context switching. Tips for a Seamless Lab Experience | Tip | Why it helps | |-----|---------------| | Bookmark key pages (Explore projects, pipeline view) | Saves time navigating between sections. | | Enable browser notifications for GitLab | Instantly know when a pipeline finishes. | | Use a consistent branch name (main) | Aligns with the lab’s documentation and avoids mismatched references. | | Keep a terminal session open | Quickly run git status or git log without leaving the lab UI. | | Take screenshots of error messages | Helpful for real agent or instructor feedback. | Common Questions (FAQ) Q1: I can’t find my project after logging in. A: In GitLab 17.x you must click Explore → Projects. If you still don’t see it, verify you’re logged into the correct group or ask the lab admin to confirm your access rights. Q2: The CI/CD badge still shows “No pipeline” after opening the project. A: This usually means a pipeline hasn’t been triggered yet. Push a commit to any branch (e.g., git push origin main) to start the pipeline. Q3: My lab instructions mention the master branch, but my repo only has main. A: The lab works with either branch. Update the instruction step to reference main or rename your branch using the commands above. Q4: Can I view the instructions on a tablet while working on the lab on a laptop? A: Yes—simply open the instruction URL on a separate device. The platform does not enforce a single‑screen view. Q5: I see a red “Failed” badge but the job logs are empty. A: Refresh the pipeline page; sometimes logs load with a slight delay. If they remain empty, check the runner’s health status in Admin → Runners (or ask support). Bottom Line Navigating GitLab’s updated UI, interpreting CI/CD status, and adhering to modern branch naming conventions are essential skills for any DevSecOps practitioner. By following the steps and tips outlined above, you’ll spend less time hunting for information and more time mastering the security‑focused workflows that the lab is designed to teach. Happy coding!

Last updated on Feb 09, 2026

Lab Environment Management: Restart, Reset, Connectivity, and Support Guide

Lab Environment Management: Restart, Reset, Connectivity, and Support Guide Managing a hands‑on DevSecOps lab should be seamless, but occasional hiccups—like a stalled VM, lost configuration, or network blockage—can interrupt your learning flow. This guide walks you through the essential actions for restarting, resetting, and troubleshooting connectivity in the Practical DevSecOps labs, plus how to get help when you need it. Table of Contents 1. Restarting Your Lab Machine 2. Resetting the Lab Environment 3. Connectivity Checklist 4. Whitelisting Required Domains & Ports 5. Getting Support 6. Quick Tips & FAQs Restarting Your Lab Machine When a VM becomes unresponsive or you need to apply a system update, a simple restart can restore normal operation. How to Restart 1. Locate the Restart button on the right‑hand side of the lab console. 2. Click Restart. 3. If you are using one of the GitLab machines, the platform automatically restarts the companion GitLab instances to keep the environment in sync. Pro tip: Give the VM 60–90 seconds after the restart command before re‑connecting. This ensures all services have fully initialized. Resetting the Lab Environment A reset returns the entire lab to its original, clean state—useful when you want to start over or when configuration changes have caused errors. Warning: Resetting erases all data on the machine, so back up any important files first. Step‑by‑Step Reset Procedure 1. Refresh the exercise page in your browser. 2. Below the Start the exercise button, click Reset my environment. 3. A confirmation pop‑up appears. Read the warning, then click Yes, Reset my environment. 4. The provisioning process begins; you’ll see a progress indicator. What Gets Reset? - All user‑created files and directories - Installed packages and custom configurations - Database contents and Docker containers Example Scenario You’ve been experimenting with a custom CI/CD pipeline that broke the GitLab runner. Rather than debugging each step, you click Reset my environment to revert to the pristine lab state and try a different approach. Connectivity Checklist If you cannot reach the labs, follow this systematic troubleshooting flow. 1. Verify Internet Stability – Run a speed test or open a few unrelated websites. 2. Refresh & Reset – Reload the lab page, then click Reset my environment before launching the lab again. 3. Disable Interfering Software – Turn off any ad‑blockers, VPNs, or corporate firewalls that might block WebSocket traffic. 4. Use Incognito/Private Mode – This bypasses cached data and extensions that could interfere. 5. Switch Browsers – Google Chrome is the recommended browser for optimal WebSocket support. 6. Change Network – Connect via a different Wi‑Fi network, mobile hotspot, or Ethernet cable. 7. Try Another Device – If possible, launch the lab from a different laptop or desktop. If none of the above resolves the issue, move on to the Support section. Whitelisting Required Domains & Ports Corporate firewalls often block the domains needed for the lab platform. Add the following entries to your allow‑list: | Category | Domains / URLs | Notes | |----------|----------------|-------| | Core Platform | *.practical-devsecops.training | Main lab UI and API | | Chat & Collaboration | chat.practical-devsecops.com | Chatbot chat | | Lab Sub‑domains | *.lab.practical-devsecops.training | Individual lab instances | | Media Content | vimeo.com | Embedded tutorial videos | | Portal | https://chnl.portal.practical-devsecops.training | Course portal & resources | Network Ports - 80 (HTTP) – Required for initial redirects. - 443 (HTTPS) – Secure traffic for all UI, API, and WebSocket connections. Protocols - HTTP/HTTPS – Standard web traffic. - WebSocket (wss) – Real‑time communication between your browser and the lab containers. Ensuring these domains and ports are open eliminates the most common connectivity roadblocks. Getting Support Technical roadblocks happen, and our support team is ready to help. Choose the channel that best fits your urgency: - Chatbot Chat – Real‑time assistance and you can request a real agent for urgent issue. - Email – Send detailed queries (including screenshots and error logs) to registrations@practical-devsecops.com. When contacting support, include: 1. Your user ID or registration email. 2. A brief description of the problem. 3. Steps you’ve already tried (e.g., browser switch, network change). 4. Any error messages or screenshots. Quick Tips & FAQs Common Questions - Q: Will restarting a GitLab machine affect my other lab VMs? A: No. Restarting a single GitLab VM triggers an automatic restart of the other GitLab nodes only to keep the cluster synchronized. Your other independent labs remain untouched. - Q: How long does a reset take? A: Typically 2–4 minutes, depending on the lab size and current platform load. - Q: Can I export my work before resetting? A: Yes. Use scp, git push, or download files via the web UI before you click Reset my environment. Handy Tips - Bookmark the support chat for one‑click access during a lab session. - Take periodic snapshots of your work (e.g., push to a personal Git repo) to avoid data loss. - Use Chrome’s “Clear browsing data” (cookies & cache) if you notice stale UI elements after a reset. Stay Productive By mastering these restart, reset, and connectivity steps, you’ll spend more time building secure pipelines and less time troubleshooting the lab infrastructure. Keep this guide handy, and you’ll navigate any technical snag with confidence. Happy learning!

Last updated on Mar 03, 2026

Managing Lab Access in Practical DevSecOps Courses: Duration, Pausing, Resetting, and What Happens After the Lab Ends

Managing Lab Access in Practical DevSecOps Courses: Duration, Pausing, Resetting, and What Happens After the Lab Ends Practical DevSecOps training combines video lessons, hands‑on labs, and supporting documentation to prepare you for the CDP (Certified DevSecOps Practitioner) exam. Understanding how long you can use the labs, whether you can pause or extend them, and what resources remain after the lab period expires is essential for planning your study schedule and ensuring a smooth path to certification. This guide walks you through lab access timelines, pausing procedures, reset options, and post‑lab resource availability, so you can make the most of your learning investment. Table of Contents 1. What Resources Remain After Lab Access Ends? 2. How Long Do You Actually Have Lab Access? 3. Pausing Your Lab Environment 4. Extending or Resetting Lab Time – What’s Possible? 5. Practical Scenarios & Tips 6. Common Questions (FAQ) What Resources Remain After Lab Access Ends? When the 60‑day lab window closes, you still retain three key assets that support your exam preparation: | Resource | Access Length | How to Use It | |----------|----------------|---------------| | Course Videos | 3 years from the date of purchase (current policy) | Stream or download for offline review. | | PDF Manual | Indefinite (once downloaded, it stays on your device) | Reference the manual anytime without needing an internet connection. | | Mattermost Community | Lifetime (as of today) | Continue asking questions, sharing knowledge, and networking with peers and instructors. | Note: The hands‑on labs themselves are only available for a limited period (normally 60 days). After that, you must schedule and complete the CDP exam within 6 months of the lab expiration date. How Long Do You Actually Have Lab Access? - Lab Duration is Day‑Based, Not Hour‑Based The lab access displayed on the course catalog reflects a validity period measured in days (e.g., “60 days”). Each individual lab exercise also shows its own duration on the right side of the title, but the overall environment shuts down once the overall day count expires. - Typical Timeline 1. Day 0 – You receive lab credentials and the environment is provisioned. 2. Day 1‑60 – Full access to all lab exercises. 3. Day 61 – Labs are de‑provisioned; you lose hands‑on access but keep videos, PDFs, and community support. Pausing Your Lab Environment If life gets busy and you need a temporary break, you can pause the labs once during the 60‑day window. Step‑by‑Step Pause Procedure 1. Visit the Member Portal Open the following URL in your browser: https://members.practical-devsecops.training/pause-course 2. Wait for Provisioning to Complete - If the status reads Provisioning, give the system a few minutes. - Once the status changes to Started, the Pause The Lab button becomes active. 3. Click “Pause The Lab” - Confirm the action when prompted. - The lab environment will be frozen, and the remaining days will be preserved. Important: You can only pause once per enrollment. After you resume the labs, the pause option disappears permanently. Extending or Resetting Lab Time – What’s Possible? | Action | Availability | How to Do It | |--------|--------------|--------------| | Extend Lab Access (e.g., until 2025) | Not supported | The platform does not allow manual extensions beyond the original 60‑day period. | | Pause Instead of Extend | ✅ Available (once) | Follow the pause steps above. | | Reset Lab Progress | ❌ Not available | There is currently no feature to wipe or restart lab progress. | If you anticipate needing more practice time, plan to pause the labs strategically (e.g., when you have a vacation or a heavy work sprint). The pause will preserve your remaining days, effectively giving you a longer overall study window without extending the original expiration date. Practical Scenarios & Tips Scenario 1 – You Finish Labs Early, but the Exam Is Months Away - What to Do: Keep the labs active until you’re ready to schedule the exam. Use the remaining days for a final practice run. Remember you must sit for the CDP exam within 6 months of lab expiration. Scenario 2 – A Work Project Takes Over Your Schedule for Two Weeks - What to Do: Pause the labs before the project starts. When the project ends, resume the labs and continue where you left off. Scenario 3 – You Want to Review Lab Steps After the Environment Is Gone - What to Do: Download the PDF manual for each lab while you still have access. The PDFs remain on your device forever and can serve as a reference guide. Tips for Maximizing Your Lab Experience - Bookmark the course overview page – Quick access saves time when you need to check remaining days. - Take Screenshots of Key Configurations – Since you can’t reset labs, capturing your work helps if you need to recreate steps later. - Leverage Mattermost – Post questions about tricky lab scenarios; community members often share alternative solutions. - Schedule Your Exam Early – Setting a firm exam date creates a natural deadline and helps you allocate lab time efficiently. Common Questions (FAQ) Q1: After the labs expire, can I still watch the video lessons? A: Yes. Video access continues for three years from the purchase date. Q2: Is there any way to get more than one pause? A: No. The platform allows a single pause per enrollment. Q3: What happens if I don’t schedule the CDP exam within six months of lab expiration? A: You’ll need to buy the exam voucher again. Q4: Can I reset my lab progress to start over? A: Currently, resetting lab progress is not possible. Plan your learning path accordingly. Q5: Do I lose my Mattermost community membership when labs end? A: No. Mattermost access is lifetime, so you stay connected to the community indefinitely. Bottom Line Managing lab access effectively is a blend of timing, strategic pauses, and leveraging the permanent resources that remain after the labs close. By understanding the 60‑day lab window, using the one‑time pause wisely, and keeping copies of PDFs and video content, you can stay on track for the CDP exam and make the most of your Practical DevSecOps training investment. Happy learning—and good luck on your certification journey!

Last updated on Feb 11, 2026

Managing Course and Lab Access: Timelines, Pausing, Resuming, and Resetting

Managing Course and Lab Access: Timelines, Pausing, Resuming, and Resetting Understanding how and when you can access your Practical DevSecOps training material is essential for staying on track and getting the most out of your investment. This guide walks you through everything you need to know about course start deadlines, lab countdowns, pausing and resuming labs, and resetting lab environments. Whether you’re a new learner or returning after a break, the step‑by‑step instructions below will help you manage your learning experience with confidence. Table of Contents 1. When Does the Lab Countdown Begin? 2. Course Start Deadline – What’s the Time Limit? 3. Pausing a Lab: How and When 4. Resuming a Paused Lab 5. Resetting Your Lab Environment 6. Practical Scenarios & Tips 7. Frequently Asked Questions When Does the Lab Countdown Begin? - Immediate Activation – As soon as you purchase a course extension, our platform automatically re‑activates the associated labs. - Countdown Starts at Reactivation – The moment the system restores access, the lab timer begins to run. There is no additional waiting period. Example: You buy a 90‑day lab extension on March 5th at 10:00 AM. The system re‑activates the labs instantly, and the 90‑day countdown starts at 10:00 AM on March 5th. Course Start Deadline – What’s the Time Limit? - One‑Year Rule – You must start the course within 12 months of the date you first received access. - Why It Matters – This policy ensures that course content remains current and that you benefit from the latest DevSecOps best practices. Scenario: If you were granted access on January 1, 2025, you have until January 1, 2026 to launch the first module. Starting after that date will require a new enrollment. Pausing a Lab: How and When Sometimes life gets in the way, and you need a short break from hands‑on work. Our platform allows a single pause per lab purchase. Steps to Pause 1. Log in to the Members Portal: https://members.practical-devsecops.training/pause-course 2. Click the Pause button next to the lab you wish to suspend. 3. Confirm the action in the pop‑up dialog. Important Limits - One‑time pause only – After you resume, the pause option disappears permanently for that lab. - Pause duration – The clock stops while the lab is paused, preserving your remaining time. Resuming a Paused Lab When you’re ready to get back to work, resuming is straightforward. Resumption Process 1. Return to the same Members Portal link used for pausing. 2. The Resume button will now be visible. Click it. 3. Confirm the resume action; the lab timer will restart from where it left off. Tip: Take a screenshot of the “Resume” button location before you pause, so you can find it quickly later. Resetting Your Lab Environment Resetting gives you a clean slate—useful when you want to start an exercise over or troubleshoot a broken environment. Warning: Resetting erases all data in the lab, so back up any important files first. Reset Procedure 1. Navigate to the lab’s exercise page. 2. Click the Reset my environment button. 3. A confirmation pop‑up appears. Read the warning, then click Yes, Reset my environment. 4. The system provisions a fresh instance; this usually takes a few minutes. Best Practices - Backup before resetting – Download scripts, logs, or configuration files you may need later. - Document your steps – Keeping a short notebook of commands run before a reset helps you reproduce the setup quickly. Practical Scenarios & Tips | Situation | Recommended Action | |-----------|--------------------| | You bought a 30‑day lab extension but can’t start right away | Pause the lab immediately; you’ll retain the full 30 days once you resume. | | Your lab environment crashes and you’re stuck | Use the Reset feature after backing up any work you need to keep. | | You’re nearing the one‑year start deadline | Prioritize launching the first module; consider contacting support for a possible extension if extenuating circumstances exist. | | You need to review a previous exercise | Resetting gives you a fresh environment, but you can also clone the repository of the exercise (if provided) to keep a local copy. | Frequently Asked Questions Q1: Does the lab timer start when I purchase the extension or when I first open the lab? A: The timer starts immediately after the system re‑activates the lab, which occurs right after purchase. Q2: Can I pause a lab more than once? A: No. Each lab can be paused only one time. After you resume, the pause option disappears. Q3: What happens to my remaining lab time if I reset the environment? A: Resetting does not affect the remaining time on your lab subscription; only the data inside the environment is cleared. Q4: I missed the one‑year start deadline. Can I still access the course? A: Typically, access is locked after 12 months. Contact support with your enrollment details; they may offer a re‑enrollment option. Q5: Is there a way to extend the lab duration beyond the purchased period? A: Yes. You can buy additional extensions at any time through the https://portal.practical-devsecops.training/pricing. The new period adds to your existing remaining time. Final Thoughts Managing your course and lab access efficiently ensures you stay on schedule, avoid unnecessary data loss, and make the most of your DevSecOps training. Keep this guide handy, follow the step‑by‑step instructions when pausing, resuming, or resetting labs, and always back up critical work before making changes. Happy learning!

Last updated on Jan 29, 2026